直播系統(tǒng)聊天技術(shù)(九)：千萬(wàn)級(jí)實(shí)時(shí)直播彈幕的技術(shù)實(shí)踐
本文由云信IM技術(shù)團(tuán)隊(duì)分享，原題“千萬(wàn)級(jí)在線直播彈幕方案”，本文有修訂和改動(dòng)。
1、引言
疫情期間，線上演唱會(huì)是一種很常見的直播娛樂(lè)形式，由于線下社交距離的限制，線上形式演唱會(huì)比以往更火爆，而對(duì)技術(shù)的要求也更高。
本文基于網(wǎng)易云信針對(duì)TFBOYS某場(chǎng)線上演唱會(huì)的技術(shù)支持，為你分享千萬(wàn)級(jí)在線用戶量的直播系統(tǒng)中實(shí)時(shí)彈幕功能的技術(shù)實(shí)踐，希望能帶給你啟發(fā)。
?技術(shù)交流：
- 移動(dòng)端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動(dòng)端IM》
- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點(diǎn)此）
（本文已同步發(fā)布于：http://www.52im.net/thread-4299-1-1.html）
2、系列文章
本文是系列文章中的第?9?篇：
《直播系統(tǒng)聊天技術(shù)(一)：百萬(wàn)在線的美拍直播彈幕系統(tǒng)的實(shí)時(shí)推送技術(shù)實(shí)踐之路》
《直播系統(tǒng)聊天技術(shù)(二)：阿里電商IM消息平臺(tái)，在群聊、直播場(chǎng)景下的技術(shù)實(shí)踐》
《直播系統(tǒng)聊天技術(shù)(三)：微信直播聊天室單房間1500萬(wàn)在線的消息架構(gòu)演進(jìn)之路》
《直播系統(tǒng)聊天技術(shù)(四)：百度直播的海量用戶實(shí)時(shí)消息系統(tǒng)架構(gòu)演進(jìn)實(shí)踐》
《直播系統(tǒng)聊天技術(shù)(五)：微信小游戲直播在Android端的跨進(jìn)程渲染推流實(shí)踐》
《直播系統(tǒng)聊天技術(shù)(六)：百萬(wàn)人在線的直播間實(shí)時(shí)聊天消息分發(fā)技術(shù)實(shí)踐》
《直播系統(tǒng)聊天技術(shù)(七)：直播間海量聊天消息的架構(gòu)設(shè)計(jì)難點(diǎn)實(shí)踐》
《直播系統(tǒng)聊天技術(shù)(八)：vivo直播系統(tǒng)中IM消息模塊的架構(gòu)實(shí)踐》
《直播系統(tǒng)聊天技術(shù)(九)：千萬(wàn)級(jí)實(shí)時(shí)直播彈幕的技術(shù)實(shí)踐》（* 本文）
3、彈幕整體技術(shù)方案
本次的彈幕方案以IM聊天室技術(shù)為基礎(chǔ)，提供了登錄直播間、發(fā)送彈幕、禮物消息等能力。同時(shí)按照千萬(wàn)級(jí)在線廣播的目標(biāo)，為期設(shè)計(jì)了基于CDN的彈幕廣播服務(wù)。
直播間收發(fā)實(shí)時(shí)消息（也就是彈幕、禮物）的主要流程如下：
1）獲取直播間接入地址；
2）登錄直播間；
3）收發(fā)消息（彈幕、禮物）。
下面將圍繞以上流程的三個(gè)階段，在技術(shù)上分別闡述如何實(shí)現(xiàn)千萬(wàn)級(jí)在線直播實(shí)時(shí)彈幕的能力。
4、彈幕技術(shù)方案之獲取直播間接入地址
為了提供穩(wěn)定高可用的實(shí)時(shí)彈幕服務(wù)，需要通過(guò)GSLB（Global Server Load Balancing）服務(wù)給用戶分配最佳的接入地址。
GSLB服務(wù)需要從以下幾個(gè)維度綜合考慮：
1）用戶網(wǎng)絡(luò)類型；
2）機(jī)房網(wǎng)絡(luò)容量；
3）服務(wù)器負(fù)載；
4）成本。
1）用戶網(wǎng)絡(luò)類型和機(jī)房網(wǎng)絡(luò)容量：
為了用戶能夠快速、穩(wěn)定的登錄直播間收發(fā)消息，一般要根據(jù)用戶所在地理位置以及網(wǎng)絡(luò)運(yùn)營(yíng)商類型綜合考慮給用戶分類接入服務(wù)器。
機(jī)房一般提供BGP網(wǎng)絡(luò)、三線網(wǎng)絡(luò)兩種接入方案，分配服務(wù)根據(jù)用戶IP地址分析用戶的地域、運(yùn)營(yíng)商類型并分配最佳接入地址。
一般優(yōu)先按運(yùn)營(yíng)商類型分配三線地址（例如電信用戶分配電信接入地址），如果是小運(yùn)營(yíng)商或無(wú)法識(shí)別的IP地址則分配BGP地址，兩種接入方式用戶都可以獲得穩(wěn)定的網(wǎng)絡(luò)環(huán)境。
2）服務(wù)器負(fù)載：
單臺(tái)服務(wù)器能夠承載的TCP長(zhǎng)鏈接有限，尤其是在高并發(fā)進(jìn)入直播間的情況下，握手協(xié)議需要完成鏈路加密工作，對(duì)系統(tǒng)的CPU資源消耗比較大，因此需要實(shí)現(xiàn)一套良好的均衡分配策略。
3）一套基于服務(wù)器負(fù)載均衡的分配策略：
長(zhǎng)鏈接接入服務(wù)器周期性上報(bào)當(dāng)前服務(wù)器負(fù)載到負(fù)載均衡服務(wù)集群，負(fù)載信息存儲(chǔ)在共享緩存中，接入分配服務(wù)根據(jù)負(fù)載信息動(dòng)態(tài)分配接入地址。
一般情況下用戶請(qǐng)求直播間地址，地址分配服務(wù)會(huì)查詢負(fù)載均衡服務(wù)（或者直接查詢負(fù)載緩存），然后根據(jù)獲取到的信息分配當(dāng)前負(fù)載最低的服務(wù)器。
在千萬(wàn)級(jí)別的在線直播活動(dòng)場(chǎng)景下，開播時(shí)大量用戶并發(fā)進(jìn)入直播間，分配服務(wù)可達(dá)50萬(wàn)到100萬(wàn)TPS，這么高的TPS下如果還用“一般分配”方案，負(fù)載均衡（緩存）服務(wù)的TPS和集群之間的機(jī)房網(wǎng)絡(luò)帶寬非常高，單臺(tái)服務(wù)器亦可能因?yàn)樨?fù)載信息滯后導(dǎo)致超負(fù)荷分配。
為解決機(jī)房?jī)?nèi)帶寬和超負(fù)載分配的問(wèn)題，我們對(duì)分配方案進(jìn)行了優(yōu)化：
1）長(zhǎng)鏈接服務(wù)器上報(bào)負(fù)載的周期從1秒調(diào)整到5毫秒，負(fù)載均衡服務(wù)器可以更實(shí)時(shí)的同步負(fù)載信息；
2）“地址分配”服務(wù)不再按請(qǐng)求查詢負(fù)載信息，而是開啟單獨(dú)的同步線程周期性（同樣是5毫秒）同步負(fù)載數(shù)據(jù)，從而有效降低負(fù)責(zé)信息同步的TPS和網(wǎng)絡(luò)開銷；
3）“地址分配”服務(wù)不在按最低負(fù)載分配，而是將服務(wù)接入地址按負(fù)載排序，單個(gè)接入地址分配一定次數(shù)后按順序分配下一個(gè)接入地址（避免低負(fù)載服務(wù)器瞬間被打爆）。
在實(shí)際方案落地中，需要結(jié)合負(fù)載、用戶網(wǎng)絡(luò)類型、機(jī)房線路容量等因素綜合分配。
5、彈幕技術(shù)方案之登錄直播間
登錄直播間主要有兩項(xiàng)任務(wù)：
1）握手；
2）身份認(rèn)證。
1）握手：
SDK建立TCP長(zhǎng)鏈接后，首先向服務(wù)器發(fā)送握手協(xié)議，主要提供SDK版本、協(xié)議版本、支持的加密算法等信息，服務(wù)器根據(jù)SDK提供的信息選擇合適的協(xié)議版本以及加密算法，建立安全的通信鏈路。
我們支持的非對(duì)稱算法包括：RSA、SM2等算法。支持的對(duì)稱加密算法包括：AES，SM4等（SM2、SM4為國(guó)密算法）。
非對(duì)稱加密算法對(duì)CPU資源消耗非常高，為了提高性能一般可以考慮選擇合適的密鑰長(zhǎng)度，另外針對(duì)Java平臺(tái)建議考慮使用JNI技術(shù)提高非對(duì)稱加密計(jì)算性能。
2）身份認(rèn)證：
引言中提到的該次直播活動(dòng)是在線付費(fèi)直播，因此身份認(rèn)證包含了賬號(hào)認(rèn)證和業(yè)務(wù)認(rèn)證兩部分，即用戶必須使用正確的賬號(hào)密碼登錄App，且必須付費(fèi)購(gòu)買直播門票才有權(quán)限觀看直播。
為優(yōu)化系統(tǒng)性能，實(shí)時(shí)彈幕服務(wù)將“地址分配和鑒權(quán)”服務(wù)進(jìn)行了特殊優(yōu)化：
鑒權(quán)中心提供用戶進(jìn)入直播間彈幕服務(wù)的身份鑒權(quán)策略配置。在該次直播活動(dòng)中采用了動(dòng)態(tài)Token的鑒權(quán)機(jī)制，即根據(jù)用戶賬號(hào)、登錄時(shí)間、分配的接入地址以及鑒權(quán)中心按時(shí)間區(qū)間生成的“隨機(jī)數(shù)以及對(duì)應(yīng)的Token算法”動(dòng)態(tài)計(jì)算鑒權(quán)Token。
用戶打開直播App，首先完成賬號(hào)鑒權(quán)。在進(jìn)入直播間時(shí)通過(guò)業(yè)務(wù)中心完成直播付費(fèi)身份認(rèn)證和彈幕服務(wù)地址分配（同步獲取到彈幕服務(wù)的動(dòng)態(tài)鑒權(quán)token），最后根據(jù)接入地址登錄彈幕服務(wù)，彈幕服務(wù)依據(jù)鑒權(quán)中心的策略校驗(yàn)Token正確性。
動(dòng)態(tài)Token鑒權(quán)采用進(jìn)程本地計(jì)算的方式。可以在不訪問(wèn)用戶服務(wù)的情況下完成身份鑒權(quán)，在提高登錄認(rèn)證的性能同時(shí)有效的降低了業(yè)務(wù)成本。
6、彈幕技術(shù)方案之收發(fā)消息（彈幕、禮物）
實(shí)時(shí)收發(fā)消息是直播間的核心業(yè)務(wù)，主要分為彈幕和禮物兩類：
1）禮物因涉及付費(fèi)等因素一般通過(guò)客戶方業(yè)務(wù)服務(wù)器發(fā)送；
2）彈幕消息則可以通過(guò)聊天室長(zhǎng)鏈接發(fā)送。
在千萬(wàn)級(jí)直播間場(chǎng)景下，因消息量太高，因此需要從消息量、消息體大小、消息比例等多個(gè)方面優(yōu)化，因此我們?cè)O(shè)計(jì)了一套基于優(yōu)先級(jí)隊(duì)列的彈幕服務(wù)。
首先：為了節(jié)約消息產(chǎn)生的帶寬，在大型直播項(xiàng)目開始階段，就需要對(duì)消息格式進(jìn)行優(yōu)化，充分精簡(jiǎn)消息體大小。例如將禮物消息展示相關(guān)的資源文件提前預(yù)加載到直播App中，禮物消息轉(zhuǎn)化為業(yè)務(wù)編號(hào)，可極大的減少消息大??；
其次：針對(duì)上行消息設(shè)計(jì)流控機(jī)制。為了能全局控制上行消息體量，設(shè)計(jì)了逐級(jí)流控方案。上層級(jí)根據(jù)下層級(jí)能夠支撐處理能力設(shè)計(jì)相對(duì)較粗粒度的本地流控機(jī)制。在彈幕反垃圾業(yè)務(wù)階段，因需要全局控制消息量，因此采用分布式全局流控方案；彈幕廣播階段則根據(jù)業(yè)務(wù)廣播需求再一次進(jìn)行消息流控。
上行消息通過(guò)反垃圾監(jiān)測(cè)后被投遞到彈幕服務(wù)處理。基于優(yōu)先級(jí)隊(duì)列的彈幕服務(wù)首先按業(yè)務(wù)劃分不同的消息隊(duì)列，例如：系統(tǒng)廣播、高優(yōu)先級(jí)禮物、低優(yōu)先級(jí)、彈幕，然后按隊(duì)列分配消息比例，最后根據(jù)單位時(shí)間（1秒）內(nèi)用戶需要接收到的消息量計(jì)算各個(gè)隊(duì)列應(yīng)該投遞的消息數(shù)量。在實(shí)際投遞消息的過(guò)程中，若前一個(gè)隊(duì)列消息量不足，可將剩余的消息數(shù)量疊加到下一個(gè)隊(duì)列，以確保每一個(gè)周期都發(fā)送足夠的消息給用戶。
彈幕可通過(guò)長(zhǎng)連接或CDN廣播給其他用戶。為了給用戶提供極致的彈幕體驗(yàn)，充分發(fā)揮邊緣加速的優(yōu)勢(shì)，在千萬(wàn)級(jí)在線直播場(chǎng)景下優(yōu)先選擇CDN方案（如下圖所示）。
基于CDN廣播彈幕有兩種方案：
1）基于推流的方案：類似于直播視頻推流技術(shù)，即將消息偽裝成視頻流的形式推送到CDN，直播App以訂閱數(shù)據(jù)流的方式同步彈幕信息；
2）靜態(tài)文件加速方案：即彈幕服務(wù)將不同隊(duì)列中的消息組裝成一個(gè)靜態(tài)文件，直播App周期性的到CDN服務(wù)器下載彈幕靜態(tài)文件。
相對(duì)來(lái)說(shuō)：
1）靜態(tài)文件加速方案實(shí)現(xiàn)更簡(jiǎn)單但實(shí)時(shí)性不高（取決于彈幕同步的周期時(shí)長(zhǎng)）；
2）推流的方案消息實(shí)時(shí)性更高，但實(shí)現(xiàn)相對(duì)復(fù)雜，且需要考慮到不同終端的兼容性。
實(shí)際項(xiàng)目中可根據(jù)場(chǎng)景和終端類型靈活選擇不同的方案。
為了保障服務(wù)的可靠性，可考慮融合CDN的方案，即同時(shí)將消息推送到多家CDN廠商，并結(jié)合CDN廠商的容量比例以及網(wǎng)絡(luò)延遲情況綜合調(diào)度（例如基于權(quán)重的輪巡調(diào)度策略）。
7、彈幕穩(wěn)定性設(shè)計(jì)之單元化部署
ChatLink和ChatServer采用單元化部署的方案，有以下優(yōu)點(diǎn)：
1）單元內(nèi)依賴的核心服務(wù)單元之間相互獨(dú)立，水平擴(kuò)展能力好，且單元內(nèi)服務(wù)故障不影響其他單元，可以有效避免整個(gè)服務(wù)不可用的問(wèn)題；
2）跨機(jī)房部署，避免單個(gè)機(jī)房容量不足，或單機(jī)房不可用問(wèn)題；
3）彈幕方案采用了單元無(wú)狀態(tài)的設(shè)計(jì)理念，因此不需要考慮單元之間同步數(shù)據(jù)的問(wèn)題。
單個(gè)直播間的“接入服務(wù)”和“彈幕服務(wù)”因需要全局控制未采用單元化部署方案，但是在實(shí)施階段采用了跨機(jī)房部署的方案（包括依賴的存儲(chǔ)資源、服務(wù)），可以避免單個(gè)機(jī)房故障導(dǎo)致服務(wù)不可用的問(wèn)題。
8、彈幕穩(wěn)定性設(shè)計(jì)之單點(diǎn)服務(wù)高可用
針對(duì)“接入服務(wù)”和“彈幕服務(wù)”，除了采用跨機(jī)房部署外，在服務(wù)設(shè)計(jì)上核心依賴的存儲(chǔ)資源、服務(wù)，采用主備模式。
例如：心跳負(fù)載依賴的緩存服務(wù)，單個(gè)緩存實(shí)例本身高可用，但考慮到極端情況（例如緩存集群內(nèi)超過(guò)一半的服務(wù)器宕機(jī)導(dǎo)致服務(wù)不可用），因此采用主備緩存集群方案，當(dāng)主集群不可用后，業(yè)務(wù)主動(dòng)切換到備用集群，可保障業(yè)務(wù)在5秒內(nèi)恢復(fù)正常。
9、幕穩(wěn)定性設(shè)計(jì)之系統(tǒng)監(jiān)控與數(shù)據(jù)大盤
為了實(shí)時(shí)了解系統(tǒng)運(yùn)行狀態(tài)，在彈幕方案中實(shí)現(xiàn)了秒級(jí)數(shù)據(jù)大盤方案。
監(jiān)控大盤圍繞用戶和消息主要展示以下信息：
1）用戶地域分布變化；
2）上行消息量；
3）廣播消息量；
4）機(jī)房出口帶寬；
5）CDN帶寬；
6）消息流控比例；
7）端側(cè)CDN彈幕同步指標(biāo)（成功比例、延遲狀況）。
為了達(dá)成秒級(jí)監(jiān)控的目標(biāo)，數(shù)據(jù)收集采用了“業(yè)務(wù)預(yù)聚合+數(shù)據(jù)中心合并”的實(shí)時(shí)計(jì)算方案。即業(yè)務(wù)服務(wù)直接在本地進(jìn)程內(nèi)聚合計(jì)算指標(biāo)上報(bào)到數(shù)據(jù)中心，數(shù)據(jù)中心僅需要按時(shí)間窗口合并監(jiān)控指標(biāo)數(shù)據(jù)即可輸出到監(jiān)控大盤。
10、彈幕穩(wěn)定性設(shè)計(jì)之故障與應(yīng)急預(yù)案演練
為確?；顒?dòng)順利完成，彈幕方案還進(jìn)行了多次故障與應(yīng)急預(yù)案演練措施。
具體包含兩個(gè)方面。
1）預(yù)設(shè)故障演練：即針對(duì)高可用設(shè)計(jì)方案的故障演練，按預(yù)設(shè)有計(jì)劃的制造故障，主要驗(yàn)證高可用方案是否生效。
2）隨機(jī)故障演練：無(wú)計(jì)劃的隨機(jī)制造故障，主要用于檢查應(yīng)急預(yù)案、異常監(jiān)控報(bào)警、數(shù)據(jù)大盤等應(yīng)急監(jiān)測(cè)機(jī)制是否生效。
11、相關(guān)資料
[1]?海量實(shí)時(shí)消息的視頻直播系統(tǒng)架構(gòu)演進(jìn)之路(視頻+PPT)
[2]?百萬(wàn)在線的美拍直播彈幕系統(tǒng)的實(shí)時(shí)推送技術(shù)實(shí)踐之路
[3]?阿里電商IM消息平臺(tái)，在群聊、直播場(chǎng)景下的技術(shù)實(shí)踐
[4]?微信直播聊天室單房間1500萬(wàn)在線的消息架構(gòu)演進(jìn)之路
[5]?百度直播的海量用戶實(shí)時(shí)消息系統(tǒng)架構(gòu)演進(jìn)實(shí)踐
[6]?百萬(wàn)人在線的直播間實(shí)時(shí)聊天消息分發(fā)技術(shù)實(shí)踐
[7]?直播間海量聊天消息的架構(gòu)設(shè)計(jì)難點(diǎn)實(shí)踐
[8]?vivo直播系統(tǒng)中IM消息模塊的架構(gòu)實(shí)踐
[9]?萬(wàn)人群聊消息投遞方案的思考和實(shí)踐
[10]?IM中的萬(wàn)人群聊技術(shù)方案實(shí)踐總結(jié)
（本文已同步發(fā)布于：http://www.52im.net/thread-4299-1-1.html）
