如何设计一个 70w 在线人数的弹幕系统？分析

背景

第一期弹幕使用腾讯云支持，效果并不理想，经常出现卡顿、弹幕偏少等问题。最终促使我们开发自己的弹幕系统。性能要求是需要支持，单房间百万用户同时在线。

问题分析

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

带宽压力

假如说每3秒促达用户一次，那么每次内容至少需要有15条才能做到视觉无卡顿。15条弹幕+http包头的大小将超过3k，那么每秒的数据大小约为8Gbps，而运维同学通知我们所有服务的可用带宽仅为10Gbps。

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

该问题已在线上环境

性能与可靠性

百万用户同时在线，按照上文的推算，具体QPS将超过30w QPS。如何保证在双十一等重要活动中不出问题，至关重要。性能也是另外一个需要着重考虑的点。

带宽优化

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

1、启用Http压缩

通过查阅资料，http gzip压缩比率可以达到40%以上（gzip比deflate要高出4%~5%）。

2、Response结构简化

3、内容排列顺序优化

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

5、频率控制

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

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

弹幕卡顿、丢失分析

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

Long Polling via AJAX

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

优点： 减少轮询次数，低延迟，浏览器兼容性较好。缺点： 服务器需要保持大量连接。

8、WebSockets

可靠与性能

9、引入了本地缓存

为了保证服务的稳定性我们对服务进行了拆分，将复杂的逻辑收拢到发送弹幕的一端。同时，将逻辑较为复杂、调用较少的发送弹幕业务与逻辑简单、调用量高的弹幕拉取服务拆分开来。服务拆分主要考虑因素是为了不让服务间相互影响，对于这种系统服务，不同服务的QPS往往是不对等的，例如像拉取弹幕的服务的请求频率和负载通常会比发送弹幕服务高1到2个数量级，在这种情况下不能让拉弹幕服务把发弹幕服务搞垮，反之亦然，最⼤度地保证系统的可用性，同时也更更加方便对各个服务做Scale-Up和Scale-Out。服务拆分也划清了业务边界，方便协同开发。

在拉取弹幕服务的一端 ，引入了本地缓存。

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