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