本文由vivo互聯網服務器團隊Cai Linfeng分享，來自公眾號“ vivo互聯網技術”，原題“百萬級羣聊的設計實踐”，下文進行了排版優化和內容修訂。

1、引言

現在IM羣聊產品多種多樣，有國民級的微信、QQ，企業級的釘釘、飛書，還有許多公司內部的IM工具，這些都是以客户端為主要載體。而且羣聊人數通常都是有限制，微信正常羣人數上限是500，QQ2000人，收費能達到3000人，這裏固然有產品考量，但技術成本、資源成本也是很大的因素。筆者的業務場景上正好需要一個迭代更新快、輕量級（不依賴客户端）、單羣百萬羣成員的純H5的IM產品。本文將回顧實現一個支持百萬人超大羣聊的Web端IM架構時遇到的技術挑戰和解決思路，內容包括：通信方案選型、消息存儲、消息有序性、消息可靠性、未讀數統計。希望能帶給你啓發。

2、技術目標

不同的羣聊產品，採用的技術方案是不同的，為了理解接下來的技術選型，需要先了解下這羣聊產品的特性。

以下是我們的技術目標：

• 1）單羣成員需要支撐百萬人，同時在線百萬級；
• 2）功能、體驗要接近純客户端實現方案；
• 3）用户端完全用H5承載。

3、Web端即時通訊技術

即時通信常見的通信技術有短輪詢、長輪詢、Server-Sent Events(SSE)、Websocket。

具體是：

1）短輪詢和長輪詢適用於實時性要求不高的場景，比如論壇的消息提醒；
2）SSE 適用於服務器向客户端單向推送的場景，如實時新聞、股票行情；
3）Websocket 適用於實時雙向通信的場景，實時性好，且服務端、前端都有比較成熟的三方包，如 socket.io，所以這塊在方案選擇中是比較 easy 的，前後端使用 Websocket 來實現實時通信。
相關的資料可以進一步閲讀：

新手入門貼：史上最全Web端即時通訊技術原理詳解
Web端即時通訊技術盤點：短輪詢、Comet、Websocket、SSE
網頁端IM通信技術快速入門：短輪詢、長輪詢、SSE、WebSocket
搞懂現代Web端即時通訊技術一文就夠：WebSocket、socket.io、SSE
WebSocket從入門到精通，半小時就夠！

4、羣聊消息的分發模式

羣聊消息的分發方式，主流有2種方式：讀擴散、寫擴散。下圖展示了它們的區別，區別就在於消息是寫一次還是寫N次，以及如何讀取：

1）讀擴散：就是所有羣成員共用一個羣信箱，當一個羣產生一條消息時，只需要寫入這個羣的信箱即可，所有羣成員從這一個信箱裏讀取羣消息。
優點是：寫入邏輯簡單，存儲成本低，寫入效率高。
缺點是：讀取邏輯相對複雜，要通過消息表與其他業務表數據聚合；消息定製化處理複雜，需要額外的業務表；可能還有IO熱點問題。
舉個例子：

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

2）寫擴散：就是每個羣成員擁有獨立的信箱，每產生一條消息，需要寫入所有羣成員信箱，羣成員各自從自己的信箱內讀取羣消息。
優點是：讀取邏輯簡單，適合消息定製化處理，不存在IO熱點問題。
缺點是：寫入效率低，且隨着羣成員數增加，效率降低；存儲成本大。

所以當單羣成員在萬級以上時，用寫擴散就明顯不太合適了，寫入效率太低，而且可能存在很多無效寫入，不活躍的羣成員也必須得有信箱，存儲成本是非常大的，因此採用讀擴散是比較合適的。據瞭解，微信是採用寫擴散模式（詳見《企業微信的IM架構設計揭秘：消息模型、萬人羣、已讀回執、消息撤回等》），微信羣設定是500人上限，寫擴散的缺點影響就比較小。

5、架構設計

5.1 整體架構

先來看看羣聊的架構設計圖，如下圖所示：

從用户登錄到發送消息，再到羣用户收到這條消息的系統流程如下圖所示：

解釋一下邏輯：
1）用户登錄，通過負載均衡，與連接服務建立 Websocket 長連接；
2）連接服務管理會話，管理羣與用户的映射關係，在本地內存裏使用哈希表存儲，key為groupId，value為List，同一個羣的用户可能會在不同的集羣服務器上；
3）連接服務向羣組服務上報羣組路由，上報它的內網IP和它所管理的 groupIdList 的關係，這裏需要2種同步策略並行保證羣組路由信息的準確性：a.在用户建立、斷開長連接時即刻上報；b.定時上報；
4）羣組服務管理羣組路由，使用遠程中心緩存 Redis 管理 groupId 和連接服務器IP的關係，key 為 groupId，value 為 List，該IP為連接服務的內網IP地址，這裏會做上報的心跳判斷，超過3個心跳週期不上報，則認為已斷線；
5）用户在羣裏發佈一條消息，消息通過 Websokcet 送達連接服務，然後經過連接服務—>消息隊列—>羣組服務，消息在羣組服務裏經過頻控、安全檢查、格式轉換等一系列流程後入庫，持久化；
6）羣組服務通過羣組路由管理獲取這條消息所屬羣的路由信息，即一組連接服務的IP地址，然後通過 HTTP 回調對應的連接服務，通知它們有新消息產生，這裏只簡單傳遞消息ID；
7）連接服務收到 HTTP 請求後，根據會話管理查詢該羣所有用户，給用户發送新消息提醒；
8）用户收到新消息提醒，通過 Websocket 來連接服務拉取該新消息具體詳情，然後根據消息協議展示在信息流裏。

5.2 路由策略

用户應該連接到哪一台連接服務呢？

這個過程重點考慮如下2個問題：

1）儘量保證各個節點的連接均衡；
2）增刪節點是否要做 Rebalance。
保證均衡有如下幾個算法：

1）輪詢：挨個將各個節點分配給客户端，但會出現新增節點分配不均勻的情況；
2）取模：類似於 HashMap，但也會出現輪詢的問題。當然也可以像 HashMap 那樣做一次 Rebalance，讓所有的客户端重新連接。不過這樣會導致所有的連接出現中斷重連，代價有點大。由於 Hash 取模方式的問題帶來了一致性 Hash 算法，但依然會有一部分的客户端需要 Rebalance；
3）權重：可以手動調整各個節點的負載情況，甚至可以做成自動的，基於監控當某些節點負載較高就自動調低權重，負載較低的可以提高權重。
PS：筆者是採用輪詢 + 權重模式，儘量保證負載均衡。

5.3 重連機制

當應用在擴縮容或重啓升級時，在該節點上的客户端怎麼處理？

由於設計有心跳機制，當心跳不通或監聽連接斷開時，就認為該節點有問題了，就嘗試重新連接；如果客户端正在發送消息，那麼就需要將消息臨時保存住，等待重新連接上後再次發送。

相關資料請閲讀：《Web端即時通訊實踐乾貨：如何讓你的WebSocket斷網重連更快速？》

5.4 線程策略

將連接服務裏的IO線程與業務線程隔離，提升整體性能，原因如下：

1）充分利用多核的並行處理能力：IO線程和業務線程隔離，雙方都可以並行處理網絡IO和業務邏輯，充分利用計算機多核並行計算能力，提升性能；

2）故障隔離：業務線程處理多種業務消息，有IO密集型，也有 CPU 密集型，有些是純內存計算，不同的業務處理時延和故障率是不同的。如果把業務線程和IO線程合併，就會有如下問題：某類業務處理較慢，阻塞IO線程，導致其他處理較快的業務消息響應不及時；

3）可維護性：IO線程和業務線程隔離之後，職責單一，有利於維護和定位問題。

5.5 有狀態鏈接

在這樣的場景中不像 HTTP 那樣是無狀態的，需要明確知道各個客户端和連接的關係。

比如需要向客户端廣播羣消息時，首先得知道客户端的連接會話保存在哪個連接服務節點上，自然這裏需要引入第三方中間件來存儲這個關係。

通過由連接服務主動上報給羣組服務來實現，上報時機是客户端接入和斷開連接服務以及週期性的定時任務。

5.6 羣組路由

設想這樣一個場景：需要給羣所有成員推送一條消息怎麼做？

通過羣編號去前面的路由 Redis 獲取對應羣的連接服務組，再通過 HTTP 方式調用連接服務，通過連接服務上的長連接會話進行真正的消息下發。

5.7 消息流轉

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

6、消息的有序性設計

6.1 亂序現象

為什麼要講消息順序，來看一個場景。假設羣裏有用户A、用户B、用户C、用户D，下面以 ABCD 代替，假設A發送了3條消息，順序分別是 msg1、msg2、msg3，但B、C、D看到的消息順序不一致。如下圖所示：

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

6.2 原因分析

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

1）發送方發送消息；
2）服務端接收消息；
3）服務端返回 ACK 消息；
4）服務端推送新消息或客户端拉取新消息。
在上面的過程中，都可能產生順序問題，簡要分析幾點原因：

1）時鐘不一致：多個客户端、服務端集羣、DB集羣，時鐘不能保證完全一致，因此不能用本地時間來決定消息順序；
2）網絡傳輸：發送消息環節，先發後至，到達服務器的順序可能是 msg2、msg1、msg3；
3）多線程：服務器考慮性能、吞吐量，往往會在多處環節採用線程池、異步去提升整體速度，因此也會產生順序問題。

6.3 解決方案

1） 單用户保持有序：

通過上面的分析可以知道，其實無法保證或是無法衡量不同用户之間的消息順序，那麼只需保證同一個用户的消息是有序的，保證上下文語義，所以可以得出一個比較樸素的實現方式：以服務端數據庫的唯一自增ID為標尺來衡量消息的時序，然後讓同一個用户的消息處理串行化。

那麼就可以通過以下幾個技術手段配合來解決：

1）發送消息使用 Websocket 發送，並且多次發送保持同一個會話，那麼 tcp 協議就保證了應用層收到的消息必定是有序的；
2）在應用程序內部處理時，涉及相關多線程的模塊，根據 uid 進行 hash，匹配一個單線程的線程池，即同一個 uid 的消息永遠用同一個線程去處理，不同用户之間仍是並行處理；
3）在跨應用程序時，一般有2種處理方式：一是用 rpc 同步調用；二是利用消息中間件的全局有序；
4）用户端上做消息發送頻率限制，2次發送必須間隔1秒，能大大降低亂序的可能性了。
2） 推拉結合：

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

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

A發送了 msg1、msg2、msg3，B發送了 msg4、msg5、msg6，最終服務端的入庫順序是msg1、msg2、msg4、msg3、msg5、msg6，那除了A和B其他人的消息順序需要按照入庫順序來展示，而這裏的問題是服務端考量推送吞吐量，在推送環節是併發的，即可能 msg4 比 msg1 先推送到用户端上，如果按照推送順序追加來展示，那麼就與預期不符了，每個人看到的消息順序都可能不一致，如果用户端按照消息的id大小進行比較插入的話，用户體驗將會比較奇怪，突然會在2個消息中間出現一條消息。

所以這裏採用推拉結合方式來解決這個問題，具體步驟如下：
1）用户端發出消息，服務端將消息以羣維度按照消息的入庫順序緩存在 Redis 有序 SET；
2）服務端推送給用户端新消息提醒，內容是該新消息的id；
3）用户端拉取消息，攜帶2個消息id，startId 和 endId，startId：本地最新的完整消息id；endId：服務端推送得到的新消息id；
4）服務端返回2個消息id區間內的消息列表。

 

舉例：上圖1表示服務端的消息順序，上圖2表示用户端拉取消息時本地消息隊列和提醒隊列的變化邏輯。

具體是：
1）t1時刻用户本地最新的完整消息是 msg1，即這條消息已經完整展示給用户；
2）t2時刻收到服務端推送的 msg3 新消息提醒，放到提醒隊列，此時用户看不到這條消息；
3）t3時刻向服務端拉取消息詳情，請求參數為 startId：msg1，endId：msg3，服務端會按順序一起返回2個消息區間內的所有消息的詳情即 msg2、msg4、msg3，將消息詳情同步寫入到消息隊列，此時用户可以看到刷新出3條消息；
4）t4時刻用户還會收到 msg2、msg4 的新消息提醒，用户端校驗消息隊列已經存在 msg2、msg4 的詳情，忽略該新消息提醒。

通過推拉結合的方式可以保證所有用户收到的消息展示順序一致。細心的讀者可能會有疑問：如果聊天信息流裏有自己發送的消息，那麼可能與其他的人看到的不一致，這是因為自己的消息展示不依賴拉取，需要即時展示，給用户立刻發送成功的體驗，同時其他人也可能也在發送，最終可能比他先入庫，為了不出現信息流中間插入消息的用户體驗，只能將他人的新消息追加在自己的消息後面。所以如果作為發送者，消息順序可能不一致，但是作為純接收者，大家的消息順序都是一樣的。
相關資料請詳讀：
什麼是IM系統的消息時序一致性？
如何保證IM實時消息的“時序性”與“一致性”？
IM單聊和羣聊中的在線狀態同步應該用“推”還是“拉”？
一個低成本確保IM消息時序的方法探討

7、 消息的可靠性設計

在IM系統中，消息的可靠性同樣非常重要，它主要體現在：

1）消息不丟失：對發送人來説，必須保證消息能入庫；對接收者來説，不管是在線還是離線，都能保證收到。但是這裏的不丟失，只是説以最大努力去保證，並不是説完全不丟失；

2）消息不重複：這很容易理解，同一條消息不能重複出現。

消息不丟失設計：

1）傳輸協議保障：首先 TCP 是可靠的協議，能較大程度上保證消息不丟失；

2）增加ACK機制：服務端在執行完消息處理的所有流程後，給發送者發送 ACK；假如發送者在超時時間內沒有收到 ACK 消息，則進行一定次數的重試，重新發送；當重發次數超過預設次數，就不再重發，消息發送失敗；

3）最終一致性：這是對接收者而言，如果某條新消息提醒因網絡等其他原因丟失，用户沒有收到這條消息提醒，那麼用户就不會去拉消息詳情，在用户視角就是沒有看到這條消息。但是當後續的新消息提醒送達時，可以依賴前面提到的拉取機制拿到一個區間內的消息列表，這裏就包含了丟失的消息，因此能達到最終一致性。

消息不重複設計：

1）增加UUID：每條消息增加 UUID，由客户端創建消息時生成，同一個用户的消息 UUID 唯一；
2）服務端：用户 ID+UUID 在數據庫做聯合唯一索引，保證數據層面消息不重複；
3）用户端：進行兜底，構造一個map來維護已接收消息的id，當收到id重複的消息時直接丟棄。

相關資料請詳讀：

IM消息送達保證機制實現(一)：保證在線實時消息的可靠投遞
IM消息送達保證機制實現(二)：保證離線消息的可靠投遞
IM開發乾貨分享：如何優雅的實現大量離線消息的可靠投遞
融雲技術分享：全面揭秘億級IM消息的可靠投遞機制
閒魚億級IM消息系統的離線推送到達率優化
微信的海量IM聊天消息序列號生成實踐（算法原理篇）

8、  消息未讀數的實現

為了提醒用户有新消息，需要給用户展示新消息提醒標識，產品設計上一般有小紅點、具體的數值2種方式。具體數值比小紅點要複雜，這裏分析下具體數值的處理方式，還需要分為初始打開羣和已打開羣2個場景。
具體是：
1）已打開羣：可以完全依賴用户端本地統計，用户端獲取到新消息後，就將未讀數累計加1，等點進去查看後，清空未讀數統計，這個比較簡單；
2）初始打開羣：由於用户端採用H5開發，用户端沒有緩存，沒有能力緩存最近的已讀消息遊標，因此這裏完全需要服務端來統計，在打開羣時下發最新的聊天信息流和未讀數，下面具體講下這個場景下該怎麼設計。
既然由服務端統計未讀數，那麼少不了要保存用户在某個羣裏已經讀到哪個消息，類似一個遊標，用户已讀消息，遊標往前走。用户已讀消息存儲表設計如下圖所示：

遊標offset採用定時更新策略，連接服務會記錄用户最近一次拉取到的消息ID，定時異步上報批量用户到羣組服務更新 offset。
該表第一行表示用户1在 id=89 的羣裏，最新的已讀消息是id=1022消息，那麼可以通過下面的SQL來統計他在這個羣裏的未讀數：

select count(1) from msg_info where groupId = 89 and id > 1022

但是事情並沒這麼簡單：一個用户有很多羣，每個羣都要展示未讀數，因此要求未讀數統計的程序效率要高，不然用户體驗就很差，很明顯這個 SQL 的耗時波動很大，取決於 offset 的位置，如果很靠後，SQL 執行時間會非常長。
筆者通過2個策略來優化這個場景:
1）調整產品設計：未讀數最大顯示調整為99+。算是產品上的一個讓步，有很多產品也採用這個方案，所以用户也是有這個心智的，99+表示“有很多新消息”，至於具體多少，是幾百、幾千很多時候不是特別重要。所以問題就變得簡單多了，只要計算遊標是否在最新的100條消息以內還是以外；
2）合理利用數據結構：因為有羣內有很多人，每個人登錄的時候都需要統計，所以每次都去查 MySQL 是比較低效的，因此筆者的方案是在 Redis 裏設計一個有界的ZSET結構。

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

9、 百萬人超大羣聊的關鍵策略

9.1 概述

前面提到，設計目標是在同一個羣裏能支撐百萬人，從架構上可以看到，連接服務處於流量最前端，所以它的承載力直接決定了同時在線用户的上限。

影響它的因素有：

1）服務器自身配置：內存、CPU、網卡、Linux 支持的最大文件打開數；
2）應用自身配置：應用本身啓動需要的內存，如 Netty 依賴的堆外內存，大量的本地緩存；
3）性能要求：當連接數不斷變大時，消息分發的整體耗時肯定在不斷增加，因此要關注最慢的分發耗時要滿足即時性要求。
結合以上情況，可以測試出固定配置服務器單點能支持的最大用户連接數，假如單機能支持20000個用户連接，那麼百萬在線連接，在連接服務層用50個服務的集羣就能解決。

9.2 消息風暴

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

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

2）消息提醒風暴：一條新消息的產生，就要推送提醒消息百萬次，對服務器來説，要考量整體推送完成的時效性，如果時效性差，對有些用户來説，就是消息需要較長時間才刷出來，出現明顯的延遲。新消息持久化後，羣組服務 HTTP 回調一組連接服務，單羣百萬在線用户，需要50台連接服務集羣，那麼回調50次，為了保證時效性，因此這裏要併發回調，並設置合理的線程池，然後連接服務收到回調後也需要併發完成對羣用户的新消息提醒推送；

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

9.3 消息壓縮

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

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

經過測試：使用 protobuf 數據交換格式，平均每一個消息可以節省43%的字節大小，可以大大節省機房出口帶寬（詳讀《Protobuf從入門到精通，一篇就夠！》）。

9.4 塊消息

超大羣裏，消息推送的頻率很高，每一條消息推送都需要進行一次IO系統調用，顯然會影響服務器性能，可以採用將多個消息進行合併推送。

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

時間間隔是1秒，閾值是10，如果500毫秒內新增了10條消息，就合併推送這10條消息，時間週期重置；如果1秒內只新增了8條消息，那麼1秒後合併推送這8條消息。

這樣做的好處如下：

1）提升服務器性能：減少IO系統調用，減少用户態與內核態之前的切換；
2）減少傳輸量：合併消息後，可以減少傳輸多餘的消息頭，進一步壓縮消息大小；
3）提升用户體驗：一定程度上能減小消息風暴，消息渲染的節奏比較均勻，帶給用户更好的體驗。

10、 本文小結

在本文中，筆者介紹了從零開始搭建一個生產級百萬級羣聊的一些關鍵要點和實踐經驗，包括通信方案選型、消息存儲、消息順序、消息可靠性、高併發等方面，但仍有許多技術設計未涉及，比如冷熱羣、高低消息通道會放在未來的規劃裏。

IM開發業界沒有統一的標準，不同的產品有適合自己的技術方案，希望本文能夠帶給讀者更好地理解和應用這些技術實踐，為構建高性能、高可靠性的羣聊系統提供一定的參考。

11、 參考資料

[1]新手入門貼：史上最全Web端即時通訊技術原理詳解

[2]Web端即時通訊技術盤點：短輪詢、Comet、Websocket、SSE

[3]網頁端IM通信技術快速入門：短輪詢、長輪詢、SSE、WebSocket

[4]搞懂現代Web端即時通訊技術一文就夠：WebSocket、socket.io、SSE

[5]理論聯繫實際：從零理解WebSocket的通信原理、協議格式、安全性

[6]Web端即時通訊實踐乾貨：如何讓你的WebSocket斷網重連更快速？

[7]WebSocket從入門到精通，半小時就夠！

[8]一套分佈式IM即時通訊系統的技術選型和架構設計

[9]微信團隊分享：來看看微信十年前的IM消息收發架構，你做到了嗎

[10]攜程技術分享：億級流量的辦公IM及開放平台技術實踐

[11]轉轉平台IM系統架構設計與實踐(一)：整體架構設計

[12]一套億級用户的IM架構技術乾貨(下篇)：可靠性、有序性、弱網優化等

[13]從新手到專家：如何設計一套億級消息量的分佈式IM系統

[14]企業微信的IM架構設計揭秘：消息模型、萬人羣、已讀回執、消息撤回等

[15]融雲技術分享：全面揭秘億級IM消息的可靠投遞機制

[16]如何保證IM實時消息的“時序性”與“一致性”？

[17]IM單聊和羣聊中的在線狀態同步應該用“推”還是“拉”？

[18]IM羣聊消息如此複雜，如何保證不丟不重？

[19]現代IM系統中聊天消息的同步和存儲方案探討

[20]IM羣聊消息究竟是存1份(即擴散讀)還是存多份(即擴散寫)？

[21]一套高可用、易伸縮、高併發的IM羣聊、單聊架構方案設計實踐

[22]網易雲信技術分享：IM中的萬人羣聊技術方案實踐總結

[23]微信直播聊天室單房間1500萬在線的消息架構演進之路

[24]海量用户IM聊天室的架構設計與實踐

[25]IM技術乾貨：假如你來設計微信的羣聊，你該怎麼設計？

[26]百萬級成員實時社羣技術實現（消息系統篇）

（本文已同步發佈於：http://www.52im.net/thread-4789-1-1.html）