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