背景：
直播业务中增加弹幕系统，支持单房间百万用户同时在线。
问题分析：
带宽压力：
假如说每3秒促达用户一次，那么每次内容至少需要有15条才能做到视觉无卡顿。15条弹幕+http包头的大小将超过3k，那么每秒的数据大小约为8Gbps，而运维同学通知我们所有服务的可用带宽仅为10Gbps。
解决：
带宽优化:<1>启用Http压缩
<2>Response结构简化
<3>内容排列顺序优化:根据gzip的压缩的压缩原理可以知道，重复度越高，压缩比越高，因此可以将字符串和数字内容放在一起摆放
<4>频率控制
带宽控制：通过添加请求间隔参数（下次请求时间），保证客户端的请求频率服务端可控。以应对突发的流量增长问题，提供有损的服务。
稀疏控制：在弹幕稀疏和空洞的时间段，通过控制下次请求时间，避免客户端的无效请求。
弱网导致的弹幕卡顿、丢失
解决：<1>Long Polling via AJAX
客户端打开一个到服务器端的 AJAX 请求，然后等待响应，服务器端需要一些特定的功能来允许请求被挂起，只要一有事件发生，服务器端就会在挂起的请求中送回响应。如果打开Http的Keepalived开关，还可以节约握手的时间。
Long Polling via AJAX优点： 减少轮询次数，低延迟，浏览器兼容性较好。缺点： 服务器需要保持大量连接。
<2>WebSockets
长轮询虽然省去了大量无效请求，减少了服务器压力和一定的网络带宽的占用，但是还是需要保持大量的连接。那么人们就在考虑了，有没有这样一个完美的方案，即能双向通信，又可以节约请求的 header 网络开销，并且有更强的扩展性，最好还可以支持二进制帧，压缩等特性呢？于是人们就发明了这样一个目前看似“完美”的解决方案 —— WebSocket。它的最大特点就是，服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息，是真正的双向平等对话。
WebSockets优点： 较少的控制开销，在连接创建后，服务器和客户端之间交换数据时，用于协议控制的数据包头部相对较小。在不包含扩展的情况下，对于服务器到客户端的内容，此头部大小只有2至10字节（和数据包长度有关）；对于客户端到服务器的内容，此头部还需要加上额外的4字节的掩码。相对于 HTTP 请求每次都要携带完整的头部，此项开销显著减少了。更强的实时性，由于协议是全双工的，所以服务器可以随时主动给客户端下发数据。相对于HTTP请求需要等待客户端发起请求服务端才能响应，延迟明显更少；即使是和Comet等类似的长轮询比较，其也能在短时间内更多次地传递数据。长连接，保持连接状态。
性能与可靠性：
解决： 引用本地缓存：本地缓存基于本地环境的内存，访问速度非常快，对于一些变更频率低、实时性要求低的数据，可以放在本地缓存中，提升访问速度
使用本地缓存能够减少和Redis类的远程缓存间的数据交互，减少网络I/O开销，降低这一过程中在网络通信上的耗时
