一、需求背景

为了更好的支持直播业务，产品设计为直播业务增加弹幕功能,但是最初的弹幕设计使用效果并不理想，经常出现卡顿、弹幕偏少等需要解决的问题。

二、问题分析

按照背景来分析，系统主要面临以下问题：

1. 带宽压力；

2. 弱网导致的弹幕卡顿、丢失；

3. 性能与可靠性。

三、设计优化

带宽优化

为了降低带宽压力，主要采用了以下方案：

1. 启用Http压缩

HTTP压缩是指在Web服务器和浏览器间传输压缩文本内容的方法。HTTP压缩通常采用 gzip压缩算法压缩HTML、JavaScript、CSS等文件。压缩的最大好处就是降低了网络传输的数据量，从而提高客户端浏览器的访问速度。当然，同时也会增加一点点服务器的负担。
http gzip压缩比率可以达到40%以上（gzip比deflate要高出4%~5%）。

2. 简化Response结构

将响应体的内容进行简化，去掉不必要的字段，在网络传输中可以节省流量，提高效率。

3. 内容排列顺序优化

根据gzip的压缩的压缩原理可以知道，重复度越高，压缩比越高，因此可以将字符串和数字内容放在一起摆放。

4. 频率控制

• 带宽控制：通过添加请求间隔参数（下次请求时间），保证客户端的请求频率服务端可控。以应对突发的流量增长问题，提供有损的服务。

• 稀疏控制：在弹幕稀疏和空洞的时间段，通过控制下次请求时间，避免客户端的无效请求。

弹幕卡顿、丢失分析

在开发弹幕系统的的时候，最常见的问题是该怎么选择促达机制，推送 vs 拉取 ？

Long Polling via AJAX

客户端打开一个到服务器端的 AJAX 请求，然后等待响应，服务器端需要一些特定的功能来允许请求被挂起，只要一有事件发生，服务器端就会在挂起的请求中送回响应。如果打开Http的Keepalived开关，还可以节约握手的时间。

优点： 减少轮询次数，低延迟，浏览器兼容性较好。

缺点： 服务器需要保持大量连接。

WebSockets

长轮询虽然省去了大量无效请求，减少了服务器压力和一定的网络带宽的占用，但是还是需要保持大量的连接。那么人们就在考虑了，有没有这样一个完美的方案，即能双向通信，又可以节约请求的 header 网络开销，并且有更强的扩展性，最好还可以支持二进制帧，压缩等特性呢？

于是就发明了这样一个目前看似“完美”的解决方案 —— WebSocket。它的最大特点就是，服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息，是真正的双向平等对话。

优点：较少的控制开销，在连接创建后，服务器和客户端之间交换数据时，用于协议控制的数据包头部相对较小。在不包含扩展的情况下，对于服务器到客户端的内容，此头部大小只有2至10字节（和数据包长度有关）；对于客户端到服务器的内容，此头部还需要加上额外的4字节的掩码。相对于 HTTP 请求每次都要携带完整的头部，此项开销显著减少了。更强的实时性，由于协议是全双工的，所以服务器可以随时主动给客户端下发数据。相对于HTTP请求需要等待客户端发起请求服务端才能响应，延迟明显更少；即使是和Comet等类似的长轮询比较，其也能在短时间内更多次地传递数据。长连接，保持连接状态。

可靠与性能

在拉取弹幕服务的一端 ，引入本地缓存。数据更新的策略是服务会定期发起RPC调⽤从弹幕服务拉取数据，拉取到的弹幕缓存到内存中，这样后续的请求过来时便能直接⾛走本地内存的读取，⼤大幅降低了调用时延。这样做还有另外一个好处就是缩短调⽤链路，把数据放到离⽤户最近的地⽅，同时还能降低外部依赖的服务故障对业务的影响。

在发送弹幕的一端 ，因为用户一定时间能看得过来弹幕总量是有限的，所以可以对弹幕进行限流，有选择的丢弃多余的弹幕。同时，采用柔性的处理方式，拉取用户头像、敏感词过滤等分支在调用失败的情况下，仍然能保证服务的核心流程不受影响，即弹幕能够正常发送和接收，提供有损的服务。

四、架构总结