直播系统聊天技术(九)：千万级实时直播弹幕的技术实践

本文由云信IM技术团队分享，原题“千万级在线直播弹幕方案”，即时通讯网有修订和改动。

1、引言

疫情期间，线上演唱会是一种很常见的直播娱乐形式，由于线下社交距离的限制，线上形式演唱会比以往更火爆，而对技术的要求也更高。

本文基于网易云信针对TFBOYS某场线上演唱会的技术支持，为你分享千万级在线用户量的直播系统中实时弹幕功能的技术实践，希望能带给你启发。

2、系列文章

本文是系列文章中的第 9 篇：

• 《直播系统聊天技术(一)：百万在线的美拍直播弹幕系统的实时推送技术实践之路》
• 《直播系统聊天技术(二)：阿里电商IM消息平台，在群聊、直播场景下的技术实践》
• 《直播系统聊天技术(三)：微信直播聊天室单房间1500万在线的消息架构演进之路》
• 《直播系统聊天技术(四)：百度直播的海量用户实时消息系统架构演进实践》
• 《直播系统聊天技术(五)：微信小游戏直播在Android端的跨进程渲染推流实践》
• 《直播系统聊天技术(六)：百万人在线的直播间实时聊天消息分发技术实践》
• 《直播系统聊天技术(七)：直播间海量聊天消息的架构设计难点实践》
• 《直播系统聊天技术(八)：vivo直播系统中IM消息模块的架构实践》
• 《直播系统聊天技术(九)：千万级实时直播弹幕的技术实践》（* 本文）
  

3、弹幕整体技术方案

本次的弹幕方案以IM聊天室技术为基础，提供了登录直播间、发送弹幕、礼物消息等能力。同时按照千万级在线广播的目标，为期设计了基于CDN的弹幕广播服务。

直播间收发实时消息（也就是弹幕、礼物）的主要流程如下：

• 1）获取直播间接入地址；
• 2）登录直播间；
• 3）收发消息（弹幕、礼物）。
  

下面将围绕以上流程的三个阶段，在技术上分别阐述如何实现千万级在线直播实时弹幕的能力。

4、弹幕技术方案之获取直播间接入地址

为了提供稳定高可用的实时弹幕服务，需要通过GSLB（Global Server Load Balancing）服务给用户分配最佳的接入地址。

GSLB服务需要从以下几个维度综合考虑：

• 1）用户网络类型；
• 2）机房网络容量；
• 3）服务器负载；
• 4）成本。
  

1）用户网络类型和机房网络容量：

为了用户能够快速、稳定的登录直播间收发消息，一般要根据用户所在地理位置以及网络运营商类型综合考虑给用户分类接入服务器。

机房一般提供BGP网络、三线网络两种接入方案，分配服务根据用户IP地址分析用户的地域、运营商类型并分配最佳接入地址。

一般优先按运营商类型分配三线地址（例如电信用户分配电信接入地址），如果是小运营商或无法识别的IP地址则分配BGP地址，两种接入方式用户都可以获得稳定的网络环境。

2）服务器负载：

单台服务器能够承载的TCP长链接有限，尤其是在高并发进入直播间的情况下，握手协议需要完成链路加密工作，对系统的CPU资源消耗比较大，因此需要实现一套良好的均衡分配策略。

3）一套基于服务器负载均衡的分配策略：

长链接接入服务器周期性上报当前服务器负载到负载均衡服务集群，负载信息存储在共享缓存中，接入分配服务根据负载信息动态分配接入地址。

一般情况下用户请求直播间地址，地址分配服务会查询负载均衡服务（或者直接查询负载缓存），然后根据获取到的信息分配当前负载最低的服务器。

在千万级别的在线直播活动场景下，开播时大量用户并发进入直播间，分配服务可达50万到100万TPS，这么高的TPS下如果还用“一般分配”方案，负载均衡（缓存）服务的TPS和集群之间的机房网络带宽非常高，单台服务器亦可能因为负载信息滞后导致超负荷分配。



为解决机房内带宽和超负载分配的问题，我们对分配方案进行了优化：

• 1）长链接服务器上报负载的周期从1秒调整到5毫秒，负载均衡服务器可以更实时的同步负载信息；
• 2）“地址分配”服务不再按请求查询负载信息，而是开启单独的同步线程周期性（同样是5毫秒）同步负载数据，从而有效降低负责信息同步的TPS和网络开销；
• 3）“地址分配”服务不在按最低负载分配，而是将服务接入地址按负载排序，单个接入地址分配一定次数后按顺序分配下一个接入地址（避免低负载服务器瞬间被打爆）。
  

在实际方案落地中，需要结合负载、用户网络类型、机房线路容量等因素综合分配。

5、弹幕技术方案之登录直播间

登录直播间主要有两项任务：

• 1）握手；
• 2）身份认证。
  

1）握手：

SDK建立TCP长链接后，首先向服务器发送握手协议，主要提供SDK版本、协议版本、支持的加密算法等信息，服务器根据SDK提供的信息选择合适的协议版本以及加密算法，建立安全的通信链路。

我们支持的非对称算法包括：RSA、SM2等算法。支持的对称加密算法包括：AES，SM4等（SM2、SM4为国密算法）。

非对称加密算法对CPU资源消耗非常高，为了提高性能一般可以考虑选择合适的密钥长度，另外针对Java平台建议考虑使用JNI技术提高非对称加密计算性能。

2）身份认证：

引言中提到的该次直播活动是在线付费直播，因此身份认证包含了账号认证和业务认证两部分，即用户必须使用正确的账号密码登录App，且必须付费购买直播门票才有权限观看直播。

为优化系统性能，实时弹幕服务将“地址分配和鉴权”服务进行了特殊优化：


鉴权中心提供用户进入直播间弹幕服务的身份鉴权策略配置。在该次直播活动中采用了动态Token的鉴权机制，即根据用户账号、登录时间、分配的接入地址以及鉴权中心按时间区间生成的“随机数以及对应的Token算法”动态计算鉴权Token。

用户打开直播App，首先完成账号鉴权。在进入直播间时通过业务中心完成直播付费身份认证和弹幕服务地址分配（同步获取到弹幕服务的动态鉴权token），最后根据接入地址登录弹幕服务，弹幕服务依据鉴权中心的策略校验Token正确性。

动态Token鉴权采用进程本地计算的方式。可以在不访问用户服务的情况下完成身份鉴权，在提高登录认证的性能同时有效的降低了业务成本。

6、弹幕技术方案之收发消息（弹幕、礼物）

实时收发消息是直播间的核心业务，主要分为弹幕和礼物两类：

• 1）礼物因涉及付费等因素一般通过客户方业务服务器发送；
• 2）弹幕消息则可以通过聊天室长链接发送。
  

在千万级直播间场景下，因消息量太高，因此需要从消息量、消息体大小、消息比例等多个方面优化，因此我们设计了一套基于优先级队列的弹幕服务。

首先：为了节约消息产生的带宽，在大型直播项目开始阶段，就需要对消息格式进行优化，充分精简消息体大小。例如将礼物消息展示相关的资源文件提前预加载到直播App中，礼物消息转化为业务编号，可极大的减少消息大小；

其次：针对上行消息设计流控机制。为了能全局控制上行消息体量，设计了逐级流控方案。上层级根据下层级能够支撑处理能力设计相对较粗粒度的本地流控机制。在弹幕反垃圾业务阶段，因需要全局控制消息量，因此采用分布式全局流控方案；弹幕广播阶段则根据业务广播需求再一次进行消息流控。



上行消息通过反垃圾监测后被投递到弹幕服务处理。基于优先级队列的弹幕服务首先按业务划分不同的消息队列，例如：系统广播、高优先级礼物、低优先级、弹幕，然后按队列分配消息比例，最后根据单位时间（1秒）内用户需要接收到的消息量计算各个队列应该投递的消息数量。在实际投递消息的过程中，若前一个队列消息量不足，可将剩余的消息数量叠加到下一个队列，以确保每一个周期都发送足够的消息给用户。

弹幕可通过长连接或CDN广播给其他用户。为了给用户提供极致的弹幕体验，充分发挥边缘加速的优势，在千万级在线直播场景下优先选择CDN方案（如下图所示）。



基于CDN广播弹幕有两种方案：

• 1）基于推流的方案：类似于直播视频推流技术，即将消息伪装成视频流的形式推送到CDN，直播App以订阅数据流的方式同步弹幕信息；
• 2）静态文件加速方案：即弹幕服务将不同队列中的消息组装成一个静态文件，直播App周期性的到CDN服务器下载弹幕静态文件。
  

相对来说：

• 1）静态文件加速方案实现更简单但实时性不高（取决于弹幕同步的周期时长）；
• 2）推流的方案消息实时性更高，但实现相对复杂，且需要考虑到不同终端的兼容性。
  

实际项目中可根据场景和终端类型灵活选择不同的方案。

为了保障服务的可靠性，可考虑融合CDN的方案，即同时将消息推送到多家CDN厂商，并结合CDN厂商的容量比例以及网络延迟情况综合调度（例如基于权重的轮巡调度策略）。

7、弹幕稳定性设计之单元化部署

ChatLink和ChatServer采用单元化部署的方案，有以下优点：

• 1）单元内依赖的核心服务单元之间相互独立，水平扩展能力好，且单元内服务故障不影响其他单元，可以有效避免整个服务不可用的问题；
• 2）跨机房部署，避免单个机房容量不足，或单机房不可用问题；
• 3）弹幕方案采用了单元无状态的设计理念，因此不需要考虑单元之间同步数据的问题。
  

单个直播间的“接入服务”和“弹幕服务”因需要全局控制未采用单元化部署方案，但是在实施阶段采用了跨机房部署的方案（包括依赖的存储资源、服务），可以避免单个机房故障导致服务不可用的问题。

8、弹幕稳定性设计之单点服务高可用

针对“接入服务”和“弹幕服务”，除了采用跨机房部署外，在服务设计上核心依赖的存储资源、服务，采用主备模式。

例如：心跳负载依赖的缓存服务，单个缓存实例本身高可用，但考虑到极端情况（例如缓存集群内超过一半的服务器宕机导致服务不可用），因此采用主备缓存集群方案，当主集群不可用后，业务主动切换到备用集群，可保障业务在5秒内恢复正常。

9、幕稳定性设计之系统监控与数据大盘

为了实时了解系统运行状态，在弹幕方案中实现了秒级数据大盘方案。

监控大盘围绕用户和消息主要展示以下信息：

• 1）用户地域分布变化；
• 2）上行消息量；
• 3）广播消息量；
• 4）机房出口带宽；
• 5）CDN带宽；
• 6）消息流控比例；
• 7）端侧CDN弹幕同步指标（成功比例、延迟状况）。
  

为了达成秒级监控的目标，数据收集采用了“业务预聚合+数据中心合并”的实时计算方案。即业务服务直接在本地进程内聚合计算指标上报到数据中心，数据中心仅需要按时间窗口合并监控指标数据即可输出到监控大盘。

10、弹幕稳定性设计之故障与应急预案演练

为确保活动顺利完成，弹幕方案还进行了多次故障与应急预案演练措施。

具体包含两个方面。

1）预设故障演练：即针对高可用设计方案的故障演练，按预设有计划的制造故障，主要验证高可用方案是否生效。

2）随机故障演练：无计划的随机制造故障，主要用于检查应急预案、异常监控报警、数据大盘等应急监测机制是否生效。

11、相关资料

[1] 海量实时消息的视频直播系统架构演进之路(视频+PPT)
[2] 百万在线的美拍直播弹幕系统的实时推送技术实践之路
[3] 阿里电商IM消息平台，在群聊、直播场景下的技术实践
[4] 微信直播聊天室单房间1500万在线的消息架构演进之路
[5] 百度直播的海量用户实时消息系统架构演进实践
[6] 百万人在线的直播间实时聊天消息分发技术实践
[7] 直播间海量聊天消息的架构设计难点实践
[8] vivo直播系统中IM消息模块的架构实践
[9] 万人群聊消息投递方案的思考和实践
[10] IM中的万人群聊技术方案实践总结