bilibili 高并发实时弹幕系统的实战之路 | 架构师实践日
编者按： 随着直播的发展，直播弹幕也逐渐火爆起来。在架构设计上，高稳定、高可用、低延迟是一款直播弹幕系统必备的三要素。7 月31 日，在七牛云主办的架构师实践日上，来自 bilibili 的架构师刘丁，从这三个方面出发，为大家带来了 bilibili 在直播弹幕服务架构上的最佳实践。下面是对他演讲内容的整理。
高并发实时弹幕是一种互动的体验。对于互动来说，考虑最多的地方就是：高稳定性、高可用性以及低延迟这三个方面。
- 高稳定性，为了保证互动的实时性，所以要求连接状态稳定。
- 高可用性，相当于提供一种备用方案，比如，互动时如果一台机器挂了，此时必须保证可以和另外一台机器连接，这样就从侧面解决了用户连接不中断的问题。
- 对于低延迟，弹幕的延迟周期控制在 1 秒以内，响应是比较快的，所以可以满足互动的需求。
B 站直播弹幕服务架构（下面简称 GOIM ）的出现就是为了解决这一系列的需求。下面将对此进行详细的介绍。
B 站直播弹幕服务架构 GOIM 的出现
图 1
直播聊天系统本质上也是一种推送系统，所谓推送系统就是，当你发送一条消息时，它可以将这个消息推送给所有人。对于直播弹幕来说，用户在不断地发送消息，不断地进行广播，当一个房间里面有 10 万人时，一个消息就要发出 10 万次请求。在 GOIM 出现之前，也用过另一个名为 Gopush 的项目，这个项目推出的目的就是进行推送。在此之后，基于一些针对性的应用场景，GOIM 对 Gopush 进行了优化，从而出现在我们视野当中。GOIM 主要包含以下几个模块（图 1）：
- Kafka（第三方服务）
消息队列系统。Kafka 是一个分布式的基于发布/订阅的消息系统，它是支持水平扩展的。每条发布到 Kafka 集群的消息都会打上一个名为 Topic（逻辑上可以被认为是一个 queue）的类别,起到消息分布式分发的作用。 - Router
存储消息。Comet 将信息传送给 Logic 之后，Logic 会对所收到的信息进行存储，采用 register session 的方式在 Router 上进行存储。Router 里面会收录用户的注册信息，这样就可以知道用户是与哪个机器建立的连接。 - Logic
对消息进行逻辑处理。用户建立连接之后会将消息转发给 Logic ，在 Logic 上可以进行账号验证。当然，类似于 IP 过滤以及黑名单设置此类的操作也可以经由 Logic 进行。 - Comet
维护客户端长链接。在上面可以规定一些业务需求，比如可以规定用户传送的信息的内容、输送用户信息等。Comet 提供并维持服务端与客户端之间的链接，这里保证链接可用性的方法主要是发送链接协议（如 Socket 等）。 - Client
客户端。与 Comet 建立链接。 - Jop
消息分发。可以起多个 Jop 模块放到不同的机器上进行覆盖，将消息收录之后，分发到所有的 Comet 上，之后再由 Comet 转发出去。
以上就是 GOIM 系统实现客户端建立链接，并进行消息转发的一个具体过程。一开始这个结构并不完善，在代码层面也存在一些问题。鉴于这些问题，B 站提供了一些相关的优化操作。在高稳定性方面，提供了内存优化、模块优化以及网络优化，下面是对这些优化操作的介绍。
GOIM 系统的优化之路
内存优化
内存优化主要分为以下三个方面：
1.一个消息一定只有一块内存
使用 Job 聚合消息，Comet 指针引用。
2.一个用户的内存尽量放到栈上
内存创建在对应的用户 Goroutine（Go 程）中。
3.内存由自己控制
主要是针对 Comet 模块所做的优化，可以查看模块中各个分配内存的地方，使用内存池。
模块优化
模块优化也分为以下三方面：
1.消息分发一定是并行的并且互不干扰
要保证到每一个 Comet 的通讯通道必须是相互独立的，保证消息分发必须是完全并列的，并且彼此之间互不干扰。
2.并发数一定是可以进行控制的
每个需要异步处理开启的 Goroutine（Go 协程）都必须预先创建好固定的个数，如果不提前进行控制，那么 Goroutine 就随时存在爆发的可能。
3.全局锁一定是被打散的
Socket 链接池管理、用户在线数据管理都是多把锁；打散的个数通常取决于 CPU，往往需要考虑 CPU 切换时造成的负担，并非是越多越好。
模块优化的三个方面，主要考虑的问题就是，分布式系统中会出现的单点问题，即当一个用户在建立链接后，如果出现故障，其余用户建立的链接不能被影响。
测试是实践过程中最不可缺少的一部分，同时，测试的数据也是用来进行参考比照的最好工具。
图 2
图 2 是 15 年末的压测数据。当时使用了两台物理机，平均每台的在线量是 25 万，每个直播每秒的推送数量控制在 20-50 条内。一般对于一个屏幕来说，40 条就可以满足直播的需求，当时用来进行模拟的推送量是 50 条/秒（峰值），推送到达数是 2440 万/秒。这次的数据显示，CPU 的负载是刚好满，内存使用量在 4G 左右，流量约为 3G。从这个数据得出的结论是，真正的瓶颈负载在 CPU 上。所以，目的很明确，就是将 CPU 负载打满（但是不能超负载）。
图 3
2015 年之后，再次进行优化，将所有内存（堆上的、不可控的）都迁移到栈上，当时只采用了一台物理机，上面承载了 100 万的在线数量。 优化效果体现在 2016 年 3 月的压测数据（图 3）中，这个数据也是最初直播时，想要测试的一个压缩状况。
从图 3 的数据可以看出，优化效果是成倍增加的。当时的目的也是将 CPU 打满，可是在实际直播环境中，需要考虑的最本质的问题其实是在流量上，包括弹幕字数，赠送礼物的数量。如果弹幕需要加上一些特殊的需求（字体、用户等级等），赠送礼物数量过多这样，都会产生很多流量。所以，直播弹幕优化的最终瓶颈只有流量。
2016 年之前，B 站的优化重点都放在了系统的优化上，包括优化内存，降低 CPU 的使用率，可是优化的效果并不显著，一台机器的瓶颈永远是流量。在 2016 年 3 月份后，B 站将优化重点转移到了网络优化上。下面就是 B 站网络优化的一些措施。
网络优化
最初 B 站的工作内容，主要是以开发为主，为了在结构上面得到扩展，所做的工作就是将代码尽量完善。但是在实际业务当中，也会遇见更多运维方面的问题，所以，在之后的关注重点上，B 站添加了对运维的重点关注。
图 4
图 4 是 B 站早期的部署结构。最开始，整套服务是部署在一个 IDC 上面的（单点 IDC），时间一长，这样的部署结构也逐渐显现出它的缺陷：
- 单线 IDC 流量不足
- 单点问题
- 接入率低
这样的网络部署往往会造成延迟高、网速卡顿等问题。
针对以上三点问题，B 站也对部署结构进行了改善，图 5 是改善过的网络部署结构，下面将对这个部署结构进行详细说明。
图 5
针对单点 IDC 流量不足的问题，B 站采用了多点 IDC 接入的方案。一个机房的流量不够，那么就把它分散到不同的机房，看看效果如何。
对于多点 IDC 接入来说，专线的成本是非常高昂的，对于创业公司来说，是一块很大的负担，所以可以通过一些研发或者是架构的方式来解决多 IDC 的问题 。针对多 IDC 的问题，需要优化的方面还有很多，下面列举出一些 B 站现有的一些优化方案：
1.调节用户最优接入节点
使用 Svrlist 模块（图 6.1）支持，选取距离用户最近的最稳定的节点，调控 IP 段，然后进行接入。
图 6.1
2.IDC 的服务质量监控：掉线率
判断一个节点是否稳定，需要不断收集大量的用户链接信息，此时就可以使用监控来查询掉线率，然后不断调优，收集最终的结果去做一个拓扑图（全国范围），在拓扑图当中就可以判断出城市到机房之间的最优线路。
3.自动切走「失联」服务器
4.消息 100%的到达率（仍在实现中）
对于弹幕来说，低丢包率是非常重要的。比如，消息是价值上千块的礼物，此时一旦丢失某些消息，当用户发礼物时，起到的效果就是，实际在弹幕中显示出来的效果是，礼物数远远少于用户花费金钱买来的礼物数。这是一个很严重的问题。
5.流量控制
对于弹幕来说，当用户量到达一定级别时，需要考虑的问题还是流量控制，这也是对于花销成本的控制，当买的机房的带宽，是以千兆带宽为计费标准时，当有超标时，一定要将超标部分的流量切走，以此实现了流量控制的功能。
引入多点 IDC 接入之后，电信的用户依旧可以走电信的线路，但是可以将模块在其他机房进行部署，让移动的一些用户可以连接移动的机房。这样就保证了，不同地区不同运营商之间，最优网络选取的问题。
可是解决了最优网络的选取，却带来了跨域传输的问题。比如在数据收集时，Comet 模块将数据反馈到 Logic，Logic 进行消息分发时，数据便会跨机房传输。有些公司的机房是通过专线进行传输，这样成本将会非常高。所以，为了节约成本就只能走公网的流量，但是公网的稳定性是否高、是否高可用，都是需要考虑的。当流量从电信的机房出去之后，经过电信的交换机，转到联通的交换机，然后到达联通的机房，就会存在跨运营商传输的问题，比如丢包率高，因此，跨运营商传输带来的问题还是非常严重的。
为了解决这个可能存在的风险，可以尝试在联通机房接入一条电信的线路（带宽可以小一点），「看管」电信的模块，让来自不同运营商的流量，可以走自己的线路。做了这样的尝试之后，不仅降低了丢包率，还满足了对稳定性的基本要求，并且成本消耗也不高。可是，这样的方案也不能说是百分百的完美，因为就算是同运营商之间的通讯，也会存在城市和城市之间某个交换机出现故障的情况，对于这样的情况，B 站采取的方法是同时在 IDC-1 与 IDC-2（图 5）之间部署两条电信线路，做了这样的备份方案之后，通畅程度以及稳定性都有非常明显的提升。
针对上述过程中出现的一些问题，前期，需要对每个线路的稳定性进行测试。为了测试每一条线路的稳定性，可以把 Comet 放入各个机房中，并将 Comet 之间的通讯方式汇总成一个链接池（链接池里可以放多个运营商的多条线路），作为网络链接可以将它配置成多条线路，用模块检测所有的 Comet 之间的通讯，以及任何线路传输的稳定性，如果说通畅的话，则保证这个链接是可以用的。（这里面有很多线路，所以一定会选择通畅的那条线路进行传输，这样，就可以判断哪条线路是通畅的。）这样一来，流量进行传输时，就有多条线路可以进行选择，三个运营商中，总有一个是可以服务的。
综合这些问题，B 站又对结构进行了重新优化。（这个结构刚刚做完，目前还没有上线，还需要经过一些测试。）
图 6.2
首先是 Comet 的链接，之前采用的是 CDN、智能 DNS 。但实际上，有些运营商基站会缓存路由表，所以即便将机器迁移走，部分用户也并不能同时迁移走。而 DNS 解析这一块，也并非完全可靠，而且一旦遇上问题，解决的流程又很长，这样下来，体验效果是十分糟糕的。其次是 List ，将其部署在一个中心机房，客户端采用的是 WEB 接口的服务，让客户端访问这个服务，就可以知道该与哪些服务器进行连接。将 IP List（Comet）部署在多个机房，可以将多个机房收集的值反馈给客户端（比如：哪些线路通畅）让客户端自己选择与那个机器进行连接。
如图 6.2 。图中将 IP 段进行了城市的划分，将某一个城市的一些用户信息链接到一个群组（GroupID），群组下有一个或多个 Comet ，把属于这个群组的物理机全部分给 Comet 。
图 7
图 7 是再次优化的结构，还是将 Comet 全部放在 IDC 机房中，消息的传输不再使用 push（推）的方式，而是通过 pull（拉）的方式，将数据拉到中心机房（源站），做一些在线处理之后，再统一由源站进行数据推送。当然，这里要十分注意中心机房的选取，中心机房的稳定性是十分重要的。除此之外，B 站在部署的时候还优化了故障监控这块功能，用来保证高可用的服务。故障监控主要为以下几项：
1.模拟 Client ，监控消息到达的速率
2.线上开启 Ppof ，随时抓图分析进程（CPU）状况
3.白名单：指定人打印服务端日志
设置白名单，记录日志信息，收集问题反馈
标注重点问题，及时解决
防止消息重现
4.服务器负载监控，短信报警
低成本、高效率一直是 B 站所追求的标准，B 站将对 GOIM 系统进行持续优化和改进，以给用户最好的直播弹幕体验。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
