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

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

1、引言

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

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

技术交流：

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4299-1-1.html）

2、系列文章

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

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方案（如下图所示）。