如何设计一个 70w 在线人数的弹幕系统？( 二 ) _系统

无论是以上哪种方式，都使用到TCP长连接，那么TCP的长连接是如何发现连接已经断开了呢？
TCP Keepalived会进行连接状态探测，探测间隔主要由三个配置控制。

keepalive_probes：探测次数（默认：7次） keepalive_time 探测的超时（默认：2小时） keepalive_intvl 探测间隔(默认：75s)

但是由于在东南亚的弱网情况下， TCP长连接会经常性的断开:

Long Polling 能发现连接异常的最短间隔为：min(keepalive_intvl, polling_interval) Websockets能发现连接异常的最短间隔为：Websockets: min(keepalive_intvl, client_sending_interval)

如果下次发送数据包的时候可能连接已经断开了，所以使用TCP长连接对于两者均意义不大。并且弱网情况下Websockets其实已经不能作为一个候选项了

即使Websockets服务端已经发现连接断开，仍然没有办法推送数据，只能被动等待客户端重新建立好连接才能推送，在此之前数据将可能会被采取丢弃的措施处理掉。
在每次断开后均需要再次发送应用层的协议进行连接建立。

根据了解腾讯云的弹幕系统，在300人以下使用的是推送模式， 300人以上则是采用的轮训模式。但是考虑到资源消耗情况，他们可能使用的是Websocket来实现的弹幕系统，所以才会出现弹幕卡顿、丢失的情况。综上所述， Long Polling和Websockets都不适用我们面临的环境，所以我们最终采取了短轮训的方案来实现弹幕促达

文章插图

五、可靠与性能
为了保证服务的稳定性我们对服务进行了拆分，将复杂的逻辑收拢到发送弹幕的一端。同时，将逻辑较为复杂、调用较少的发送弹幕业务与逻辑简单、调用量高的弹幕拉取服务拆分开来。服务拆分主要考虑因素是为了不让服务间相互影响，对于这种系统服务，不同服务的QPS往往是不对等的，例如像拉取弹幕的服务的请求频率和负载通常会比发送弹幕服务高1到2个数量级，在这种情况下不能让拉弹幕服务把发弹幕服务搞垮，反之亦然，最?度地保证系统的可用性，同时也更更加方便对各个服务做Scale-Up和Scale-Out 。服务拆分也划清了业务边界，方便协同开发。
在拉取弹幕服务的一端，引入了本地缓存。数据更新的策略是服务会定期发起RPC调?从弹幕服务拉取数据，拉取到的弹幕缓存到内存中，这样后续的请求过来时便能直接?走本地内存的读取， ?大幅降低了调用时延。这样做还有另外一个好处就是缩短调?链路，把数据放到离?户最近的地? ，同时还能降低外部依赖的服务故障对业务的影响，

文章插图

为了数据拉取方便，我们将数据按照时间进行分片，将时间作为数据切割的单位，按照时间存储、拉取、缓存数据（RingBuffer），简化了数据处理流程。与传统的Ring Buffer不一样的是，我们只保留了尾指针，它随着时间向前移动，每?秒向前移动一格，把时间戳和对应弹幕列表并写到一个区块当中，因此最多保留60秒的数据。同时，如果此时来了一个读请求，那么缓冲环会根据客户端传入的时间戳计算出指针的索引位置，并从尾指针的副本区域往回遍历直至跟索引重叠，收集到一定数量的弹幕列表返回，这种机制保证了缓冲区的区块是整体有序的，因此在读取的时候只需要简单地遍历一遍即可，加上使用的是数组作为存储结构，带来的读效率是相当高的。
再来考虑可能出现数据竞争的情况。先来说写操作，由于在这个场景下，写操作是单线程的，因此?可不必关心并发写带来的数据一致性问题。再来说读操作，由图可知写的方向是从尾指针以顺时针?向移动， ?读?向是从尾指针以逆时针方向移动， ?决定读和写的位置是否出现重叠取决于index的位置，由于我们保证了读操作最多只能读到30秒内的数据，因此缓冲环完全可以做到无锁读写