隨著直播應(yīng)用的普及，特別是直播帶貨概念的普及，大用戶的直播場景已經(jīng)正?；?。

大用戶直播室的實時互動非常頻繁，具體體現(xiàn)在各種用戶聊天、彈幕、禮物、拇指、禁止、系統(tǒng)通知等實時信息上。

如此大量的實時信息，如何處理分發(fā)不會打破服務(wù)端，到客戶端不會讓應(yīng)用程序瘋狂刷新和卡住（不會影響用戶體驗），這顯然需要特殊的技術(shù)手段和實現(xiàn)策略來處理。

事實上，直播室的實時消息分發(fā)在技術(shù)上與傳統(tǒng)的在線聊天室概念相同，但在傳統(tǒng)的互聯(lián)網(wǎng)時代，聊天室的在線用戶數(shù)量不會那么大。雖然數(shù)量級不同，但技術(shù)模型可以完全應(yīng)用。

我們以百萬人觀看的直播間為例，看看需要面對哪些技術(shù)挑戰(zhàn)。

1)直播中會有一波又一波的新聞高峰，比如直播中的刷新新聞，即大量用戶同時發(fā)送的大量實時新聞。一般來說，這種刷新新聞的內(nèi)容基本相同。如果所有信息都顯示在客戶端，客戶端很可能會卡住、延遲等問題，嚴重影響用戶體驗。

2)在大量消息的情況下，如果服務(wù)端的每一條消息都長期存儲，就會導(dǎo)致服務(wù)緩存就會激增，內(nèi)存就會成為性能瓶頸。

3)在其他場景中，如直播室房間管理員操作后的通知消息或系統(tǒng)通知。一般來說，這類消息更為重要。如何優(yōu)先保證其到達率。

基于這些挑戰(zhàn)，我們的服務(wù)需要根據(jù)業(yè)務(wù)場景進行優(yōu)化。

下面將簡要說明主要服務(wù)。

1)直播間服務(wù)：

主要功能是：緩存直播間的基本信息。包括用戶列表、禁言/禁言關(guān)系、白名單用戶等。

2)新聞服務(wù)：

主要功能是：緩存本節(jié)點需要處理的用戶關(guān)系信息、消息隊列信息等。

具體來說，這是以下兩件大事。

直播間用戶關(guān)系同步：

A)成員主動加入退出：直播間服務(wù)同步至==>消息服務(wù)；

b)發(fā)現(xiàn)用戶已離線時：消息服務(wù)同步至==>直播間服務(wù)。

發(fā)送消息：

a)直播間服務(wù)經(jīng)必要驗證通過后，將消息廣播到消息服務(wù)；

b)直播間服務(wù)不緩存消息內(nèi)容。

3)Zk(即Zookeeper):

主要功能是將所有服務(wù)實例注冊到ZK，并在服務(wù)間流通時使用數(shù)據(jù)進行落點計算。

具體就是：

a)直播間服務(wù)：按直播間ID落點；

b)消息服務(wù)：根據(jù)用戶ID落點。

4)Redis：

主要用于二次緩存，以及服務(wù)更新(重啟)時內(nèi)存數(shù)據(jù)的備份。

我們的消息分發(fā)過程主要如下：

1)用戶A在直播間發(fā)送消息，首先由直播間服務(wù)處理；

2)直播間服務(wù)將消息同步到各消息服務(wù)節(jié)點；

3)消息服務(wù)向本節(jié)點緩存的所有成員發(fā)出通知；

4)如上圖所示的消息服務(wù)-1，將向用戶B發(fā)出通知。

此外，由于消息量過大，我們在分發(fā)過程中有通知合并機制，通知合并機制主要提到上述步驟3。

上述步驟3通知合并機制的原理如下：

a)將所有成員加入待通知隊列(如有，更新通知時間)；

b)下發(fā)線程，輪訓(xùn)獲得待通知隊列；

c)向隊列中的用戶發(fā)出通知。

通過通知合并機制，我們可以確保線程只向同一用戶發(fā)送一個通知，即多個消息合并為通知，有效提高服務(wù)端性能，降低客戶端和服務(wù)器的網(wǎng)絡(luò)消耗。

我們的消息提取過程主要如下：

1)收到通知后，用戶B將向服務(wù)端發(fā)送拉取消息請求；

2)該請求將由消息服務(wù)-1節(jié)點處理；

3)消息服務(wù)-1將根據(jù)客戶端傳輸?shù)淖詈笠粭l消息時間戳，從消息隊列中返回消息列表；

4)用戶B獲取新消息。

對于直播室的用戶來說，很多消息其實并沒有太大的實際意義，比如大量重復(fù)的刷新消息和動態(tài)通知。為了提升用戶體驗，這類消息可以有策略地丟棄(這與IM中的實時聊天消息最大的區(qū)別，IM中不允許丟失)。

PS:直播間消息分發(fā)的丟棄策略，結(jié)合節(jié)中的通知合并機制，可以穩(wěn)定直接間大量消息，順利分發(fā)。

我們的丟棄策略主要由以下三部分組成：

1)上行限速控制(丟棄)策略；

2)下行限速控制(丟棄)策略；

3)重要消息防丟棄策略。

讓我們一一解釋一下。

1)上行限速控制（丟棄）策略：

對于上行限速控制，默認為200條/秒，可根據(jù)業(yè)務(wù)需要進行調(diào)整。達到限速后發(fā)送的消息將在直播間丟棄，不再與每個消息服務(wù)節(jié)點同步。

2)下行限速控制(丟棄)策略:

對下行限速控制，即對消息環(huán)隊列長度的控制（見5.2消息提取過程中提取消息的詳細邏輯圖），達到最大值后最老的消息將被淘汰和丟棄。

每次發(fā)出通知后，服務(wù)器都會將用戶標記為拉取中，用戶實際拉取消息后將標記刪除。

拉中標記的功能：例如，用戶在產(chǎn)生新消息時有拉中標記，如果距離設(shè)置標記時間2秒內(nèi)不發(fā)出通知（降低客戶壓力，丟棄通知不丟棄消息），2秒以上繼續(xù)發(fā)出通知（連續(xù)多次通知觸發(fā)用戶踢出策略，此處不重復(fù)）。

因此，消息是否丟棄取決于客戶端的提取速度（受客戶端性能和網(wǎng)絡(luò)影響），而客戶端沒有丟棄消息。

3)重要消息防丟棄策略：

如前文所述：在直播間場景中，對某些消息要有較高的優(yōu)先級，不能丟棄。

例如：直播間房間管理員操作后通知消息或系統(tǒng)通知。

針對這一場景：我們設(shè)置了信息白名單和信息優(yōu)先級的概念，以確保不被丟棄。如本節(jié)開頭的圖所示，可以有多個消息環(huán)隊列，與普通直播間的消息分離保證了重要消息不被丟棄。