網易實踐｜千萬級在線直播彈幕方案

導讀：8月22日，TFBOYS「日光旅行」七週年演唱會落下帷幕，頂級流量的在線直播，海量彈幕、禮物刷爆屏幕，網易雲信爲這場直播活動提供直播彈幕技術方案。本文將圍繞千萬級在線場景闡述直播彈幕的設計方案。

文｜雲信IM技術團隊

8月22日，TFBOYS「日光旅行」七週年演唱會落下帷幕，36氪評價網易雲音樂舉辦的這場線上演唱會「極可能會成爲線上音樂演出正式走上歷史舞臺的一個標誌性事件」。在這樣一個打破吉尼斯世界紀錄的「標誌性事件」背後，是網易雲信千萬級在線直播間彈幕方案的技術支持。

彈幕技術方案

彈幕方案以雲信聊天室服務爲基礎，提供登陸直播間、發送彈幕、禮物消息等能力；以千萬級在線廣播爲目標，設計了基於CDN的彈幕廣播服務。

直播間收發消息（彈幕、禮物）的基本業務流程以下：

• 獲取直播間接入地址
• 登陸直播間
• 收發消息（彈幕、禮物）

下文將圍繞以上三個階段分別闡述如何實現千萬級在線直播彈幕能力。

獲取直播間接入地址

爲了提供穩定高可用的彈幕服務，須要經過GSLB服務給用戶分配最佳的接入地址。GSLB服務須要從用戶網絡類型、機房網絡容量、服務器負載、成本等維度綜合考慮。

用戶網絡類型和機房網絡容量：爲了用戶可以快速、穩定的登陸直播間收發消息，通常要根據用戶所在地理位置以及網絡運營商類型綜合考慮給用戶分類接入服務器。機房通常提供BGP網絡、三線網絡兩種接入方案，分配服務根據用戶IP地址分析用戶的地域、運營商類型並分配最佳接入地址。通常優先按運營商類型分配三線地址（例如電信用戶分配電信接入地址），若是是小運營商或沒法識別的IP地址則分配BGP地址，兩種接入方式用戶均可以得到穩定的網絡環境。

服務器負載：單臺服務器可以承載的TCP長連接有限，尤爲是在高併發進入直播間的狀況下，握手協議須要完成鏈路加密工做，對系統的CPU資源消耗比較大，所以須要實現一套良好的均衡分配策略。

雲信實現了一套基於服務器負載均衡的分配策略。長連接接入服務器週期性上報當前服務器負載到負載均衡服務集羣，負載信息存儲在共享緩存中，接入分配服務根據負載信息動態分配接入地址。

通常狀況下用戶請求直播間地址，地址分配服務會查詢負載均衡服務（或者直接查詢負載緩存），而後根據獲取到的信息分配當前負載最低的服務器。在千萬級別的在線直播活動場景下，開播時大量用戶併發進入直播間，分配服務可達50萬到100萬TPS，這麼高的TPS下若是還用「通常分配」方案，負載均衡（緩存）服務的TPS和集羣之間的機房網絡帶寬很是高，單臺服務器亦可能由於負載信息滯後致使超負荷分配。爲解決機房內帶寬和超負載分配的問題，咱們對分配方案實現瞭如下優化：

1. 長連接服務器上報負載的週期從1秒調整到5毫秒，負載均衡服務器能夠更實時的同步負載信息
2. 「地址分配」服務再也不按請求查詢負載信息，而是開啓單獨的同步線程週期性（一樣是5毫秒）同步負載數據，從而有效下降負責信息同步的TPS和網絡開銷。
3. 「地址分配」服務不在按最低負載分配，而是將服務接入地址按負載排序，單個接入地址分配必定次數後按順序分配下一個接入地址（避免低負載服務器瞬間被打爆）

在實際方案落地中，須要結合負載、用戶網絡類型、機房線路容量等因素綜合分配。

登陸直播間

登陸直播間主要有兩項任務：握手和身份認證。

握手：SDK創建TCP長連接後，首先向服務器發送握手協議，主要提供SDK版本、協議版本、支持的加密算法等信息，服務器根據SDK提供的信息選擇合適的協議版本以及加密算法，創建安全的通訊鏈路。

雲信支持的非對稱算法包括：RSA，SM2等算法，支持的對稱加密算法包括：AES，SM4等（注：SM二、SM4爲國密算法，即我國自主研發創新的一套數據加密處理系列算法。

雲信做爲業內領先的即時通信PAAS平臺，十分重視信息安全，所以也率先支持了國密算法。）。非對稱加密算法對CPU資源消耗很是高，爲了提升性能通常能夠考慮選擇合適的密鑰長度，另外針對Java平臺建議考慮使用JNI技術提升非對稱加密計算性能。

身份認證：TFBOYS活動是在線付費直播，所以身份認證包含了帳號認證和業務認證兩部分，即用戶必須使用正確的帳號密碼登陸App，且必須付費購買直播門票纔有權限觀看直播。爲優化系統性能，彈幕服務將「地址分配和鑑權」服務進行了特殊優化：

鑑權中心提供用戶進入直播間彈幕服務的身份鑑權策略配置。在TFBOYS活動中採用了動態Token的鑑權機制，即根據用戶帳號、登陸時間、分配的接入地址以及鑑權中心按時間區間生成的「隨機數以及對應的Token算法」動態計算鑑權Token。

用戶打開直播App，首先完成帳號鑑權。在進入TFBOYS直播間時經過業務中心完成直播付費身份認證和彈幕服務地址分配（同步獲取到彈幕服務的動態鑑權token），最後根據接入地址登陸彈幕服務，彈幕服務依據鑑權中心的策略校驗Token正確性。

動態Token鑑權採用進程本地計算的方式，能夠在不訪問用戶服務的狀況下完成身份鑑權，在提升登陸認證的性能同時有效的下降了業務成本。

收發消息（彈幕、禮物）

收發消息是直播間的核心業務，直播間消息主要分爲彈幕和禮物兩類。禮物因涉及付費等因素通常經過客戶方業務服務器發送，彈幕消息則能夠經過聊天室長連接發送。在千萬級直播間場景下，因消息量過高，所以須要從消息量、消息體大小、消息比例等多個方面優化，所以設計了一套基於優先級隊列的彈幕服務。

首先，爲了節約消息產生的帶寬，在大型直播項目開始階段，就須要對消息格式進行優化，充分精簡消息體大小。例如將禮物消息展現相關的資源文件提早預加載到直播App中，禮物消息轉化爲業務編號，可極大的減小消息大小；

其次，針對上行消息設計流控機制。爲了能全局控制上行消息體量，設計了逐級流控方案。上層級根據下層級可以支撐處理能力設計相對較粗粒度的本地流控機制；在彈幕反垃圾業務階段，因須要全局控制消息量，所以採用分佈式全局流控方案；彈幕廣播階段則根據業務廣播需求再一次進行消息流控。

上行消息經過反垃圾監測後被投遞到彈幕服務處理。基於優先級隊列的彈幕服務首先按業務劃分不一樣的消息隊列，例如：系統廣播、高優先級禮物、低優先級、彈幕，而後按隊列分配消息比例，最後根據單位時間（1秒）內用戶須要接收到的消息量計算各個隊列應該投遞的消息數量。在實際投遞消息的過程當中，若前一個隊列消息量不足，可將剩餘的消息數量疊加到下一個隊列，以確保每個週期都發送足夠的消息給用戶。

彈幕可經過長鏈接或CDN廣播給其餘用戶。爲了給用戶提供極致的彈幕體驗，充分發揮邊緣加速的優點，在千萬級在線直播場景下優先選擇CDN方案，以下圖：

基於CDN廣播彈幕有兩種方案：

• 基於推流的方案：相似於直播視頻推流技術，即將消息假裝成視頻流的形式推送到CDN，直播App以訂閱數據流的方式同步彈幕信息；
• 靜態文件加速方案：即彈幕服務將不一樣隊列中的消息組裝成一個靜態文件，直播App週期性的到CDN服務器下載彈幕靜態文件。

相對來講，靜態文件加速方案實現更簡單但實時性不高（取決於彈幕同步的週期時長）；推流的方案消息實時性更高，但實現相對複雜，且須要考慮到不一樣終端的兼容性。實際項目中可根據場景和終端類型靈活選擇不一樣的方案。

爲了保障服務的可靠性，可考慮融合CDN的方案，即同時將消息推送到多家CDN廠商，並結合CDN廠商的容量比例以及網絡延遲狀況綜合調度（例如基於權重的輪巡調度策略）。

彈幕穩定性設計

單元化部署

ChatLink和ChatServer採用單元化部署的方案，有如下優勢：

1. 單元內依賴的核心服務單元之間相互獨立，水平擴展能力好，且單元內服務故障不影響其餘單元，能夠有效避免整個服務不可用的問題；
2. 跨機房部署，避免單個機房容量不足，或單機房不可用問題；
3. 彈幕方案採用了單元無狀態的設計理念，所以不須要考慮單元之間同步數據的問題。

單個直播間的「接入服務」和「彈幕服務」因須要全局控制未採用單元化部署方案，可是在實施階段採用了跨機房部署的方案（包括依賴的存儲資源、服務），能夠避免單個機房故障致使服務不可用的問題。

單點服務高可用

針對「接入服務」和「彈幕服務」，除了採用跨機房部署外，在服務設計上核心依賴的存儲資源、服務，採用主備模式。例如心跳負載依賴的緩存服務，單個緩存實例自己高可用，但考慮到極端狀況（例如緩存集羣內超過一半的服務器宕機致使服務不可用），所以採用主備緩存集羣方案，當主集羣不可用後，業務主動切換到備用集羣，可保障業務在5秒內恢復正常。

系統監控與數據大盤

爲了實時瞭解系統運行狀態，在彈幕方案中實現了秒級數據大盤方案。監控大盤圍繞用戶和消息，展現用戶地域分佈變化、上行消息量、廣播消息量、機房出口帶寬、CDN帶寬、消息流控比例，端側CDN彈幕同步指標（成功比例、延遲情況）等信息。

爲了達成秒級監控的目標，數據收集採用了「業務預聚合+數據中心合併」的實時計算方案。即業務服務直接在本地進程內聚合計算指標上報到數據中心，數據中心僅須要按時間窗口合併監控指標數據便可輸出到監控大盤。

故障與應急預案演練

爲確保活動順利完成，彈幕方案進行了屢次故障與應急預案演練措施。具體包含兩個方面：

1. 預設故障演練：即針對高可用設計方案的故障演練，按預設有計劃的製造故障，主要驗證高可用方案是否生效。
2. 隨機故障演練：無計劃的隨機制造故障，主要用於檢查應急預案、異常監控報警、數據大盤等應急監測機制是否生效。

**結束語
**

憑藉超過20年的技術累積和5年企業融合通訊經驗，網易雲信在線直播彈幕方案在TFBOYS「日光旅行」七週年演唱會上以0故障的佳績交上了一份滿意的答卷，攜手網易雲音樂共同成就了這場口碑票房雙豐收的線上演唱會。