直播系統聊天技術(九)：千萬級實時直播彈幕的技術實踐

Posted on 2023-06-29 11:32 Jack Jiang 閱讀(102) 評論(0) 編輯收藏

本文由云信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方案（如下圖所示）。