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

前提

        要设计一款优秀的弹幕系统，首先要考虑人多的时候弹幕响应的完整性、保证弹幕不卡顿不丢失的问题并且要确保系统的稳定性可靠性。那我们就需要在设计之初解决这些问题。

解决

带宽优化

1.启用Http压缩：http gzip压缩比率可以达到40%以上（gzip比deflate要高出4%~5%）。

2.Response结构简化：把公共的内容抽离出来，变的内容放在Response结构中

3.内容排列顺序优化：重复度越高，压缩比越高，因此可以将字符串和数字内容放在一起摆放

4.频率控制：通过添加请求间隔参数（下次请求时间），保证客户端的请求频率服务端可控

弹幕卡顿、丢失分析

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

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

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

2.WebSockets：服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息，是真正的双向平等对话。

        优点：较少的控制开销，在连接创建后，服务器和客户端之间交换数据时，用于协议控制的数据包头部相对较小。

3.Long Polling vs Websockets：Long Polling在一些弱网的地区会发生断开连接的情况Websockets服务端已经发现连接断开，仍然没有办法推送数据，只能被动等待客户端重新建立好连接才能推送，在此之前数据将可能会被采取丢弃的措施处理掉。这两种形式都会发生连接断开的情况。最后我们采取短轮询的方式。

健壮、可靠性

 进行服务拆分，拆分为拉取弹幕服务和发送弹幕服务。拉取弹幕服务：引入了本地缓存。数据更新的策略是服务会定期发起RPC调⽤从弹幕服务拉取数据，拉取到的弹幕缓存到内存中，这样后续的请求过来时便能直接⾛走本地内存的读取，⼤大幅降低了调用时延。发送弹幕服务：因为用户一定时间能看得过来弹幕总量是有限的，所以可以对弹幕进行限流，有选择的丢弃多余的弹幕。同时，采用柔性的处理方式，拉取用户头像、敏感词过滤等分支在调用失败的情况下，仍然能保证服务的核心流程不受影响，即弹幕能够正常发送和接收，提供有损的服务。