【網易實戰解讀】如何實現IM萬人羣聊？

隨着移動互聯網的發展，即時通信服務被普遍應用到各個行業，客戶業務快速發展，傳統百人或千人上限的羣聊已經沒法知足不少業務發展需求，所以網易雲信IM 專屬雲推出萬人羣服務。

本篇文章主要介紹網易雲信IM萬人羣的設計方案。

萬人羣場景須要解決如下問題：

• 消息須要按1:9999的比例進行轉發投遞，按常規消息處理流程將產生大量的子任務，對系統吞吐量的要求極高；
• 在微服務系統架構下，若是不採用一些優化方案，服務以及存儲（DB、緩存等）之間的QPS和網絡流量將很是高；
• 以羣爲單位的緩存（如羣成員列表）內存存儲開銷較大（假設一個成員200Byte，萬人羣約2MB）；
• 羣成員登陸後須要同步羣離線消息，智能手機上App先後臺切換產生的較多登陸同步消息協議，所以須要優化消息同步方案。

爲了解決以上問題，萬人羣技術方案採用了「聚合+分層/組+增量」的設計思路：

1、萬人羣消息處理流程

一、 按羣維護在線羣成員信息，主要包含兩部分（能夠理解爲兩個緩存集合）

a) 羣成員在線信息：即用戶在線狀態變化（上線、下線）時，更新相應羣的在線狀態信息（即動態維護羣有哪些成員在線）；

b) 成員IM長鏈接信息：即用戶新登陸時，更新用戶的Link信息（即登陸所在Link的地址信息，消息轉發時根據Link地址路由消息）。

二、 IM Server收到羣消息後，按羣ID將消息路由到「羣消息服務」模塊；

三、 羣消息模塊檢查並預處理消息內容，而後經過「羣成員在線狀態」服務獲取在線成員，完成消息轉發的基礎工做。爲了減小羣消息模塊和羣在線成員服務之間的網絡流量，採用了「本地緩存+增量同步」的緩存策略，即本地緩存記錄最後更新版本號和時間戳，每次同步羣在線成員前先檢查緩存版本號是否有變動，如有則按最後更新時間增量同步；

四、 經過「羣成員在線服務」獲取在線羣成員的Link連接信息，按Link分組路由消息（分組路由的緣由：同一Link上的所有羣成員只須要路由一條消息便可）。一樣爲了減小網絡開銷，成員Link信息也採用「本地緩存+增量同步」的方案；

五、 羣消息採用「漫遊+歷史」的存儲方案，漫遊的消息存儲在分佈式緩存中，歷史消息異步寫入HBase。用戶登陸後能夠經過漫遊快速的獲取到最新消息，並能夠經過拉取歷史查看更早的消息。

2、萬人羣方案本地緩存增量同步策略

拋開羣在線狀態管理邏輯，羣成員在線狀態服務能夠簡單理解爲分佈式集中緩存，增量同步技術方案以下：

1. 數據緩存是一個集合，其包含了多個緩存數據項，每個數據項帶有最後更新時間信息；另外緩存還有一個嚴格遞增的版本號；
2. 緩存數據變動（新增、修改、刪除）後，須要增長版本號；
3. 本地線程經過緩存管理讀取數據時，管理服務先檢查本地版本號和分佈式緩存中的版本號是否一致，若不一致則按本地最新時間戳增量同步新數據項，並更新本地的版本號和最後更新時間（爲了不分佈式集中緩存中併發寫入致使的增量時間戳不可靠問題，增量更新時能夠將本地記錄的最後更新時間戳向前推移，好比減小20ms）；
4. 爲避免本地多線程併發讀取相同數據項致使併發更新本地緩存的問題，能夠按緩存數據合併更新請求，即解決併發問題還能夠減小網絡開銷；
5. 緩存數據由大量數據項構成，爲了不單個緩存數據太大，能夠將數據項中的屬性業務場景精簡（冷熱分離），低頻次讀寫的屬性額外緩存。

3、萬人羣水平擴容方案

萬人羣採用大量本地緩存的方案解決消息處理性能和網絡流量的問題，所以本地存儲空間成了方案的瓶頸點。所以咱們設計了分組路由的技術方案。

消息按羣ID和路由策略定向路由到指定分組（集羣）上處理，分組由多個計算節點組成，所以方案上能夠作到分組內和分組間的水平擴縮容。

4、IM專屬雲

因爲萬人羣對計算和存儲資源消耗比較高，在實施和運維方案上也有必定的特殊性，爲了保證業務的可靠性和穩定性，萬人大羣僅提供給 專屬雲客戶。

網易雲信IM專屬雲以億級日活的公有云架構爲基礎，全面升級了業務技術架構和部署、運維方案，旨在爲雲信客戶提供更加穩定的IM服務，採用專屬雲方案，將得到如下優點：

• 專屬的獨立計算資源：不只計算資源獨立，並且資源冗餘度比公有云更高，且不會受到公有云上其餘客戶業務的影響；
• 專屬的獨立運維服務：專屬雲由資深的SRE團隊成員負責，運維經驗豐富，可以根據客戶業務場景制定最佳的業務監控、彈性擴容、故障遷移等運維方案；
• 專屬的IM能力：因爲專屬雲下計算資源獨立，業務場景特徵明確，所以可使用萬人羣、百萬人聊天室等高級服務。
• 專屬的活動保障：每一年能夠得到2次大型活動保障服務。

當即 諮詢，立享專屬服務、專屬資源以及萬人大羣。