直播系統(tǒng)聊天技術(shù)(六)：百萬人在線的直播間實時聊天消息分發(fā)技術(shù)實踐
本文由融云技術(shù)團隊原創(chuàng)分享，原題“聊天室海量消息分發(fā)之消息丟棄策略”，內(nèi)容有修訂。
1、引言
隨著直播類應(yīng)用的普及，尤其直播帶貨概念的風(fēng)靡，大用戶量的直播間場景已然常態(tài)化。
大用戶量直播間中的實時互動是非常頻繁的，具體體現(xiàn)在技術(shù)上就是各種用戶聊天、彈幕、禮物、點贊、禁言、系統(tǒng)通知等實時消息（就像下圖這樣）。
▲ 某電商APP的賣貨直播間
如此大量的實時消息，在分發(fā)時如何處理才能不至于把服務(wù)端搞垮，而到了客戶端時也不至于讓APP出現(xiàn)瘋狂刷屏和卡頓（不至于影響用戶體驗），這顯然需要特殊的技術(shù)手段和實現(xiàn)策略才能應(yīng)對。
其實，直播間中的實時消息分發(fā)，在技術(shù)上是跟傳統(tǒng)的在線聊天室這種概念是一樣的，只是傳統(tǒng)互聯(lián)網(wǎng)時代，聊天室同時在線的用戶量不會這么大而已，雖然量級不同，但技術(shù)模型是完全可以套用的。
本文將基于直播技術(shù)實踐的背景，分享了單直播間百萬用戶在線量的實時消息分發(fā)的技術(shù)經(jīng)驗總結(jié)，希望帶給你啟發(fā)。
學(xué)習(xí)交流：
- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》
- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK?
（本文已同步發(fā)布于：http://www.52im.net/thread-3799-1-1.html）
2、系列文章
本文是系列文章中的第6篇：
《直播系統(tǒng)聊天技術(shù)(一)：百萬在線的美拍直播彈幕系統(tǒng)的實時推送技術(shù)實踐之路》
《直播系統(tǒng)聊天技術(shù)(二)：阿里電商IM消息平臺，在群聊、直播場景下的技術(shù)實踐》
《直播系統(tǒng)聊天技術(shù)(三)：微信直播聊天室單房間1500萬在線的消息架構(gòu)演進(jìn)之路》
《直播系統(tǒng)聊天技術(shù)(四)：百度直播的海量用戶實時消息系統(tǒng)架構(gòu)演進(jìn)實踐》
《直播系統(tǒng)聊天技術(shù)(五)：微信小游戲直播在Android端的跨進(jìn)程渲染推流實踐》
《直播系統(tǒng)聊天技術(shù)(六)：百萬人在線的直播間實時聊天消息分發(fā)技術(shù)實踐》（* 本文）
3、技術(shù)挑戰(zhàn)
我們以一個百萬人觀看的直播間為例進(jìn)行分析，看看需要面臨哪些技術(shù)挑戰(zhàn)。
1）在直播中會有一波一波的消息高峰，比如直播中的“刷屏”消息，即大量用戶在同一時段發(fā)送的海量實時消息，一般情況下此類“刷屏”消息的消息內(nèi)容基本相同。如果將所有消息全部展示在客戶端，則客戶端很可能出現(xiàn)卡頓、消息延遲等問題，嚴(yán)重影響用戶體驗。
2）海量消息的情況下，如果服務(wù)端每條消息都長期存儲將導(dǎo)致服務(wù)緩存使用量激增，使得內(nèi)存、存儲成為性能瓶頸。
3）在另外一些場景下，比如直播間的房間管理員進(jìn)行操作后的通知消息或者系統(tǒng)通知，一般情況下這類消息是較為重要的，如何優(yōu)先保障它的到達(dá)率。
基于這些挑戰(zhàn)，我們的服務(wù)需要做一個基于業(yè)務(wù)場景的優(yōu)化來應(yīng)對。
4、架構(gòu)模型
我們的架構(gòu)模型圖如下：
?
如上圖所示，下面將針對主要服務(wù)進(jìn)行簡要說明。
1）直播間服務(wù)：
主要作用是：緩存直播間的基本信息。包括用戶列表、禁言/封禁關(guān)系、白名單用戶等。
2）消息服務(wù)：
主要作用是：緩存本節(jié)點需要處理的用戶關(guān)系信息、消息隊列信息等。
具體說是以下兩個主要事情。
直播間用戶關(guān)系同步：
a）成員主動加入退出時：直播間服務(wù)同步至==> 消息服務(wù)；
b）分發(fā)消息發(fā)現(xiàn)用戶已離線時：消息服務(wù)同步至==> 直播間服務(wù)。
發(fā)送消息：? ?
a）直播間服務(wù)經(jīng)過必要校驗通過后將消息廣播至消息服務(wù)；
b）直播間服務(wù)不緩存消息內(nèi)容。
3）Zk（就是?Zookeeper?啦）：
主要作用就是：將各服務(wù)實例均注冊到 Zk，數(shù)據(jù)用于服務(wù)間流轉(zhuǎn)時的落點計算。
具體就是：
a）直播間服務(wù)：按照直播間 ID 落點；
b）消息服務(wù)：按照用戶 ID 落點。
4）Redis：
主要作為二級緩存，以及服務(wù)更新（重啟）時內(nèi)存數(shù)據(jù)的備份。
5、消息分發(fā)總體方案
直播間服務(wù)的消息分發(fā)完整邏輯主要包括：消息分發(fā)流程和消息拉取流程。
5.1 消息分發(fā)流程
如上圖所示，我們的消息分發(fā)流程主要是以下幾步：
1）用戶 A 在直播間中發(fā)送一條消息，首先由直播間服務(wù)處理；
2）直播間服務(wù)將消息同步到各消息服務(wù)節(jié)點；
3）消息服務(wù)向本節(jié)點緩存的所有成員下發(fā)通知拉?。?/p>
4）如上圖中的“消息服務(wù)-1”，將向用戶 B 下發(fā)通知。
另外，因為消息量過大，我們在在分發(fā)的過程中，是具有通知合并機制的，通知合并機制主要提現(xiàn)在上述步驟?3?中。
上述步驟3的通知合并機制原理如下：
a）將所有成員加入到待通知隊列中（如已存在則更新通知消息時間）；
b）下發(fā)線程，輪訓(xùn)獲取待通知隊列；
c）向隊列中用戶下發(fā)通知拉取。
通過通知合并機制，我們可以可保障下發(fā)線程一輪只會向同一用戶發(fā)送一個通知拉取，即多個消息會合并為一個通知拉取，從面有效提升了服務(wù)端性能且降低了客戶端與服務(wù)端的網(wǎng)絡(luò)消耗。
PS：以上通知合并機制，在大消息量的情況下，非常適合使用Actor分布式算法來實現(xiàn)，有興趣的同學(xué)可以進(jìn)一步學(xué)習(xí)《分布式高并發(fā)下Actor模型如此優(yōu)秀》、《分布式計算技術(shù)之Actor計算模式》。
5.2 消息拉取流程
?
如上圖所示，我們的消息拉取流程主要是以下幾步：
1）用戶 B 收到通知后將向服務(wù)端發(fā)送拉取消息請求；
2）該請求將由“消息服務(wù)-1”節(jié)點處理；
3）“消息服務(wù)-1”將根據(jù)客戶端傳遞的最后一條消息時間戳，從消息隊列中返回消息列表（原理詳見下圖 ▼）；
4）用戶 B 獲取到新的消息。
上述步驟?3?中拉取消息的具體邏輯如下圖所示：
6、消息分發(fā)的丟棄策略
對于直播間中的用戶來說，很多消息其實并沒有太多實際意義，比如大量重復(fù)的刷屏消息和動態(tài)通知等等，為了提升用戶體驗，這類消息是可以有策略地進(jìn)行丟棄的（這是跟IM中的實時聊天消息最大的不同，IM中是不允許丟消息的）。
PS：直播間中消息分發(fā)的丟棄策略，跟上節(jié)中的通知合并機制一起，使得直接間海量消息的穩(wěn)定、流暢分發(fā)得以成為可能。
我們的丟棄策略主要由以下3部分組成：
1）上行限速控制（丟棄）策略；
2）下行限速控制（丟棄）策略；
3）重要消息防丟棄策略。
如下圖所示：
我們來逐個解釋一下。
1）上行限速控制（丟棄）策略：
針對上行的限速控制，我們默認(rèn)是 200 條/秒，根據(jù)業(yè)務(wù)需要可調(diào)整。達(dá)到限速后發(fā)送的消息將在直播間服務(wù)丟棄，不再向各消息服務(wù)節(jié)點同步。
2）下行限速控制（丟棄）策略：
針對下行的限速控制，即對消息環(huán)形隊列（見“5.2 消息拉取流程”中的拉取消息詳細(xì)邏輯圖）長度的控制，達(dá)到最大值后最“老”的消息將被淘汰丟棄。
每次下發(fā)通知拉取后服務(wù)端將該用戶標(biāo)記為“拉取中”，用戶實際拉取消息后移除該標(biāo)記。
拉取中標(biāo)記的作用：例如產(chǎn)生新消息時用戶具有拉取中標(biāo)記，如果距設(shè)置標(biāo)記時間在 2 秒內(nèi)則不會下發(fā)通知（降低客戶端壓力，丟棄通知未丟棄消息），超過 2 秒則繼續(xù)下發(fā)通知（連續(xù)多次通知未拉取則觸發(fā)用戶踢出策略，不在此贅述）。
因此消息是否被丟棄取決于客戶端拉取速度（受客戶端性能、網(wǎng)絡(luò)影響），客戶端及時拉取消息則沒有被丟棄的消息。
3）重要消息防丟棄策略：
如前文所述：在直播間場景下對某些消息應(yīng)具有較高優(yōu)先級，不應(yīng)丟棄。
例如：直播間的房間管理員進(jìn)行操作后的通知消息或者系統(tǒng)通知。
針對此場景：我們設(shè)置了消息白名單、消息優(yōu)先級的概念，保障不丟棄。如本節(jié)開始的圖所示，消息環(huán)形隊列可以為多個，與普通直播間消息分開則保障了重要消息不丟棄。
通過上述“1）上行限速控制（丟棄）策略”和“下行限速控制（丟棄）策略”保障了：
1）客戶端不會因為海量消息出現(xiàn)卡頓、延遲等問題；
2）避免出現(xiàn)消息刷屏，肉眼無法查看的情況；
3）同時降低了服務(wù)端存儲壓力，不會因為海量消息出現(xiàn)內(nèi)存瓶頸從而影響服務(wù)。
7、寫在最后
隨著移動互聯(lián)網(wǎng)的發(fā)展，直播間的實時消息業(yè)務(wù)模型和壓力也在不停地擴展變化，后續(xù)可能還會遇到更多的挑戰(zhàn)，我們的服務(wù)會與時俱進(jìn)、跟進(jìn)更優(yōu)的方案策略進(jìn)行應(yīng)對。
附錄：多人群聊天技術(shù)文章
[1]《IM單聊和群聊中的在線狀態(tài)同步應(yīng)該用“推”還是“拉”？》
[2]《IM群聊消息如此復(fù)雜，如何保證不丟不重？》
[3]《移動端IM中大規(guī)模群消息的推送如何保證效率、實時性？》
[4]《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲方案探討》
[5]《關(guān)于IM即時通訊群聊消息的亂序問題討論》
[6]《IM群聊消息的已讀回執(zhí)功能該怎么實現(xiàn)？》
[7]《IM群聊消息究竟是存1份(即擴散讀)還是存多份(即擴散寫)？》
[8]《一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構(gòu)方案設(shè)計實踐》
[9]《IM群聊機制，除了循環(huán)去發(fā)消息還有什么方式？如何優(yōu)化？》
[10]《網(wǎng)易云信技術(shù)分享：IM中的萬人群聊技術(shù)方案實踐總結(jié)》
[11]《阿里釘釘技術(shù)分享：企業(yè)級IM王者——釘釘在后端架構(gòu)上的過人之處》
[12]《IM群聊消息的已讀未讀功能在存儲空間方面的實現(xiàn)思路探討》
[13]《企業(yè)微信的IM架構(gòu)設(shè)計揭秘：消息模型、萬人群、已讀回執(zhí)、消息撤回等》
[14]《融云IM技術(shù)分享：萬人群聊消息投遞方案的思考和實踐》
（本文已同步發(fā)布于：http://www.52im.net/thread-3799-1-1.html）
