B站千萬級長連接實時消息系統(tǒng)的架構(gòu)設(shè)計與實踐

Posted on 2024-05-16 11:44 Jack Jiang 閱讀(99) 評論(0) 編輯收藏

本文由嗶哩嗶哩資深開發(fā)工程師黃山成分享，原題“千萬長連消息系統(tǒng)”，本文進行了排版和內(nèi)容優(yōu)化等。

1、引言

在當(dāng)今數(shù)字娛樂時代，彈幕已經(jīng)成為直播平臺上不可或缺的互動元素之一。

用戶通過發(fā)送彈幕、送禮等，可以實時在直播畫面上展現(xiàn)自己的想法、評論和互動內(nèi)容，從而豐富了用戶觀看體驗。在這個過程中，實時向終端推送互動信息，就需要用到長連接。

長連接，顧名思義，是應(yīng)用存活期間和服務(wù)端一直保持的網(wǎng)絡(luò)數(shù)據(jù)通道，能夠支持全雙工上下行數(shù)據(jù)傳輸。其和請求響應(yīng)模式的短連接服務(wù)最大的差異，在于它可以提供服務(wù)端主動給用戶實時推送數(shù)據(jù)的能力。

本文將介紹B站基于golang實現(xiàn)的千萬級長連接實時消息系統(tǒng)的架構(gòu)設(shè)計與實踐，包括長連接服務(wù)的框架設(shè)計，以及針對穩(wěn)定性與高吞吐做的相關(guān)優(yōu)化。

技術(shù)交流：

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

（本文已同步發(fā)布于：http://www.52im.net/thread-4647-1-1.html）

2、關(guān)聯(lián)文章

《B站基于微服務(wù)的API網(wǎng)關(guān)從0到1的演進之路》
《石墨文檔單機50萬WebSocket長連接架構(gòu)實踐》
《百度統(tǒng)一socket長連接組件從0到1的技術(shù)實踐》
《探探的IM長連接技術(shù)實踐：技術(shù)選型、架構(gòu)設(shè)計、性能優(yōu)化》
《愛奇藝WebSocket實時推送網(wǎng)關(guān)技術(shù)實踐》
《LinkedIn的Web端即時通訊實踐：實現(xiàn)單機幾十萬條長連接》
《一個基于長連接的安全可擴展的訂閱/推送服務(wù)實現(xiàn)思路》
《魅族2500萬長連接的實時消息推送架構(gòu)的技術(shù)實踐分享》
《專訪魅族架構(gòu)師：海量長連接的實時消息推送系統(tǒng)的心得體會》

3、架構(gòu)設(shè)計

3.1概述

長連接服務(wù)是多業(yè)務(wù)方共同使用一條長連接。

因為在設(shè)計時，需要考慮到不同業(yè)務(wù)方、不同業(yè)務(wù)場景對長連接服務(wù)的訴求，同時也要考慮長連接服務(wù)的邊界，避免介入業(yè)務(wù)邏輯，影響后續(xù)長連接服務(wù)的迭代和發(fā)展。

長連接服務(wù)主要分為三個方面：

1）長連接建立、維護、管理；
2）下行數(shù)據(jù)推送；
3）上行數(shù)據(jù)轉(zhuǎn)發(fā)（目前只有心跳，還沒實際業(yè)務(wù)場景需求）。

3.2整體架構(gòu)

長連接服務(wù)整體構(gòu)架如上圖所示，整體服務(wù)包含以下幾個部分。

1）控制層：建連的前置調(diào)用，主要做接入合法性校驗、身份校驗和路由管控。

主要職責(zé)：

1）用戶身份鑒權(quán)；
2）加密組裝數(shù)據(jù)，生成合法token；
3）動態(tài)調(diào)度分配接入節(jié)點。

2）接入層：長連接核心服務(wù)，主要做卸載證書、協(xié)議對接和長連接維護。

主要職責(zé)：

1）卸載證書和協(xié)議；
2）負責(zé)和客戶端建立并維護連接，管理連接id和roomid的映射關(guān)系；
3）處理上下行消息。

3）邏輯層：簡化接入層，主要做長連的業(yè)務(wù)功能。

主要職責(zé)：

1）在線人數(shù)上報記錄；
2）記錄連接ID各屬性和各節(jié)點的映射關(guān)系。
4）消息分發(fā)層：消息推送到接入層。

主要職責(zé)：

1）消息封裝、壓縮和聚合推送給相應(yīng)的邊緣節(jié)點；

5）服務(wù)層：業(yè)務(wù)服務(wù)對接層，提供下行消息推送入口。

主要職責(zé)：

1）管控業(yè)務(wù)推送權(quán)限；
2）消息檢測和重組裝；
3）消息按一定策略限流，保護自身系統(tǒng)。

3.3核心流程

長連接主要是3個核心流程：

1）建立連接：由客戶端發(fā)起，先通過控制層，獲取該設(shè)備合法的token和接入點配置；
2）維持連接：主要是客戶端定時發(fā)起心跳，來保證長連接活躍；
3）下行推送：下行推送由業(yè)務(wù)Server發(fā)起，經(jīng)由服務(wù)層根據(jù)相關(guān)標(biāo)識確定連接標(biāo)識和接入節(jié)點，經(jīng)過消息分發(fā)層，把推送到對應(yīng)的接入層，寫入到指定連接上，然后下發(fā)到客戶端。

3.4功能列表

結(jié)合B站業(yè)務(wù)場景，下行數(shù)據(jù)推送，提供如下通用功能：

1）用戶級消息：指定推送給某些用戶（比如給某個主播發(fā)送邀請pk消息）；
2）設(shè)備級消息：制定推送給某些設(shè)備（比如針對未登陸的設(shè)備，推送客戶端日志上報指令）；
3）房間級消息：給某房間內(nèi)的連接推送消息（比如給直播間的所有在線用戶推送彈幕消息）；
4）分區(qū)消息：給某分區(qū)的房間推送消息（比如給某個分區(qū)下，所有開播的房間，推送某個營收活動）；
5）全區(qū)消息：給全平臺用戶推送消息（比如給全部在線用戶推送活動通知）。

4、高吞吐技術(shù)設(shè)計

隨著業(yè)務(wù)發(fā)展壯大，在線用戶越來越多，長連系統(tǒng)的壓力越來越大，尤其是熱門賽事直播，比如s賽期間，全平臺在線人數(shù)快達到千萬，消息吞吐量有上億，長連系統(tǒng)消息分發(fā)平均延遲耗時在1s左右，消息到達率達到99%，下面具體分析下長連做了哪些措施。

4.1網(wǎng)絡(luò)協(xié)議

選擇合適的網(wǎng)絡(luò)協(xié)議對于長連接系統(tǒng)的性能至關(guān)重要：

1）TCP協(xié)議：可以提供可靠的連接和數(shù)據(jù)傳輸，適用于對數(shù)據(jù)可靠性要求較高的場景；
2）UDP協(xié)議：是一個不可靠的協(xié)議，但是傳輸效率高，適用于對數(shù)據(jù)可靠性要求不高的場景；
3）WebSocket協(xié)議：也是實現(xiàn)雙向通信而不增加太多的開銷，更多的用于web端。

接入層拆分成協(xié)議模塊和連接模塊：

1）協(xié)議模塊：和具體的通訊層協(xié)議交互，封裝不同通訊協(xié)議的接口和邏輯差異。
2）連接模塊：維護長連接業(yè)務(wù)連接狀態(tài)，支持請求上行、下行等業(yè)務(wù)邏輯，維護連接各屬性，以及和房間id的綁定關(guān)系。

針對以上第 1）點，協(xié)議模塊同時給連接模塊提供統(tǒng)一的數(shù)據(jù)接口，包括連接建立、數(shù)據(jù)讀取、寫入等。后續(xù)增加新協(xié)議，只要在協(xié)議模塊做適配，不影響其他模塊的長連業(yè)務(wù)邏輯。

優(yōu)勢在于：

1）業(yè)務(wù)邏輯和通訊協(xié)議做了隔離，方便迭代增加通訊協(xié)議，簡化兼容多通訊協(xié)議的實現(xiàn)難度；
2）控制層可以根據(jù)客戶端的實際情況，下發(fā)更優(yōu)的通訊協(xié)議。

4.2負載均衡

采用負載均衡技術(shù)可以將請求分發(fā)到不同的服務(wù)器節(jié)點上處理，避免了單一節(jié)點的負載過高，提高了系統(tǒng)的擴展性和穩(wěn)定性。

長連增加控制層，做負載均衡。控制層提供http短連接口，基于客戶端和各邊緣節(jié)點實際情況，根據(jù)就近原則，動態(tài)選擇合適的接入節(jié)點。

接入層支持水平擴展，控制層可以實時增加、減少分配節(jié)點。在S賽期間，在線人數(shù)快到達千萬時，平衡調(diào)度各接入節(jié)點，保障了各節(jié)點的CPU和內(nèi)存都在穩(wěn)定的范圍內(nèi)。

4.3消息隊列

消息推送鏈路是：業(yè)務(wù)發(fā)送推送，經(jīng)過服務(wù)層推到邊緣節(jié)點，然后下發(fā)給客戶端。

服務(wù)層實時分發(fā)到各邊緣節(jié)點，如果是房間類型消息，需要推到多個邊緣節(jié)點，服務(wù)層同時還要處理業(yè)務(wù)邏輯，很影響消息的吞吐量。

所以增加消息隊列和消息分發(fā)層，消息分發(fā)層維護各邊緣節(jié)點信息和推送消息，提高了系統(tǒng)的并發(fā)處理能力和穩(wěn)定性，避免了因消息推送阻塞而導(dǎo)致的性能問題。

4.4消息聚合

當(dāng)有熱門賽事時，同時在線可能達到千萬級別，一條彈幕消息就要擴散到千萬個終端，假如在線的每個人每秒發(fā)一條，需要發(fā)送消息量就是1kw*1kw，消息量非常大，此時消息分發(fā)層和接入層，壓力都會很大。

分析發(fā)現(xiàn)：這些消息都是同一個房間的，屬于熱點房間，比如s賽房間，觀眾數(shù)量是無法減少的，那只能在消息數(shù)上做文章。業(yè)務(wù)消息推送不能減少，又要減少擴散的消息數(shù)，就想到了消息聚合。

針對房間消息，按照一定的規(guī)則進行消息聚合，批量推送：

消息聚合上線后，消息分發(fā)層對接入層調(diào)用QPS下降60%左右，極大的降低了接入層和消息分發(fā)層的壓力。

4.5壓縮算法

消息聚合后，降低了消息的數(shù)量，但是增加了消息體的大小，影響了寫入IO，需要減少消息體大小，就想到了消息壓縮。

壓縮算法，選了市面上比較常用的兩個：zlib和brotli，進行比較。

抓取了線上業(yè)務(wù)推送的數(shù)據(jù)，選擇最高等級的壓縮等級，進過壓縮驗證：

由此可見，brotli相比zlib有很大的優(yōu)勢，最后選擇了brotli壓縮算法。

選擇在消息分發(fā)層進行消息壓縮，避免在各接入節(jié)點多次重復(fù)壓縮，浪費性能。上線后提升吞吐量的同時，也降低的寬帶使用成本。

5、服務(wù)保障技術(shù)設(shè)計

現(xiàn)在有些業(yè)務(wù)是強依賴長連推送消息，消息丟失，輕則影響用戶體驗，重則阻塞業(yè)務(wù)后續(xù)流程，進而影響業(yè)務(wù)流水。針對長連服務(wù)消息保障，做了如下工作。

5.1多活部署

多活部署，通過在不同地理位置部署相同的系統(tǒng)架構(gòu)和服務(wù)，實現(xiàn)了系統(tǒng)在單一地域故障時的快速故障轉(zhuǎn)移，從而提高了系統(tǒng)的穩(wěn)定性和可用性。

長連服務(wù)部署，主要做了以下幾點：

1）長連接在國內(nèi)華東、華南、華北地域均部署了接入點，支持三大運營商；華南和華中自建機房也部署了接入點；為支持海外用戶，增加了新加坡機房獨立接入點；
2）針對業(yè)務(wù)場景不同，在云上節(jié)點和自建節(jié)點之間，實時切換，因為云上節(jié)點和自建機房的成本是不一樣的，在保證服務(wù)質(zhì)量的前提下，盡可能的控制成本。

目前線上運行過程中，偶爾會遇到單節(jié)點或機房的網(wǎng)絡(luò)抖動，通過控制層，對有問題的節(jié)點，進行秒級摘流，大大減少了對業(yè)務(wù)的影響。

5.2高低消息通道

多業(yè)務(wù)消息接入長連接，但不同消息之間的重要性是不一樣的，比如彈幕消息和邀請pk消息，丟失幾條彈幕對用戶體驗不會影響很大，但如果邀請pk消息丟失，則會導(dǎo)致pk業(yè)務(wù)無法進行后續(xù)的流程。

針對不同等級的消息，采用了高低優(yōu)消息通道。重要消息走高優(yōu)通道，普通消息走低優(yōu)通道。這樣重要和普通消息進行了物理隔離，消息分發(fā)優(yōu)先保證重要消息。

針對高優(yōu)通道，做了雙投遞的保障，在接入層做冪等去重。首先重要消息是針對用戶級別的，量不會很大，所以對接入層的壓力不會增加很大。另外雙投遞的job是部署在多機房的，這也就降低單機房網(wǎng)絡(luò)抖動造成的影響。

高低優(yōu)通道上線后，遇到過內(nèi)網(wǎng)出網(wǎng)抖動，當(dāng)時內(nèi)網(wǎng)部屬的job節(jié)點推送消息異常，而云上高優(yōu)job節(jié)點可正常推送，很好的保障了高優(yōu)消息的到達，進而保障了高優(yōu)業(yè)務(wù)不受影響。

5.3高達功能

高低優(yōu)通道解決的是job到接入層的這一個環(huán)節(jié)，但消息推送聯(lián)路涉及到多個環(huán)節(jié)，比如服務(wù)層到j(luò)ob、接入層到客戶端。

針對整個鏈路，通過實現(xiàn)必達機制來確保終端的到達率，簡稱高達功能。

功能實現(xiàn)：

1）每條消息引入msgID，客戶端收到消息后進行冪等去重和ack回執(zhí)；
2）服務(wù)端針對msgid進行ack檢測，針對未ack的，有效期內(nèi)再次重試下發(fā)。

最終到達率 = (1-(1-r)^(n+1))，其中：r為廣播單次到達率，n為最大重試次數(shù)。

例如：r = 97%、n=2，那么最終到達率可以達到(1-(1-0.97)^(2+1)) = 99.9973%

6、進出”房“消息的送達保證設(shè)計

有些業(yè)務(wù)場景，需要用到用戶進出房消息，比如用戶A進入直播間，頁面會顯示歡迎用戶A進入房間，或者是加入在線榜單。

1）進房消息會存在丟失，需要有補償機制。想到可以通過連接心跳來補償進房消息，但心跳是持續(xù)不斷的，連接在線期間，業(yè)務(wù)希望只收到一次進房消息，所以進房消息需要有冪等機制。

2）出房消息也會存在丟失，如果丟失了，業(yè)務(wù)無法從在線榜單剔除用戶，此時也需要有補償機制。此時就需要增加連接的狀態(tài)機，通過心跳維護狀態(tài)機，當(dāng)心跳丟失時，認為連接斷開，用戶退房。

7、未來規(guī)劃

統(tǒng)一長連接服務(wù)經(jīng)歷數(shù)次迭代后，目前基本功能已經(jīng)趨于穩(wěn)定，后續(xù)對長連接服務(wù)進行改善和優(yōu)化。

主要集中在以下幾個方向：

1）數(shù)據(jù)化：進一步完善長連接全鏈路網(wǎng)絡(luò)質(zhì)量數(shù)據(jù)統(tǒng)計和高價值消息全鏈路追蹤的能力；
2）智能化：端上建聯(lián)、接入點選擇等能夠根據(jù)實際環(huán)境進行自動化調(diào)整；
3）性能優(yōu)化：接入層的連接模塊中，處理上下行消息的攜程進行共享，減少接入層的攜程數(shù)，進一步提升單機性能和連接數(shù)；
4）功能擴展：新增離線消息功能等。