作者：來自 vivo 互聯(lián)網(wǎng)服務(wù)器團隊- Cai Linfeng

 本文介紹了服務(wù)端在搭建 Web 版的百萬人級別的群聊系統(tǒng)時，遇到的技術(shù)挑戰(zhàn)和解決思路，內(nèi)容包括：通信方案選型、消息存儲、消息有序性、消息可靠性、未讀數(shù)統(tǒng)計。

 

一、引言

現(xiàn)在IM群聊產(chǎn)品多種多樣，有國民級的微信、QQ，企業(yè)級的釘釘、飛書，還有許多公司內(nèi)部的IM工具，這些都是以客戶端為主要載體，而且群聊人數(shù)通常都是有限制，微信正常群人數(shù)上限是500，QQ2000人，收費能達到3000人，這里固然有產(chǎn)品考量，但技術(shù)成本、資源成本也是很大的因素。而筆者業(yè)務(wù)場景上需要一個迭代更新快、輕量級（不依賴客戶端）、單群百萬群成員的純H5的IM產(chǎn)品，本文將回顧實現(xiàn)一個百萬人量級的群聊，服務(wù)器側(cè)需要考慮的設(shè)計要點，希望可以給到讀者一些啟發(fā)。

 

二、背景介紹

不同的群聊產(chǎn)品，采用的技術(shù)方案是不同的，為了理解接下來的技術(shù)選型，需要先了解下這群聊產(chǎn)品的特性。

1. 單群成員需要支撐百萬人，同時在線百萬級。

2. 功能、體驗要接近純客戶端實現(xiàn)方案。

3. 用戶端完全用H5承載。

 

三、通信技術(shù)

即時通信常見的通信技術(shù)有短輪詢、長輪詢、Server-Sent Events(SSE)、Websocket。短輪詢和長輪詢適用于實時性要求不高的場景，比如論壇的消息提醒。SSE 適用于服務(wù)器向客戶端單向推送的場景，如實時新聞、股票行情。Websocket 適用于實時雙向通信的場景，實時性好，且服務(wù)端、前端都有比較成熟的三方包，如 socket.io，所以這塊在方案選擇中是比較 easy 的，前后端使用 Websocket 來實現(xiàn)實時通信。

 

四、消息存儲

群聊消息的保存方式，主流有2種方式：讀擴散、寫擴散。圖1展示了它們的區(qū)別，區(qū)別就在于消息是寫一次還是寫N次，以及如何讀取。

 

圖1

 

讀擴散就是所有群成員共用一個群信箱，當一個群產(chǎn)生一條消息時，只需要寫入這個群的信箱即可，所有群成員從這一個信箱里讀取群消息。

優(yōu)點是寫入邏輯簡單，存儲成本低，寫入效率高。缺點是讀取邏輯相對復(fù)雜，要通過消息表與其他業(yè)務(wù)表數(shù)據(jù)聚合；消息定制化處理復(fù)雜，需要額外的業(yè)務(wù)表；可能還有IO熱點問題。

 

舉個例子：

很常見的場景，展示用戶對消息的已讀未讀狀態(tài)，這個時候公共群信箱就無法滿足要求，必須增加消息已讀未讀表來記錄相關(guān)狀態(tài)。還有用戶對某條消息的刪除狀態(tài)，用戶可以選擇刪除一條消息，但是其他人仍然可以看到它，此時也不適合在公共群信箱里拓展，也需要用到另一張關(guān)系表，總而言之針對消息做用戶特定功能時就會比寫擴散復(fù)雜。

寫擴散就是每個群成員擁有獨立的信箱，每產(chǎn)生一條消息，需要寫入所有群成員信箱，群成員各自從自己的信箱內(nèi)讀取群消息。優(yōu)點是讀取邏輯簡單，適合消息定制化處理，不存在IO熱點問題。缺點是寫入效率低，且隨著群成員數(shù)增加，效率降低；存儲成本大。

 

所以當單群成員在萬級以上時，用寫擴散就明顯不太合適了，寫入效率太低，而且可能存在很多無效寫入，不活躍的群成員也必須得有信箱，存儲成本是非常大的，因此采用讀擴散是比較合適的。

 

據(jù)了解，微信是采用寫擴散模式，微信群設(shè)定是500人上限，寫擴散的缺點影響就比較小。

 

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

5.1 整體架構(gòu)

先來看看群聊的架構(gòu)設(shè)計圖，如圖2所示：

 

圖2

 

從用戶登錄到發(fā)送消息，再到群用戶收到這條消息的系統(tǒng)流程如圖3所示：

 

圖3

 

1. 用戶登錄，通過負載均衡，與連接服務(wù)建立 Websocket 長連接。

2. 連接服務(wù)管理會話，管理群與用戶的映射關(guān)系，在本地內(nèi)存里使用哈希表存儲，key為groupId，value為List<SocketIOClient>，同一個群的用戶可能會在不同的集群服務(wù)器上。

3. 連接服務(wù)向群組服務(wù)上報群組路由，上報它的內(nèi)網(wǎng)IP和它所管理的 groupIdList 的關(guān)系，這里需要2種同步策略并行保證群組路由信息的準確性：a.在用戶建立、斷開長連接時即刻上報；b.定時上報。

4. 群組服務(wù)管理群組路由，使用遠程中心緩存 Redis 管理 groupId 和連接服務(wù)器IP的關(guān)系，key 為 groupId，value 為 List，該IP為連接服務(wù)的內(nèi)網(wǎng)IP地址，這里會做上報的心跳判斷，超過3個心跳周期不上報，則認為已斷線。

5. 用戶在群里發(fā)布一條消息，消息通過 Websokcet 送達連接服務(wù)，然后經(jīng)過連接服務(wù)——>消息隊列——>群組服務(wù)，消息在群組服務(wù)里經(jīng)過頻控、安全檢查、格式轉(zhuǎn)換等一系列流程后入庫，持久化。

6. 群組服務(wù)通過群組路由管理獲取這條消息所屬群的路由信息，即一組連接服務(wù)的IP地址，然后通過 HTTP 回調(diào)對應(yīng)的連接服務(wù)，通知它們有新消息產(chǎn)生，這里只簡單傳遞消息ID。

7. 連接服務(wù)收到 HTTP 請求后，根據(jù)會話管理查詢該群所有用戶，給用戶發(fā)送新消息提醒。

8. 用戶收到新消息提醒，通過 Websocket 來連接服務(wù)拉取該新消息具體詳情，然后根據(jù)消息協(xié)議展示在信息流里。

 

5.2 路由策略

用戶應(yīng)該連接到哪一臺連接服務(wù)呢？這個過程重點考慮如下2個問題：

1. 盡量保證各個節(jié)點的連接均衡；

2. 增刪節(jié)點是否要做 Rebalance。

 

保證均衡有如下幾個算法：

1. 輪詢：挨個將各個節(jié)點分配給客戶端，但會出現(xiàn)新增節(jié)點分配不均勻的情況；

2. 取模：類似于 HashMap，但也會出現(xiàn)輪詢的問題。當然也可以像 HashMap 那樣做一次 Rebalance，讓所有的客戶端重新連接。不過這樣會導(dǎo)致所有的連接出現(xiàn)中斷重連，代價有點大。由于 Hash 取模方式的問題帶來了一致性 Hash 算法，但依然會有一部分的客戶端需要 Rebalance；

3. 權(quán)重：可以手動調(diào)整各個節(jié)點的負載情況，甚至可以做成自動的，基于監(jiān)控當某些節(jié)點負載較高就自動調(diào)低權(quán)重，負載較低的可以提高權(quán)重；筆者是采用輪詢 + 權(quán)重模式，盡量保證負載均衡。

 

5.3 重連機制

當應(yīng)用在擴縮容或重啟升級時，在該節(jié)點上的客戶端怎么處理？由于設(shè)計有心跳機制，當心跳不通或監(jiān)聽連接斷開時，就認為該節(jié)點有問題了，就嘗試重新連接；如果客戶端正在發(fā)送消息，那么就需要將消息臨時保存住，等待重新連接上后再次發(fā)送。

 

5.4 線程策略

將連接服務(wù)里的IO線程與業(yè)務(wù)線程隔離，提升整體性能，原因如下：

1. 充分利用多核的并行處理能力：IO線程和業(yè)務(wù)線程隔離，雙方都可以并行處理網(wǎng)絡(luò)IO和業(yè)務(wù)邏輯，充分利用計算機多核并行計算能力，提升性能；

2. 故障隔離：業(yè)務(wù)線程處理多種業(yè)務(wù)消息，有IO密集型，也有 CPU 密集型，有些是純內(nèi)存計算，不同的業(yè)務(wù)處理時延和故障率是不同的。如果把業(yè)務(wù)線程和IO線程合并，就會有如下問題：某類業(yè)務(wù)處理較慢，阻塞IO線程，導(dǎo)致其他處理較快的業(yè)務(wù)消息響應(yīng)不及時；

3. 可維護性：IO線程和業(yè)務(wù)線程隔離之后，職責(zé)單一，有利于維護和定位問題。

 

5.5 有狀態(tài)鏈接

在這樣的場景中不像 HTTP 那樣是無狀態(tài)的，需要明確知道各個客戶端和連接的關(guān)系。比如需要向客戶端廣播群消息時，首先得知道客戶端的連接會話保存在哪個連接服務(wù)節(jié)點上，自然這里需要引入第三方中間件來存儲這個關(guān)系。通過由連接服務(wù)主動上報給群組服務(wù)來實現(xiàn)，上報時機是客戶端接入和斷開連接服務(wù)以及周期性的定時任務(wù)。

 

5.6 群組路由

設(shè)想這樣一個場景：需要給群所有成員推送一條消息怎么做？通過群編號去前面的路由 Redis 獲取對應(yīng)群的連接服務(wù)組，再通過 HTTP 方式調(diào)用連接服務(wù)，通過連接服務(wù)上的長連接會話進行真正的消息下發(fā)。

 

5.7 消息流轉(zhuǎn)

連接服務(wù)直接接收用戶的上行消息，考慮到消息量可能非常大，在連接服務(wù)里做業(yè)務(wù)顯然不合適，這里完全可以選擇 Kafka 來解耦，將所有的上行消息直接丟到 Kafka 就不管了，消息由群組服務(wù)來處理。

 

六、消息順序

?6.1 亂序現(xiàn)象

為什么要講消息順序，來看一個場景。假設(shè)群里有用戶A、用戶B、用戶C、用戶D，下面以 ABCD 代替，假設(shè)A發(fā)送了3條消息，順序分別是 msg1、msg2、msg3，但B、C、D看到的消息順序不一致，如圖4所示：

圖4

 

這時B、C、D肯定會覺得A在胡言亂語了，這樣的產(chǎn)品用戶必定是不喜歡的，因此必須要保證所有接收方看到的消息展示順序是一致的。

 

6.2 原因分析

所以先了解下消息發(fā)送的宏觀過程：

1. 發(fā)送方發(fā)送消息。

2. 服務(wù)端接收消息。

3. 服務(wù)端返回 ACK 消息。

4. 服務(wù)端推送新消息或客戶端拉取新消息。

 

在上面的過程中，都可能產(chǎn)生順序問題，簡要分析幾點原因：

 

1. 時鐘不一致：多個客戶端、服務(wù)端集群、DB集群，時鐘不能保證完全一致，因此不能用本地時間來決定消息順序。

2. 網(wǎng)絡(luò)傳輸：發(fā)送消息環(huán)節(jié)，先發(fā)后至，到達服務(wù)器的順序可能是 msg2、msg1、msg3。

3. 多線程：服務(wù)器考慮性能、吞吐量，往往會在多處環(huán)節(jié)采用線程池、異步去提升整體速度，因此也會產(chǎn)生順序問題。

 

6.3 解決方案

6.3.1 單用戶保持有序

通過上面的分析可以知道，其實無法保證或是無法衡量不同用戶之間的消息順序，那么只需保證同一個用戶的消息是有序的，保證上下文語義，所以可以得出一個比較樸素的實現(xiàn)方式：以服務(wù)端數(shù)據(jù)庫的唯一自增ID為標尺來衡量消息的時序，然后讓同一個用戶的消息處理串行化。那么就可以通過以下幾個技術(shù)手段配合來解決：

 

1. 發(fā)送消息使用 Websocket 發(fā)送，并且多次發(fā)送保持同一個會話，那么 tcp 協(xié)議就保證了應(yīng)用層收到的消息必定是有序的。

2. 在應(yīng)用程序內(nèi)部處理時，涉及相關(guān)多線程的模塊，根據(jù) uid 進行 hash，匹配一個單線程的線程池，即同一個 uid 的消息永遠用同一個線程去處理，不同用戶之間仍是并行處理。

3. 在跨應(yīng)用程序時，一般有2種處理方式：一是用 rpc 同步調(diào)用；二是利用消息中間件的全局有序。

4. 用戶端上做消息發(fā)送頻率限制，2次發(fā)送必須間隔1秒，能大大降低亂序的可能性了。

 

6.3.2 推拉結(jié)合

到這里基本解決了同一個用戶的消息可以按照他自己發(fā)出的順序入庫的問題，即解決了消息發(fā)送流程里第一、二步。

 

第三、四步存在的問題是這樣的：

A發(fā)送了 msg1、msg2、msg3，B發(fā)送了 msg4、msg5、msg6，最終服務(wù)端的入庫順序是msg1、msg2、msg4、msg3、msg5、msg6，那除了A和B其他人的消息順序需要按照入庫順序來展示，而這里的問題是服務(wù)端考量推送吞吐量，在推送環(huán)節(jié)是并發(fā)的，即可能 msg4 比 msg1 先推送到用戶端上，如果按照推送順序追加來展示，那么就與預(yù)期不符了，每個人看到的消息順序都可能不一致，如果用戶端按照消息的id大小進行比較插入的話，用戶體驗將會比較奇怪，突然會在2個消息中間出現(xiàn)一條消息。所以這里采用推拉結(jié)合方式來解決這個問題，具體步驟如下：

 

1. 用戶端發(fā)出消息，服務(wù)端將消息以群維度按照消息的入庫順序緩存在 Redis 有序 SET。

2. 服務(wù)端推送給用戶端新消息提醒，內(nèi)容是該新消息的id。

3. 用戶端拉取消息，攜帶2個消息id，startId 和 endId，startId：本地最新的完整消息id；endId：服務(wù)端推送得到的新消息id。

4. 服務(wù)端返回2個消息id區(qū)間內(nèi)的消息列表。

 

圖5

 

圖6

 

舉例，圖5表示服務(wù)端的消息順序，圖6表示用戶端拉取消息時本地消息隊列和提醒隊列的變化邏輯。

 

1. t1時刻用戶本地最新的完整消息是 msg1，即這條消息已經(jīng)完整展示給用戶。

2. t2時刻收到服務(wù)端推送的 msg3 新消息提醒，放到提醒隊列，此時用戶看不到這條消息。

3. t3時刻向服務(wù)端拉取消息詳情，請求參數(shù)為 startId：msg1，endId：msg3，服務(wù)端會按順序一起返回2個消息區(qū)間內(nèi)的所有消息的詳情即 msg2、msg4、msg3，將消息詳情同步寫入到消息隊列，此時用戶可以看到刷新出3條消息。

4. t4時刻用戶還會收到 msg2、msg4 的新消息提醒，用戶端校驗消息隊列已經(jīng)存在 msg2、msg4 的詳情，忽略該新消息提醒。

 

通過推拉結(jié)合的方式可以保證所有用戶收到的消息展示順序一致。細心的讀者可能會有疑問，如果聊天信息流里有自己發(fā)送的消息，那么可能與其他的人看到的不一致，這是因為自己的消息展示不依賴拉取，需要即時展示，給用戶立刻發(fā)送成功的體驗，同時其他人也可能也在發(fā)送，最終可能比他先入庫，為了不出現(xiàn)信息流中間插入消息的用戶體驗，只能將他人的新消息追加在自己的消息后面。所以如果作為發(fā)送者，消息順序可能不一致，但是作為純接收者，大家的消息順序都是一樣的。

 

七、消息可靠性

在IM系統(tǒng)中，消息的可靠性同樣非常重要，它主要體現(xiàn)在：

1. 消息不丟失：對發(fā)送人來說，必須保證消息能入庫；對接收者來說，不管是在線還是離線，都能保證收到。但是這里的不丟失，只是說以最大努力去保證，并不是說完全不丟失。

2. 消息不重復(fù)：這很容易理解，同一條消息不能重復(fù)出現(xiàn)。

 

7.1 消息不丟失設(shè)計

1. 傳輸協(xié)議保障：首先 TCP 是可靠的協(xié)議，能較大程度上保證消息不丟失。

2. 增加ACK機制：服務(wù)端在執(zhí)行完消息處理的所有流程后，給發(fā)送者發(fā)送 ACK；假如發(fā)送者在超時時間內(nèi)沒有收到 ACK 消息，則進行一定次數(shù)的重試，重新發(fā)送；當重發(fā)次數(shù)超過預(yù)設(shè)次數(shù)，就不再重發(fā)，消息發(fā)送失敗。

3. 最終一致性：這是對接收者而言，如果某條新消息提醒因網(wǎng)絡(luò)等其他原因丟失，用戶沒有收到這條消息提醒，那么用戶就不會去拉消息詳情，在用戶視角就是沒有看到這條消息。但是當后續(xù)的新消息提醒送達時，可以依賴前面提到的拉取機制拿到一個區(qū)間內(nèi)的消息列表，這里就包含了丟失的消息，因此能達到最終一致性。

 

7.2 消息不重復(fù)設(shè)計

1. 增加UUID：每條消息增加 UUID，由客戶端創(chuàng)建消息時生成，同一個用戶的消息 UUID 唯一。

2. 服務(wù)端：用戶 ID+UUID 在數(shù)據(jù)庫做聯(lián)合唯一索引，保證數(shù)據(jù)層面消息不重復(fù)。

3. 用戶端：進行兜底，構(gòu)造一個map來維護已接收消息的id，當收到id重復(fù)的消息時直接丟棄。

 

八、未讀數(shù)統(tǒng)計

為了提醒用戶有新消息，需要給用戶展示新消息提醒標識，產(chǎn)品設(shè)計上一般有小紅點、具體的數(shù)值2種方式。具體數(shù)值比小紅點要復(fù)雜，這里分析下具體數(shù)值的處理方式，還需要分為初始打開群和已打開群2個場景。

 

已打開群：可以完全依賴用戶端本地統(tǒng)計，用戶端獲取到新消息后，就將未讀數(shù)累計加1，等點進去查看后，清空未讀數(shù)統(tǒng)計，這個比較簡單。

 

初始打開群：由于用戶端采用H5開發(fā)，用戶端沒有緩存，沒有能力緩存最近的已讀消息游標，因此這里完全需要服務(wù)端來統(tǒng)計，在打開群時下發(fā)最新的聊天信息流和未讀數(shù)，下面具體講下這個場景下該怎么設(shè)計。

既然由服務(wù)端統(tǒng)計未讀數(shù)，那么少不了要保存用戶在某個群里已經(jīng)讀到哪個消息，類似一個游標，用戶已讀消息，游標往前走。用戶已讀消息存儲表設(shè)計如圖7所示：

 

圖7

 

游標offset采用定時更新策略，連接服務(wù)會記錄用戶最近一次拉取到的消息ID，定時異步上報批量用戶到群組服務(wù)更新 offset。

該表第一行表示用戶1在 id=89 的群里，最新的已讀消息是id=1022消息，那么可以通過下面的SQL來統(tǒng)計他在這個群里的未讀數(shù)：select count(1) from msg_info where groupId = 89 and id > 1022。但是事情并沒這么簡單，一個用戶有很多群，每個群都要展示未讀數(shù)，因此要求未讀數(shù)統(tǒng)計的程序效率要高，不然用戶體驗就很差，很明顯這個 SQL 的耗時波動很大，取決于 offset 的位置，如果很靠后，SQL 執(zhí)行時間會非常長。筆者通過2個策略來優(yōu)化這個場景:

 

1. 調(diào)整產(chǎn)品設(shè)計：未讀數(shù)最大顯示調(diào)整為99+。算是產(chǎn)品上的一個讓步，有很多產(chǎn)品也采用這個方案，所以用戶也是有這個心智的，99+表示“有很多新消息”，至于具體多少，是幾百、幾千很多時候不是特別重要。所以問題就變得簡單多了，只要計算游標是否在最新的100條消息以內(nèi)還是以外。

2. 合理利用數(shù)據(jù)結(jié)構(gòu)：因為有群內(nèi)有很多人，每個人登錄的時候都需要統(tǒng)計，所以每次都去查 MySQL 是比較低效的，因此筆者的方案是在 Redis 里設(shè)計一個有界的ZSET結(jié)構(gòu)。

 

圖8

 

如上圖8所示，每個群都會構(gòu)建一個長度為100，score 和 member 都是消息ID，可以通過 zrevrank 命令得到某個 offset 的排名值，該值可以換算成未讀數(shù)。比如：用戶1在群89的未讀消息數(shù)，'zrevrank 89 1022' = 2，也就是有2條未讀數(shù)。用戶2在群89的未讀數(shù)，'zrevrank 89 890' = nil，那么未讀數(shù)就是99+。同時消息新增、刪除都需要同步維護該數(shù)據(jù)結(jié)構(gòu)，失效或不存在時從 MySQL 初始化。

 

九、超大群策略

前面提到，設(shè)計目標是在同一個群里能支撐百萬人，從架構(gòu)上可以看到，連接服務(wù)處于流量最前端，所以它的承載力直接決定了同時在線用戶的上限。

影響它的因素有：

1. 服務(wù)器自身配置：內(nèi)存、CPU、網(wǎng)卡、Linux 支持的最大文件打開數(shù)；

2. 應(yīng)用自身配置：應(yīng)用本身啟動需要的內(nèi)存，如 Netty 依賴的堆外內(nèi)存，大量的本地緩存；

3. 性能要求：當連接數(shù)不斷變大時，消息分發(fā)的整體耗時肯定在不斷增加，因此要關(guān)注最慢的分發(fā)耗時要滿足即時性要求；結(jié)合以上情況，可以測試出固定配置服務(wù)器單點能支持的最大用戶連接數(shù)，假如單機能支持20000個用戶連接，那么百萬在線連接，在連接服務(wù)層用50個服務(wù)的集群就能解決。

 

9.1 消息風(fēng)暴

當同時在線用戶數(shù)非常多，例如百萬時，會面臨如下幾個問題：

 

1. 消息發(fā)送風(fēng)暴：極端情況下，用戶同時發(fā)送消息，假設(shè)服務(wù)端承載住了這些流量，那么瓶頸其實在用戶端，第一用戶端會經(jīng)歷網(wǎng)絡(luò)風(fēng)暴，網(wǎng)卡帶寬能否支撐是一個大問題；第二假設(shè)網(wǎng)卡能通過這些流量，用戶端上百萬條消息該如何展示，要是瞬間刷出這些消息，用戶端 CPU能否撐住又是個問題，即使能抗住用戶體驗也很糟糕，根本就看不清消息，一直在飛速刷屏。因此服務(wù)端可以在發(fā)送消息風(fēng)暴時做好限流、丟棄策略，給到用戶友好的提示。

2. 消息提醒風(fēng)暴：一條新消息的產(chǎn)生，就要推送提醒消息百萬次，對服務(wù)器來說，要考量整體推送完成的時效性，如果時效性差，對有些用戶來說，就是消息需要較長時間才刷出來，出現(xiàn)明顯的延遲。新消息持久化后，群組服務(wù) HTTP 回調(diào)一組連接服務(wù)，單群百萬在線用戶，需要50臺連接服務(wù)集群，那么回調(diào)50次，為了保證時效性，因此這里要并發(fā)回調(diào)，并設(shè)置合理的線程池，然后連接服務(wù)收到回調(diào)后也需要并發(fā)完成對群用戶的新消息提醒推送。

3. 消息拉取風(fēng)暴：連接服務(wù)收到拉取消息事件，需要去群組服務(wù)獲取消息詳情，QPS 就非常高了，理論上集群達到 100wQPS，20臺群組服務(wù)，那么每臺群組服務(wù)就是 5wQPS。這里的策略是在鏈路前端連接服務(wù)上進行流量過濾，因為用戶都是請求同一個群的同一條消息或附近的消息，那么就可以在連接服務(wù)里設(shè)計群消息的本地緩存，所有用戶都只從本地緩存里讀，如果本地緩存里沒有，就放一個線程去群組服務(wù)請求加載緩存，其他線程同步等待，這樣就大大降低了打到群組服務(wù)的 QPS。

 

9.2 消息壓縮

如果某一個時刻，推送消息的數(shù)量比較大，且群同時在線人數(shù)比較多的時候，連接服務(wù)層的機房出口帶寬就會成為消息推送的瓶頸。

做個計算，百萬人在線，需要5臺連接服務(wù)，一條消息1KB，一般情況下，5臺連接服務(wù)集群都是部署在同一個機房，那么這個機房的帶寬就是1000000*1KB=1GB，如果多幾個超大群，那么對機房的帶寬要求就更高，所以如何有效的控制每一個消息的大小、壓縮每一個消息的大小，是需要思考的問題。

經(jīng)過測試，使用 protobuf 數(shù)據(jù)交換格式，平均每一個消息可以節(jié)省43%的字節(jié)大小，可以大大節(jié)省機房出口帶寬。

 

9.3 塊消息

超大群里，消息推送的頻率很高，每一條消息推送都需要進行一次IO系統(tǒng)調(diào)用，顯然會影響服務(wù)器性能，可以采用將多個消息進行合并推送。

主要思路：以群為維度，累計一段時間內(nèi)的消息，如果達到閾值，就立刻合并推送，否則就以勻速的時間間隔將在這個時間段內(nèi)新增的消息進行推送。

時間間隔是1秒，閾值是10，如果500毫秒內(nèi)新增了10條消息，就合并推送這10條消息，時間周期重置；如果1秒內(nèi)只新增了8條消息，那么1秒后合并推送這8條消息。這樣做的好處如下：

 

1. 提升服務(wù)器性能：減少IO系統(tǒng)調(diào)用，減少用戶態(tài)與內(nèi)核態(tài)之前的切換；

2. 減少傳輸量：合并消息后，可以減少傳輸多余的消息頭，進一步壓縮消息大小；

3. 提升用戶體驗：一定程度上能減小消息風(fēng)暴，消息渲染的節(jié)奏比較均勻，帶給用戶更好的體驗；

 

十、總結(jié)

在本文中，筆者介紹了從零開始搭建一個生產(chǎn)級百萬級群聊的一些關(guān)鍵要點和實踐經(jīng)驗，包括通信方案選型、消息存儲、消息順序、消息可靠性、高并發(fā)等方面，但仍有許多技術(shù)設(shè)計未涉及，比如冷熱群、高低消息通道會放在未來的規(guī)劃里。IM開發(fā)業(yè)界沒有統(tǒng)一的標準，不同的產(chǎn)品有適合自己的技術(shù)方案，希望本文能夠帶給讀者更好地理解和應(yīng)用這些技術(shù)實踐，為構(gòu)建高性能、高可靠性的群聊系統(tǒng)提供一定的參考。

轉(zhuǎn)自https://www.cnblogs.com/vivotech/p/18740478