100w人在线的弹幕系统，是怎么架构的？

阳光穿透心脏的1/2处 2024-03-30 17:52 55阅读 0赞

Shopee是东南亚及中国台湾地区的电商平台 。2015年于新加坡成立并设立总部，随后拓展至马来西亚、泰国、中国台湾地区、印度尼西亚、越南及菲律宾共七大市场。

Shopee拥有商品种类，包括电子消费品、家居、美容保健、母婴、服饰及健身器材等。

2022年第二季度，Shopee保持业绩增长，其中总订单数20亿，同比增长41.6%。最新财报数据显示，Shopee电商平台在今年第二季度的GMV为190亿美元，同比增长27.2%；总营收为17亿美元，同比增长51.4%。

据data.ai， Shopee取得了2022年Q1全球购物类App总下载量第一、谷歌应用商店全球购物类App用户使用总时长第一的佳绩。

> 注：本文以 PDF 持续更新，最新尼恩 架构笔记、面试题 的PDF文件，请从这里获取：[码云][Link 1]

### 100W用户同时在线的弹幕系统背景 ###

为了更好的支持 shopee 东南亚直播业务，Shopee 平台产品设计为直播业务增加了弹幕。

第一期弹幕使用腾讯云支持，效果并不理想，

主要问题是：

*  经常卡顿、
 *  弹幕偏少等问题。

最终促使Shopee团队，定制开发自己的弹幕系统。

其性能规划是： 单房间百万用户同时在线。

没有看错：**百万用户同时在线，而且是单房间**。

假如说每3秒促达用户一次，百万用户同时在线，单房间具体QPS将超过30w QPS

没有看错：**单房间具体QPS将超过30w QPS**

### 问题分析 ###

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

1.  带宽压力
    
    > 假如说每3秒促达用户一次，那么每次内容至少需要有15条才能做到视觉无卡顿。
    > 
    > 15条弹幕+http包头的大小将超过3k，那么每秒的数据大小约为8Gbps，
    > 
    > 而运维同学通知我们所有服务的可用带宽仅为10Gbps。
2.  弱网导致的弹幕卡顿、丢失
    
    > 该问题已在线上环境
3.  性能与可靠性
    
    > 百万用户同时在线，按照上文的推算，具体QPS将超过30w QPS。
    > 
    > 如何保证在双十一等重要活动中不出问题，至关重要。性能也是另外一个需要着重考虑的点。

### 架构设计和优化 ###

那么，该如何做架构设计和优化呢？

主要的架构优化有：

*  业务解耦+服务拆分
 *  引入本地缓存，优化高并发读
 *  引入限流，优化高并发写
 *  使用滑动窗口，实现无锁化读写
 *  通过短轮训实现弹幕促达
 *  传输优化、节约带宽

### 业务解耦+服务拆分 ###

为了保证服务的稳定性我们对服务进行了拆分，进行业务解耦+服务拆分

#### 业务解耦+服务拆分的具体架构方案 ####

将逻辑较为复杂、调用较少的发送弹幕业务与逻辑简单、调用量高的弹幕拉取服务拆分开来。

将复杂的逻辑收拢到发送弹幕的一端。

![在这里插入图片描述][b15fc1d8b6f54784911d82a09aebe801.png]

服务拆分主要考虑因素是为了不让服务间相互影响，

对于这种系统服务，不同服务的QPS往往是不对等的，

例如像拉取弹幕的服务的请求频率和负载，通常会比发送弹幕服务高1到2个数量级，

![62d41c250fd04be5b4e66fbf38b14c0b.png][]

#### 解耦之后的优势： ####

实现一个小3高的目标： 高可用、高扩展、高协同

![442c5790aa55413b8ccbfa1587af874b.png][]

*  高可用

最⼤度地保证系统的可用性，

在这种情况下，不能让拉弹幕服务把发弹幕服务搞垮，

反之亦然，不能让 发弹服务把拉弹幕服务 搞垮

*  高扩展

方便扩容和缩容

更加方便对各个服务做Scale-Up和Scale-Out。

*  高协同

方便协同开发

服务拆分也划清了业务边界，方便协同开发。

### 引入本地缓存优化高并发读 ###

**在拉取弹幕服务的一端：引入本地缓存**

数据更新的策略是：

服务会定期发起RPC调⽤，从弹幕服务拉取数据，拉取到的弹幕缓存到内存中，

这样后续的请求过来时便能直接⾛走本地内存的读取，大大幅降低了调用时延。

这样做还有另外一个好处就是缩短调⽤链路，把数据放到离⽤户最近的地⽅

同时还能降低外部依赖的服务故障对业务的影响，

> 尼恩提示： 本地缓存非常重要，大家需要做到架构级、源码级精通
> 
> 建议大家穿透 400Wqps本地缓存 caffeine的核心架构、核心源码，这个非常有价值，
> 
> 具体，可以去学习第25章视频《穿透caffeine源码》里边有caffeine的起底式、穿透式介绍

### 引入限流，优化高并发写 ###

**在发送弹幕的一端: 限流（有损服务）**，

因为用户一定时间能看得过来弹幕总量是有限的，

所以可以对弹幕进行限流，有选择的丢弃多余的弹幕。

同时，采用柔性的处理方式，拉取用户头像、敏感词过滤等分支在调用失败的情况下，仍然能保证服务的核心流程不受影响，即弹幕能够正常发送和接收，提供有损的服务。

### 使用滑动窗口，实现无锁化读写 ###

弹幕数据的读写，如果使用阻塞队列，那么需要加锁

如果加锁，在超高并发场景，会性能非常低

如何实现无锁化读写呢

基于滑动窗口技术，实现无锁化读写，保证在**超高并发场景并发读写的性能**

![ring-buffer][]

为了数据拉取方便，我们将数据按照时间进行分片，将时间作为数据切割的单位，按照时间存储、拉取、缓存数据（RingBuffer），简化了数据处理流程。

与传统的Ring Buffer不一样的是，我们只保留了尾指针，

它随着时间向前移动，每⼀秒向前移动一格，把时间戳和对应弹幕列表并写到一个区块当中，因此最多保留60秒的数据。

同时，如果此时来了一个读请求，那么缓冲环会根据客户端传入的时间戳计算出指针的索引位置，并从尾指针的副本区域往回遍历直至跟索引重叠，收集到一定数量的弹幕列表返回，

这种机制保证了缓冲区的区块是整体有序的，因此在读取的时候只需要简单地遍历一遍即可，加上使用的是数组作为存储结构，带来的读效率是相当高的。

再来考虑可能出现数据竞争的情况。

先来说写操作，由于在这个场景下，写操作是单线程的，因此⼤可不必关心并发写带来的数据一致性问题。

再来说读操作，由图可知写的方向是从尾指针以顺时针⽅向移动，而读方向是从尾指针以逆时针方向移动，

⽽决定读和写的位置是否出现重叠取决于index的位置，

由于我们保证了读操作最多只能读到30秒内的数据，因此缓冲环完全可以做到无锁读写

> 尼恩提示： 滑动窗口的原理和源码非常重要
> 
> 具体，可以去学习第26章视频 《100Qwps三级缓存组件实操》里边有滑动窗口的起底式、穿透式介绍

### 通过短轮训实现弹幕促达 ###

Long Polling和Websockets都不适用弱环境，

所以我们最终采取了**短轮训**的方案来实现弹幕促达

#### 弹幕卡顿、丢失分析 ####

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

*  推送 vs 拉取 ？
 *  长轮询 vs 短 轮询

#### 基于AJAX的长轮询方案 （Long Polling via AJAX） ####

客户端打开一个到服务器端的 AJAX 请求，然后等待响应，

服务器端需要一些特定的功能来允许请求被挂起，只要一有事件发生，服务器端就会在挂起的请求中送回响应。

如果打开Http的Keepalived开关，还可以节约握手的时间。

![polling-ajax][]

**优点：**

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

**缺点：**

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

#### 基于WebSockets 的双向通讯方案 ####

长轮询虽然省去了大量无效请求，减少了服务器压力和一定的网络带宽的占用，但是还是需要保持大量的连接。

那么人们就在考虑了，有没有这样一个完美的方案，即能双向通信，又可以节约请求的 header 网络开销，并且有更强的扩展性，最好还可以支持二进制帧，压缩等特性呢？

于是人们就发明了这样一个目前看似“完美”的解决方案 —— WebSocket。

**它的最大特点就是：**

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

![websockets][]

**优点1：较少的控制开销，**

较少的控制开销：在连接创建后， WS用于协议控制的数据包头部相对较小。

在不包含扩展的情况下，服务端到客户端WS 头部大小只有2至10字节（和数据包长度有关）；

对于客户端到服务器的内容，此头部还需要加上额外的4字节的掩码。

但是，与 HTTP 头部比，此项开销显著减少了。

**优点2：更强的实时性，**

WEBSocket由于协议是全双工的，服务器可以随时推数据。

WEBSocket延迟明显更少；

**优点3：长连接，保持连接状态**。

#### Long Polling vs Websockets ####

无论是以上哪种方式，都使用到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来实现的弹幕系统，

也就是 300人以上轮训模式， 腾讯云也是基于Websocket 来实现的，不太可能基于 AJAX来实现，

正式因为基于Websocket ，在弱网环境下，所以才会出现弹幕卡顿、丢失的情况。

综上所述，Long Polling和Websockets都不适用我们面临的环境，

所以我们最终采取了**短轮训**的方案来实现弹幕促达

![polling][]

### 传输优化、节约带宽 ###

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

1.  启用Http压缩

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

1.  Response结构简化

![request response][]

1.  内容排列顺序优化

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

1.  频率控制

>  *  通过请求频率调整带宽：通过添加请求间隔参数，实现客户端的请求频率服务端可控。间隔时间太长，在突发流量的时候， 可能会出现有损服务，对于弹幕来说，是可以容忍的。
>  *  延长请求频率，可以避免无效请求：在弹幕稀疏和空洞的时间段，通过控制下次请求时间，避免客户端的无效请求。

> 注：本文以 PDF 持续更新，最新尼恩Java面试宝典、架构笔记 的PDF文件，请从这里获取：[码云][Link 1]

### 总结 ###

![danmaku architecture][]

最终该服务在双十二活动中，在Redis出现短暂故障的背景下，

高效且稳定的支撑了单房间100w用户在线，成功完成了既定的100w用户的目标

### 参考文献： ###

*  https://halfrost.com/websocket/
 *  https://shopee-sz.github.io/2019/02/27/livechat/
 *  https://www.cyningsun.com/03-31-2019/live-streaming-danmaku.html

### 推荐阅读： ###

《[峰值21WQps、亿级DAU，小游戏《羊了个羊》是怎么架构的？][21WQps_DAU]》

《[场景题：假设10W人突访，你的系统如何做到不 雪崩？][10W_]》

《[2个大厂 100亿级 超大流量 红包 架构方案][2_ 100_ _ _]》

《[尼恩Java面试宝典][Java]》

《[Nginx面试题（史上最全 + 持续更新）][Nginx_ _]》

《[K8S面试题（史上最全 + 持续更新）][K8S_ _]》

《[操作系统面试题（史上最全、持续更新）][Link 2]》

《[Docker面试题（史上最全 + 持续更新）][Docker_ _]》

《[Springcloud gateway 底层原理、核心实战 (史上最全)][Springcloud gateway _]》

《[Flux、Mono、Reactor 实战（史上最全）][Flux_Mono_Reactor]》

《[sentinel （史上最全）][sentinel]》

《[Nacos (史上最全)][Nacos]》

《[TCP协议详解 (史上最全)][TCP_]》

《[分库分表 Sharding-JDBC 底层原理、核心实战（史上最全）][Sharding-JDBC]》

《[clickhouse 超底层原理 + 高可用实操 （史上最全）][clickhouse _ _ _]》

《[nacos高可用（图解+秒懂+史上最全）][nacos]》

《[队列之王： Disruptor 原理、架构、源码 一文穿透][Disruptor _]》

《[环形队列、 条带环形队列 Striped-RingBuffer （史上最全）][_ Striped-RingBuffer]》

《[一文搞定：SpringBoot、SLF4j、Log4j、Logback、Netty之间混乱关系（史上最全）][SpringBoot_SLF4j_Log4j_Logback_Netty]》

《[单例模式（史上最全）][Link 3]》

《[红黑树（ 图解 + 秒懂 + 史上最全）][_ _ _ _]》

《[分布式事务 （秒懂）][Link 4]》

《[缓存之王：Caffeine 源码、架构、原理（史上最全，10W字 超级长文）][Caffeine _10W_]》

《[缓存之王：Caffeine 的使用（史上最全）][Caffeine]》

《[Java Agent 探针、字节码增强 ByteBuddy（史上最全）][Java Agent _ ByteBuddy]》

《[Docker原理（图解+秒懂+史上最全）][Docker]》

《[Redis分布式锁（图解 - 秒懂 - 史上最全）][Redis_ - _ -]》

《[Zookeeper 分布式锁 - 图解 - 秒懂][Zookeeper _ - _ -]》

《[Zookeeper Curator 事件监听 - 10分钟看懂][Zookeeper Curator _ - 10]》

《[Netty 粘包 拆包 | 史上最全解读][Netty _ _ _]》

《[Netty 100万级高并发服务器配置][Netty 100]》

《[Springcloud 高并发 配置 （一文全懂）][Springcloud _ _]》

[Link 1]: https://gitee.com/crazymaker/SimpleCrayIM/blob/master/%E7%96%AF%E7%8B%82%E5%88%9B%E5%AE%A2%E5%9C%88%E6%80%BB%E7%9B%AE%E5%BD%95.md
[b15fc1d8b6f54784911d82a09aebe801.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/9fba2c83bce041098932640ab31289d1.png
[62d41c250fd04be5b4e66fbf38b14c0b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/d4b6bfd3548041a08240365ca652a909.png
[442c5790aa55413b8ccbfa1587af874b.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/31b886c43d034d098c22e732b63e5ab2.png
[ring-buffer]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/36bd180d4cb348b88bba29920652e7cb.png
[polling-ajax]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/221d129d0da74394a40b3dd391c2b202.jpeg
[websockets]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/94e9d0ac8a174beb81abddc5a7575ccb.png
[polling]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/331652ac6dd746e7b8c5bbf2d41075df.jpeg
[request response]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/71b9e5df0f644ab8898afc6702ec9797.jpeg
[danmaku architecture]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/30/831b043bf9ff4b2ebacf67e5d0ce33ab.png
[21WQps_DAU]: https://blog.csdn.net/crazymakercircle/article/details/128725701
[10W_]: https://blog.csdn.net/crazymakercircle/article/details/128533821
[2_ 100_ _ _]: https://blog.csdn.net/crazymakercircle/article/details/128697096
[Java]: https://blog.csdn.net/crazymakercircle/article/details/124790425
[Nginx_ _]: https://blog.csdn.net/crazymakercircle/article/details/128684641
[K8S_ _]: https://blog.csdn.net/crazymakercircle/article/details/128671196
[Link 2]: https://blog.csdn.net/crazymakercircle/article/details/128708648
[Docker_ _]: https://blog.csdn.net/crazymakercircle/article/details/128670335
[Springcloud gateway _]: https://blog.csdn.net/crazymakercircle/article/details/125057567
[Flux_Mono_Reactor]: https://blog.csdn.net/crazymakercircle/article/details/124120506
[sentinel]: https://blog.csdn.net/crazymakercircle/article/details/125059491
[Nacos]: https://blog.csdn.net/crazymakercircle/article/details/125057545
[TCP_]: https://blog.csdn.net/crazymakercircle/article/details/114527369
[Sharding-JDBC]: https://blog.csdn.net/crazymakercircle/article/details/123420859
[clickhouse _ _ _]: https://blog.csdn.net/crazymakercircle/article/details/126992542
[nacos]: https://blog.csdn.net/crazymakercircle/article/details/120702536
[Disruptor _]: https://blog.csdn.net/crazymakercircle/article/details/128264803
[_ Striped-RingBuffer]: https://blog.csdn.net/crazymakercircle/article/details/128264508
[SpringBoot_SLF4j_Log4j_Logback_Netty]: https://blog.csdn.net/crazymakercircle/article/details/125135726
[Link 3]: https://blog.csdn.net/crazymakercircle/article/details/128265067
[_ _ _ _]: https://blog.csdn.net/crazymakercircle/article/details/125017316
[Link 4]: https://blog.csdn.net/crazymakercircle/article/details/109459593
[Caffeine _10W_]: https://blog.csdn.net/crazymakercircle/article/details/128123114
[Caffeine]: https://blog.csdn.net/crazymakercircle/article/details/113751575
[Java Agent _ ByteBuddy]: https://blog.csdn.net/crazymakercircle/article/details/126579528
[Docker]: https://blog.csdn.net/crazymakercircle/article/details/120747767
[Redis_ - _ -]: https://blog.csdn.net/crazymakercircle/article/details/116425814
[Zookeeper _ - _ -]: https://blog.csdn.net/crazymakercircle/article/details/85956246
[Zookeeper Curator _ - 10]: https://blog.csdn.net/crazymakercircle/article/details/85922561
[Netty _ _ _]: https://blog.csdn.net/crazymakercircle/article/details/83957259
[Netty 100]: https://blog.csdn.net/crazymakercircle/article/details/83758107
[Springcloud _ _]: https://blog.csdn.net/crazymakercircle/article/details/102557988