共计 4700 个字符，预计需要花费 12 分钟才能阅读完成。
本文由云信 IM 技术团队分享，原题“千万级在线直播弹幕计划”，本文有订正和改变。
1、引言
疫情期间，线上演唱会是一种很常见的直播娱乐模式，因为线下社交间隔的限度，线上模式演唱会比以往更火爆，而对技术的要求也更高。本文基于网易云信针对 TFBOYS 某场线上演唱会的技术支持，为你分享千万级在线用户量的直播零碎中实时弹幕性能的技术实际，心愿能带给你启发。
技术交换：
- 挪动端 IM 开发入门文章：《新手入门一篇就够：从零开发挪动端 IM》
- 开源 IM 框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）
（本文已同步公布于：http://www.52im.net/thread-4299-1-1.html）
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 弹幕同步指标（胜利比例、提早情况 7）端侧 CDN 弹幕同步指标（胜利比例、提早情况）。
为了达成秒级监控的指标，数据收集采纳了“业务预聚合 + 数据中心合并”的实时计算计划。即业务服务间接在本地过程内聚合计算指标上报到数据中心，数据中心仅须要按工夫窗口合并监控指标数据即可输入到监控大盘。
10、弹幕稳定性设计之故障与应急预案演练
为确保流动顺利完成，弹幕计划还进行了屡次故障与应急预案演练措施。具体蕴含两个方面。
1）预设故障演练：即针对高可用设计方案的故障演练，按预设有打算的制作故障，次要验证高可用计划是否失效。
2）随机故障演练：无打算的随机制作故障，次要用于查看应急预案、异样监控报警、数据大盘等应急监测机制是否失效。
11、相干材料
[1] 海量实时音讯的视频直播零碎架构演进之路 (视频 +PPT)
[2] 百万在线的美拍直播弹幕零碎的实时推送技术实际之路
[3] 阿里电商 IM 音讯平台，在群聊、直播场景下的技术实际
[4] 微信直播聊天室单房间 1500 万在线的音讯架构演进之路
[5] 百度直播的海量用户实时音讯零碎架构演进实际
[6] 百万人在线的直播间实时聊天音讯散发技术实际
[7] 直播间海量聊天音讯的架构设计难点实际
[8] vivo 直播零碎中 IM 音讯模块的架构实际
[9] 万人群聊音讯投递计划的思考和实际
[10] IM 中的万人群聊技术计划实际总结
（本文已同步公布于：http://www.52im.net/thread-4299-1-1.html）