隨着移動互聯網的發展，即時通訊服務被廣泛應用到各個行業，客戶業務快速發展，傳統百人或千人上限的羣聊已經無法滿足很多業務發展需求，因此網易雲信IM專屬雲推出萬人羣服務。
本篇文章主要介紹網易雲信IM萬人羣的設計方案。
萬人羣場景需要解決以下問題：
- 消息需要按1:9999的比例進行轉發投遞，按常規消息處理流程將產生大量的子任務，對系統吞吐量的要求極高；
- 在微服務系統架構下，如果不採用一些優化方案，服務以及存儲（DB、緩存等）之間的QPS和網絡流量將非常高；
- 以羣爲單位的緩存（如羣成員列表）內存存儲開銷較大（假設一個成員200Byte，萬人羣約2MB）；
- 羣成員登錄後需要同步羣離線消息，智能手機上App前後臺切換產生的較多登錄同步消息協議，因此需要優化消息同步方案。
爲了解決以上問題，萬人羣技術方案採用了“聚合+分層/組+增量”的設計思路：
一、萬人羣消息處理流程：
- 按羣維護在線羣成員信息，主要包含兩部分（可以理解爲兩個緩存集合）
- 羣成員在線信息：即用戶在線狀態變化（上線、下線）時，更新相應羣的在線狀態信息（即動態維護羣有哪些成員在線）；
- 成員IM長連接信息：即用戶新登錄時，更新用戶的Link信息（即登錄所在Link的地址信息，消息轉發時根據Link地址路由消息）。
- IM Server收到羣消息後，按羣ID將消息路由到“羣消息服務”模塊；
- 羣消息模塊檢查並預處理消息內容，然後通過“羣成員在線狀態”服務獲取在線成員，完成消息轉發的基礎工作。爲了減少羣消息模塊和羣在線成員服務之間的網絡流量，採用了“本地緩存+增量同步”的緩存策略，即本地緩存記錄最後更新版本號和時間戳，每次同步羣在線成員前先檢查緩存版本號是否有變更，若有則按最後更新時間增量同步；
- 通過“羣成員在線服務”獲取在線羣成員的Link鏈接信息，按Link分組路由消息（分組路由的原因：同一Link上的全部羣成員只需要路由一條消息即可）。同樣爲了減少網絡開銷，成員Link信息也採用“本地緩存+增量同步”的方案；
- 羣消息採用“漫遊+歷史”的存儲方案，漫遊的消息存儲在分佈式緩存中，歷史消息異步寫入HBase。用戶登錄後可以通過漫遊快速的獲取到最新消息，並可以通過拉取歷史查看更早的消息。
二、萬人羣方案本地緩存增量同步策略
拋開羣在線狀態管理邏輯，羣成員在線狀態服務可以簡單理解爲分佈式集中緩存，增量同步技術方案如下：
- 數據緩存是一個集合，其包含了多個緩存數據項，每一個數據項帶有最後更新時間信息；另外緩存還有一個嚴格遞增的版本號；
- 緩存數據變更（新增、修改、刪除）後，需要增加版本號；
- 本地線程通過緩存管理讀取數據時，管理服務先檢查本地版本號和分佈式緩存中的版本號是否一致，若不一致則按本地最新時間戳增量同步新數據項，並更新本地的版本號和最後更新時間（爲了避免分佈式集中緩存中併發寫入導致的增量時間戳不可靠問題，增量更新時可以將本地記錄的最後更新時間戳向前推移，比如減少20ms）；
- 爲避免本地多線程併發讀取相同數據項導致併發更新本地緩存的問題，可以按緩存數據合併更新請求，即解決併發問題還可以減少網絡開銷；
- 緩存數據由大量數據項構成，爲了避免單個緩存數據太大，可以將數據項中的屬性業務場景精簡（冷熱分離），低頻次讀寫的屬性額外緩存。
三、萬人羣水平擴容方案
萬人羣採用大量本地緩存的方案解決消息處理性能和網絡流量的問題，因此本地存儲空間成了方案的瓶頸點。因此我們設計了分組路由的技術方案。
消息按羣ID和路由策略定向路由到指定分組（集羣）上處理，分組由多個計算節點組成，因此方案上可以做到分組內和分組間的水平擴縮容。
四、IM專屬雲
由於萬人羣對計算和存儲資源消耗比較高，在實施和運維方案上也有一定的特殊性，爲了保證業務的可靠性和穩定性，萬人大羣僅提供給專屬雲客戶。
網易雲信IM專屬雲以億級日活的公有云架構爲基礎，全面升級了業務技術架構和部署、運維方案，旨在爲雲信客戶提供更加穩定的IM服務，採用專屬雲方案，將獲得以下優勢：
- 專屬的獨立計算資源：不僅計算資源獨立，而且資源冗餘度比公有云更高，且不會受到公有云上其他客戶業務的影響；
- 專屬的獨立運維服務：專屬雲由資深的SRE團隊成員負責，運維經驗豐富，能夠根據客戶業務場景制定最佳的業務監控、彈性擴容、故障遷移等運維方案；
- 專屬的IM能力：由於專屬雲下計算資源獨立，業務場景特徵明確，因此可以使用萬人羣、百萬人聊天室等高級服務。
- 專屬的活動保障：每年可以獲得2次大型活動保障服務。
立即諮詢，立享專屬服務、專屬資源以及萬人大羣。