本文來(lái)自網(wǎng)易云信團(tuán)隊(duì)的技術(shù)分享，原創(chuàng)發(fā)表于網(wǎng)易云信公眾號(hào)，原文鏈接：mp.weixin.qq.com/s/LT2dASI7QVpcOVxDAsMeVg，收錄時(shí)有改動(dòng)。
1、引言
在不了解IM技術(shù)的人眼里，群聊是再平常不過(guò)的功能而已，萬(wàn)人群聊？應(yīng)該也不難實(shí)現(xiàn)吧？！
確實(shí)，從前端功能界面上來(lái)看，群聊無(wú)非就是個(gè)循環(huán)向群?jiǎn)T發(fā)送消息的一對(duì)多聊天消息分發(fā)模式而已，難在何處？
真實(shí)的情況是，群聊是IM系統(tǒng)中的高難度技術(shù)點(diǎn)之一。難在哪？難在服務(wù)端！從某種角度上說(shuō)，群聊功能的架構(gòu)設(shè)計(jì)和技術(shù)實(shí)現(xiàn)的品質(zhì)，可以代表這款I(lǐng)M軟件的技術(shù)水平。
群聊從后臺(tái)的技術(shù)實(shí)現(xiàn)上說(shuō)，至少有以下難點(diǎn)：
1）如何高效地進(jìn)行大量群?jiǎn)T消息的分發(fā)？
2）如何高效地管理群?jiǎn)T的在線狀態(tài)？
3）如何高效地讀取群?jiǎn)T的在線狀態(tài)？
4）集群系統(tǒng)中，如何高效地保證群?jiǎn)T消息的準(zhǔn)確送達(dá)？
5）群聊消息該擴(kuò)散寫還是擴(kuò)散讀？
6）如何保證大量群聊消息分發(fā)的情況下不影響單聊消息體驗(yàn)？
7）如何應(yīng)對(duì)大群突發(fā)事件下的性能負(fù)載？
.... ....
目前，市面上主流的IM產(chǎn)品中，微信群是500人上限，QQ群是3000人上限（3000人群是按年付費(fèi)升級(jí)，很貴，不是為一般用戶準(zhǔn)備的）。一方面，從產(chǎn)品的定義上群成員數(shù)量不應(yīng)過(guò)多，另一方面，技術(shù)成本也是個(gè)不可回避的因素。萬(wàn)人群這種超大規(guī)模群的技術(shù)難度，更是難已想象。
本文內(nèi)容是網(wǎng)易云信團(tuán)隊(duì)為了響應(yīng)萬(wàn)人群聊功能需求，在設(shè)計(jì)實(shí)現(xiàn)萬(wàn)人群聊技術(shù)方案中總結(jié)的技術(shù)實(shí)踐，借此機(jī)會(huì)分享給各IM開(kāi)發(fā)者同行。
（本文同步發(fā)布于：http://www.52im.net/thread-2707-1-1.html）
學(xué)習(xí)交流：
- 即時(shí)通訊/推送技術(shù)開(kāi)發(fā)交流5群：215477170[推薦]
- 移動(dòng)端IM開(kāi)發(fā)入門文章：《新手入門一篇就夠：從零開(kāi)發(fā)移動(dòng)端IM》
2、概述
隨著移動(dòng)互聯(lián)網(wǎng)的發(fā)展，即時(shí)通訊服務(wù)被廣泛應(yīng)用到各個(gè)行業(yè)，客戶業(yè)務(wù)快速發(fā)展，傳統(tǒng)百人或千人上限的群聊已經(jīng)無(wú)法滿足很多業(yè)務(wù)發(fā)展需求，因此網(wǎng)易云信IM推出萬(wàn)人群服務(wù)。
萬(wàn)人群場(chǎng)景需要解決以下問(wèn)題：
1）消息需要按1:9999的比例進(jìn)行轉(zhuǎn)發(fā)投遞，按常規(guī)消息處理流程將產(chǎn)生大量的子任務(wù)，對(duì)系統(tǒng)吞吐量的要求極高；
2）在微服務(wù)系統(tǒng)架構(gòu)下，如果不采用一些優(yōu)化方案，服務(wù)以及存儲(chǔ)（DB、緩存等）之間的QPS和網(wǎng)絡(luò)流量將非常高；
3）以群為單位的緩存（如群成員列表）內(nèi)存存儲(chǔ)開(kāi)銷較大（假設(shè)一個(gè)成員200Byte，萬(wàn)人群約2MB）；
4）群成員登錄后需要同步群離線消息，智能手機(jī)上App前后臺(tái)切換產(chǎn)生的較多登錄同步消息協(xié)議，因此需要優(yōu)化消息同步方案。
為了解決以上問(wèn)題，萬(wàn)人群技術(shù)方案采用了“聚合+分層/組+增量”的設(shè)計(jì)思路：
3、萬(wàn)人群消息的處理流程
1）按群維護(hù)在線群成員信息，主要包含兩部分（可以理解為兩個(gè)緩存集合）：
a. 群成員在線信息：即用戶在線狀態(tài)變化（上線、下線）時(shí)，更新相應(yīng)群的在線狀態(tài)信息（即動(dòng)態(tài)維護(hù)群有哪些成員在線）；
b. 成員IM長(zhǎng)連接信息：即用戶新登錄時(shí)，更新用戶的Link信息（即登錄所在Link的地址信息，消息轉(zhuǎn)發(fā)時(shí)根據(jù)Link地址路由消息）。
2）IM Server收到群消息后，按群ID將消息路由到“群消息服務(wù)”模塊；
3）群消息模塊檢查并預(yù)處理消息內(nèi)容，然后通過(guò)“群成員在線狀態(tài)”服務(wù)獲取在線成員，完成消息轉(zhuǎn)發(fā)的基礎(chǔ)工作。為了減少群消息模塊和群在線成員服務(wù)之間的網(wǎng)絡(luò)流量，采用了“本地緩存+增量同步”的緩存策略，即本地緩存記錄最后更新版本號(hào)和時(shí)間戳，每次同步群在線成員前先檢查緩存版本號(hào)是否有變更，若有則按最后更新時(shí)間增量同步；
4）通過(guò)“群成員在線服務(wù)”獲取在線群成員的Link鏈接信息，按Link分組路由消息（分組路由的原因：同一Link上的全部群成員只需要路由一條消息即可）。同樣為了減少網(wǎng)絡(luò)開(kāi)銷，成員Link信息也采用“本地緩存+增量同步”的方案；
5）群消息采用“漫游+歷史”的存儲(chǔ)方案，漫游的消息存儲(chǔ)在分布式緩存中，歷史消息異步寫入HBase。用戶登錄后可以通過(guò)漫游快速的獲取到最新消息，并可以通過(guò)拉取歷史查看更早的消息。
4、萬(wàn)人群方案本地緩存增量同步策略
拋開(kāi)群在線狀態(tài)管理邏輯，群成員在線狀態(tài)服務(wù)可以簡(jiǎn)單理解為分布式集中緩存。
增量同步技術(shù)方案如下：
如上圖所示：
1）數(shù)據(jù)緩存是一個(gè)集合，其包含了多個(gè)緩存數(shù)據(jù)項(xiàng)，每一個(gè)數(shù)據(jù)項(xiàng)帶有最后更新時(shí)間信息；另外緩存還有一個(gè)嚴(yán)格遞增的版本號(hào)；
2）緩存數(shù)據(jù)變更（新增、修改、刪除）后，需要增加版本號(hào)；
3）本地線程通過(guò)緩存管理讀取數(shù)據(jù)時(shí)，管理服務(wù)先檢查本地版本號(hào)和分布式緩存中的版本號(hào)是否一致，若不一致則按本地最新時(shí)間戳增量同步新數(shù)據(jù)項(xiàng)，并更新本地的版本號(hào)和最后更新時(shí)間（為了避免分布式集中緩存中并發(fā)寫入導(dǎo)致的增量時(shí)間戳不可靠問(wèn)題，增量更新時(shí)可以將本地記錄的最后更新時(shí)間戳向前推移，比如減少20ms）；
4）為避免本地多線程并發(fā)讀取相同數(shù)據(jù)項(xiàng)導(dǎo)致并發(fā)更新本地緩存的問(wèn)題，可以按緩存數(shù)據(jù)合并更新請(qǐng)求，即解決并發(fā)問(wèn)題還可以減少網(wǎng)絡(luò)開(kāi)銷；
5）緩存數(shù)據(jù)由大量數(shù)據(jù)項(xiàng)構(gòu)成，為了避免單個(gè)緩存數(shù)據(jù)太大，可以將數(shù)據(jù)項(xiàng)中的屬性業(yè)務(wù)場(chǎng)景精簡(jiǎn)（冷熱分離），低頻次讀寫的屬性額外緩存。
5、萬(wàn)人群水平擴(kuò)容方案
萬(wàn)人群采用大量本地緩存的方案解決消息處理性能和網(wǎng)絡(luò)流量的問(wèn)題，因此本地存儲(chǔ)空間成了方案的瓶頸點(diǎn)。因此我們?cè)O(shè)計(jì)了分組路由的技術(shù)方案。
消息按群ID和路由策略定向路由到指定分組（集群）上處理，分組由多個(gè)計(jì)算節(jié)點(diǎn)組成，因此方案上可以做到分組內(nèi)和分組間的水平擴(kuò)縮容。
6、作為“云”服務(wù)，網(wǎng)易云信是如何實(shí)現(xiàn)萬(wàn)人群所需的計(jì)算資源的？
由于萬(wàn)人群對(duì)計(jì)算和存儲(chǔ)資源消耗比較高，在實(shí)施和運(yùn)維方案上也有一定的特殊性，為了保證業(yè)務(wù)的可靠性和穩(wěn)定性，網(wǎng)易云信是將萬(wàn)人大群的能力，僅提供給專屬的云客戶（普通公有云客戶是無(wú)法使用的）。
之所以能從軟硬件基礎(chǔ)設(shè)施上為萬(wàn)人群提供保障，網(wǎng)易云信的IM專有云必須具備以下資源能力：
1）需要專屬的獨(dú)立計(jì)算資源：保持計(jì)算資源獨(dú)立，且資源冗余度比公有云高，且需要保證不會(huì)受到公有云上其他客戶業(yè)務(wù)的影響；
2）需要專屬的獨(dú)立運(yùn)維服務(wù)：從而根據(jù)客戶業(yè)務(wù)場(chǎng)景制定最佳的業(yè)務(wù)監(jiān)控、彈性擴(kuò)容、故障遷移等運(yùn)維方案。
總之，萬(wàn)人群聊的實(shí)現(xiàn)，過(guò)硬的技術(shù)方案設(shè)計(jì)和技術(shù)實(shí)現(xiàn)只是一方面，基礎(chǔ)計(jì)算設(shè)施資源和運(yùn)維能力也是不可或缺。
所以，從今以后，不要隨隨便便就喊萬(wàn)人群聊，甚至十萬(wàn)人群聊，這不是想實(shí)現(xiàn)就能實(shí)現(xiàn)的哦！
附錄：更多群聊相關(guān)技術(shù)文章
《快速裂變：見(jiàn)證微信強(qiáng)大后臺(tái)架構(gòu)從0到1的演進(jìn)歷程（一）》
《如何保證IM實(shí)時(shí)消息的“時(shí)序性”與“一致性”？》
《IM單聊和群聊中的在線狀態(tài)同步應(yīng)該用“推”還是“拉”？》
《IM群聊消息如此復(fù)雜，如何保證不丟不重？》
《微信后臺(tái)團(tuán)隊(duì)：微信后臺(tái)異步消息隊(duì)列的優(yōu)化升級(jí)實(shí)踐分享》
《移動(dòng)端IM中大規(guī)模群消息的推送如何保證效率、實(shí)時(shí)性？》
《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲(chǔ)方案探討》
《關(guān)于IM即時(shí)通訊群聊消息的亂序問(wèn)題討論》
《IM群聊消息的已讀回執(zhí)功能該怎么實(shí)現(xiàn)？》
《IM群聊消息究竟是存1份(即擴(kuò)散讀)還是存多份(即擴(kuò)散寫)？》
《一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構(gòu)方案設(shè)計(jì)實(shí)踐》
《[技術(shù)腦洞] 如果把14億中國(guó)人拉到一個(gè)微信群里技術(shù)上能實(shí)現(xiàn)嗎？》
《IM群聊機(jī)制，除了循環(huán)去發(fā)消息還有什么方式？如何優(yōu)化？》
《網(wǎng)易云信技術(shù)分享：IM中的萬(wàn)人群聊技術(shù)方案實(shí)踐總結(jié)》
>> 更多同類文章 ……
（本文同步發(fā)布于：http://www.52im.net/thread-2707-1-1.html）