大屏技术演进-推模式

1、问题

• 在咱们上一篇文章《大屏技术演进-拉模式》最后思考部分，咱们提出条件单一使用拉模式其实也能够，定时控制一下时间粒度问题，整个架构也简单，那若是咱们条件增长了呢，用那个模式是否是又回到前端请求同时要根据条件计算的问题呢？
• 咱们是否能够理解为在大屏上面其实在不少时刻可能没有大量日志数据打点，那咱们在人类社会通常沟通方式都是：你有事叫我，没事别叫我（尽可能少这样作，会没有朋友的），在服务架构上，我们仍是尽可能作到：有日志上报通知我，而前端不须要定时去拉取数据，数据拉取也是须要消耗网络流量的。

2、解决方案

那么基于上面两个问题，咱们要思考方向就是推的模式，这里使用时websocket，中心思想就是：有日志上报大屏就有网络请求，没有上报就老实一点，别发请求了，省省吧

那么对应websocket不太理解的同窗，能够考虑看下 WebSocket原理及如何使用 ，里面讲解的比较详细。

上咱们的时序图：

说明：

1. 大屏在打开的时候，会发起一个websocket的connect请求，这个时候链接成功后，会进行一个token的返回。
2. 将返回的token与前端请求的条件参数进行合并提交请求到服务端，服务端将token与条件进行一个绑定操做，条件进行惟一值计算，咱们使用是md5，在redis里面进行一个集合的绑定操做。
3. 后台任务会定时去拉取这个关联关系，而且将条件参数提取出来，将条件进行一个单独的进程去进行对应的计算，多核cpu下面，能够考虑使用线程或者多进程来实现，固然若是是go语言，直接用内置的协程也是能够的，毕竟在语言级别实现csp模型仍是很是不错的。
4. 由于是多个模块数据数据生成，而且多模块下面有一些是实时数据，还有一些是要增量数据，实时数据在每次计算均可以覆盖之前的，而增量的数据只能判断当前是否有数据，没有数据不能覆盖数据源，只有有数据才能够进行覆盖。
5. 计算发现数据版本已经变动后，就通知服务端 条件（condition）与模块列表（modules）须要更新，服务端收到请求后，就将关联关系里面 条件对应的token取出，而后一次性对于这些token发起服务端推送操做，内容就是模块列表（modules）
6. 前端使用onmessage接收到响应后，在使用token与module请求服务端获取对应模块的数据，服务端获取modules列表后去对应redis里面取出数据直接返回给前端。
7. 大致的流程就是上面所讲的。

3、过程当中的问题

Q：websocket为何要用ping/pong来维持？

A：由于在本方案里面，ping/pong心跳用来肯定一个大屏是否打开的，由于咱们在后端计算大屏数据是跟咱们的条件来走的，若是咱们的大屏掉线了，可以及时通知后台任务，那么咱们的计算量会少不少

Q：用ping/pong就能百分百保证个人websocket不会断连吗？

A：答案是否认的，互联网上真没有百分百的事情，网络的一个抖动，咱们的ping/pong就有可能挂了，这是很正常的状况，咱们在业务上会对于ping/pong进行一些重试机制，这个重试可能会短期内的，好比1s内发起多少次请求的；若是这个请求不能正确获取数据，那么服务端过时后，其实这个token就没有太多用处了，前端就会有个定时器去探测websocket服务与本地通信是否有问题，没有问题进行从新的connect操做，而在探测过程当中，咱们有个降级操做，会将咱们websocket操做变成传统的拉模式，这个要结合咱们上一篇文件技术方案。

Q：我条件确定会变动，变动证实作？

A：这是一个好问题，由于啥，切换大屏参数直接致使咱们不少模块数据是须要从新渲染的，那么咱们须要从新的发送push操做，而后后续逻辑是一致的。

Q：为何要用token的介入呢，我已经登入系统了，直接uid就能够不？

A：开始咱们也是考虑到uid的方案的，为何不行呢，主要是咱们这里的token是跟websocket相关的，能够近似的认为是socket里面的fd，好比我一我的开了10个大屏，那么我推送的那一刻，我须要将10个大屏数据都能推送到，而区别就在于，uid只有一个，token是10个

4、总结

这里为何花了两个篇幅来写大屏这块呢，主要是在一些简单场景下，咱们1.0版本会更适合，毕竟websocket相对于流程复杂一点，那么中间节点处毛病地方就会多一点，可是复杂场景下面，又必需要这样作设计，因此咱们就分开两个文章来进行说明。

但愿经过两篇文章，同窗们可以从中学习到大屏制做技术方案的相关知识点，可以让咱们应对产品经理 完（刁）美（钻）需求时候，咱们有一个很是合适的技术方案输出。