跟著源碼學(xué)IM(十)：基于Netty，搭建高性能IM集群（含技術(shù)思路+源碼）
本文原題“搭建高性能的IM系統(tǒng)”，作者“劉蒞”，內(nèi)容有修訂和改動。為了尊重原創(chuàng)，如需轉(zhuǎn)載，請聯(lián)系作者獲得授權(quán)。
1、引言
相信很多朋友對微信、QQ等聊天軟件的實(shí)現(xiàn)原理都非常感興趣，筆者同樣對這些軟件有著深厚的興趣。而且筆者在公司也是做IM的，公司的IM每天承載著上億條消息的發(fā)送！
正好有這樣的技術(shù)資源和條件，所以前段時間，筆者利用業(yè)余時間，基于Netty開發(fā)了一套基本功能比較完善的IM系統(tǒng)。該系統(tǒng)支持私聊、群聊、會話管理、心跳檢測，支持服務(wù)注冊、負(fù)載均衡，支持任意節(jié)點(diǎn)水平擴(kuò)容。
這段時間，網(wǎng)上的一些讀者，也希望筆者分享一些Netty或者IM相關(guān)的知識，所以今天筆者把開發(fā)的這套IM系統(tǒng)分享給大家。
本文將根據(jù)筆者這次的業(yè)余技術(shù)實(shí)踐，為你講述如何基于Netty+Zk+Redis來搭建一套高性能IM集群，包括本次實(shí)現(xiàn)IM集群的技術(shù)原理和實(shí)例代碼，希望能帶給你啟發(fā)。
學(xué)習(xí)交流：
- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》
- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK?
（本文已同步發(fā)布于：http://www.52im.net/thread-3816-1-1.html?）
2、本文源碼
主地址：https://github.com/nicoliuli/chat
備地址：https://github.com/52im/chat
源碼的目錄結(jié)構(gòu)，如下圖所示：
3、知識準(zhǔn)備
* 重要提示：本文不是一篇即時通訊理論文章，文章內(nèi)容來自代碼實(shí)戰(zhàn)，如果你對即時通訊（IM）技術(shù)理論了解的太少，建議先詳細(xì)閱讀：《新手入門一篇就夠：從零開發(fā)移動端IM》。
可能有人不知道 Netty 是什么，這里簡單介紹下：
Netty 是一個 Java 開源框架。Netty 提供異步的、事件驅(qū)動的網(wǎng)絡(luò)應(yīng)用程序框架和工具，用以快速開發(fā)高性能、高可靠性的網(wǎng)絡(luò)服務(wù)器和客戶端程序。
也就是說，Netty 是一個基于 NIO 的客戶、服務(wù)器端編程框架，使用Netty 可以確保你快速和簡單的開發(fā)出一個網(wǎng)絡(luò)應(yīng)用，例如實(shí)現(xiàn)了某種協(xié)議的客戶，服務(wù)端應(yīng)用。
Netty 相當(dāng)簡化和流線化了網(wǎng)絡(luò)應(yīng)用的編程開發(fā)過程，例如，TCP 和 UDP 的 Socket 服務(wù)開發(fā)。
以下是有關(guān)Netty的入門文章：
1）新手入門：目前為止最透徹的的Netty高性能原理和框架架構(gòu)解析
2）寫給初學(xué)者：Java高性能NIO框架Netty的學(xué)習(xí)方法和進(jìn)階策略
3）史上最通俗Netty框架入門長文：基本介紹、環(huán)境搭建、動手實(shí)戰(zhàn)
如果你連Java的NIO都不知道是什么，下面的文章建議優(yōu)先讀：
1）少啰嗦！一分鐘帶你讀懂Java的NIO和經(jīng)典IO的區(qū)別
2）史上最強(qiáng)Java NIO入門：擔(dān)心從入門到放棄的，請讀這篇！
3）Java的BIO和NIO很難懂？用代碼實(shí)踐給你看，再不懂我轉(zhuǎn)行！
Netty源碼和API的在線查閱地址：
1）Netty-4.1.x 完整源碼（在線閱讀版）
2）Netty-4.1.x API文檔（在線版）
4、系統(tǒng)架構(gòu)
系統(tǒng)的架構(gòu)如上圖所示：整個系統(tǒng)是一個C/S系統(tǒng)，客戶端沒有做復(fù)雜的圖形化界面而是用Java終端開發(fā)的（黑窗口），服務(wù)端IM實(shí)例是Netty寫的socket服務(wù)。
ZK作為服務(wù)注冊中心，Redis用來做分布式會話的緩存，并保存用戶信息和輕量級的消息隊(duì)列。
對于整個系統(tǒng)架構(gòu)中各部分的工作原理，我們將在接下來的各章節(jié)中一一介紹。
5、服務(wù)端的工作原理
在上述架構(gòu)中：NettyServer啟動，每啟動一臺Server節(jié)點(diǎn)，都會把自身的節(jié)點(diǎn)信息，如：ip、port等信息注冊到ZK上（臨時節(jié)點(diǎn)）。
正如上節(jié)架構(gòu)圖上啟動了兩臺NettyServer，所以ZK上會保存兩個Server的信息。
同時ZK將監(jiān)聽每臺Server節(jié)點(diǎn)，如果Server宕機(jī)ZK就會刪除當(dāng)前機(jī)器所注冊的信息（把臨時節(jié)點(diǎn)刪除），這樣就完成了簡單的服務(wù)注冊的功能。
6、客戶端的工作原理
Client啟動時，會先從ZK上隨機(jī)選擇一個可用的NettyServer（隨機(jī)表示可以實(shí)現(xiàn)負(fù)載均衡），拿到NettyServer的信息（IP和port）后與NettyServer建立鏈接。
鏈接建立起來后，NettyServer端會生成一個Session（即會話），用來把當(dāng)前客戶端的Channel等信息組裝成一個Session對象，保存在一個SessionMap里，同時也會把這個Session保存在Redis中。
這個會話特別重要，通過會話，我們能獲取當(dāng)前Client和NettyServer的Channel等信息。
7、Session的作用
我們啟動多個Client，由于每個Client啟動，都會先從ZK上隨機(jī)獲取NettyServer的的信息，所以如果啟動多個Client，就會連接到不同的NettyServer上。
熟悉Netty的朋友都知道，Client與Server建立接連后會產(chǎn)生一個Channel，通過Channel，Client和Server才能進(jìn)行正常的網(wǎng)絡(luò)數(shù)據(jù)傳輸。
如果Client1和Client2連接在同一個Server上：那么Server通過SessionMap分別拿到Client1和Client2的會話，會話中包含Channel信息，有了兩個Client的Channel，Client1和Client2便可完成消息通信。
如果Client1和Client2連接到不同的NettyServer上：Client1和Client2要進(jìn)行通信，該怎么辦？這個問題放在后面解答。
8、高效的數(shù)據(jù)傳輸
無論是IM系統(tǒng)，還是分布式的RPC框架，高效的網(wǎng)絡(luò)數(shù)據(jù)傳輸，無疑會極大的提升系統(tǒng)的性能。
數(shù)據(jù)通過網(wǎng)絡(luò)傳輸時，一般把對象通序列化成二進(jìn)制字節(jié)流數(shù)組，然后將數(shù)據(jù)通過socket傳給對方服務(wù)器，對方服務(wù)器拿到二進(jìn)制字節(jié)流后再反序列化成對象，達(dá)到遠(yuǎn)程通信的目的。
在Java領(lǐng)域，Java序列化對象的方式有嚴(yán)重的性能問題，業(yè)界常用谷歌的protobuf來實(shí)現(xiàn)序列化反序列化（見《Protobuf通信協(xié)議詳解：代碼演示、詳細(xì)原理介紹等》）。
protobuf支持不同的編程語言，可以實(shí)現(xiàn)跨語言的系統(tǒng)調(diào)用，并且有著極高的序列化反序列化性能，本系統(tǒng)也采用protobuf來做數(shù)據(jù)的序列化。
關(guān)于Protobuf的基本認(rèn)之，下面這幾篇可以深入讀一讀：
《強(qiáng)列建議將Protobuf作為你的即時通訊應(yīng)用數(shù)據(jù)傳輸格式》
《全方位評測：Protobuf性能到底有沒有比JSON快5倍？》
《金蝶隨手記團(tuán)隊(duì)分享：還在用JSON? Protobuf讓數(shù)據(jù)傳輸更省更快(原理篇)》
另外：《一套海量在線用戶的移動端IM架構(gòu)設(shè)計(jì)實(shí)踐分享(含詳細(xì)圖文)》一文中，“3、協(xié)議設(shè)計(jì)”這一節(jié)有關(guān)于protobuf在IM中的實(shí)戰(zhàn)設(shè)計(jì)和使用，可以一并學(xué)習(xí)一下。
9、聊天協(xié)議定義
我們在使用各種聊天App時，會發(fā)各種各樣的消息，每種消息都會對應(yīng)不同的消息格式（即“聊天協(xié)議”）。
聊天協(xié)議中主要包含幾種重要的信息：
1）消息類型；
2）發(fā)送時間；
3）消息的收發(fā)人；
4）聊天類型（群聊或私聊）。
我的這套IM系統(tǒng)中，聊天協(xié)議定義如下：
syntax = "proto3";
option java_package = "model.chat";
option java_outer_classname = "RpcMsg";
message Msg{
????string msg_id = 1;
????int64 from_uid = 2;
????int64 to_uid = 3;
????int32 format = 4;
????int32 msg_type = 5;
????int32 chat_type = 6;
????int64 timestamp = 7;
????string body = 8;
????repeated int64 to_uid_list = 9;
}
如上面的protobuf代碼，字段的具體含義如下：
1）msg_id：表示消息的唯一id，可以用UUID表示；
2）from_uid：消息發(fā)送者的uid；
3）to_uid：消息接收者的uid；
4）format：消息格式，我們使用各種聊天軟件時，會發(fā)送文字消息，語音消息，圖片消息等等等等，每種消息有不同的消息格式，我們用format來表示（由于本系統(tǒng)是java終端，format字段沒有太大含義，可有可無）；
5）msg_type：消息類型，比如登錄消息、聊天消息、ack消息、ping、pong消息；
6）chat_type：聊天類型，如群聊、私聊；
7）timestamp：發(fā)送消息的時間戳；
8）body：消息的具體內(nèi)容，載體；
9）to_uid_list：這個字段用戶群聊消息提高群聊消息的性能，具體作用會在群聊原理部分詳細(xì)解釋。
10、私聊消息發(fā)送原理
Client1給Client2發(fā)消息時，我們需要構(gòu)建上節(jié)中的消息體。
具體就是：from_uid是Client1的uid、to_uid是Client2的uid。
NettyServer收到消息后的處理邏輯是：
1）解析到to_uid字段；
2）從SessionMap或者Redis中保存的Session集合中獲取to_uid即Client2的Session；
3）從Session中取出Client2的Channel；
4）然后將消息通過Client2的Channel發(fā)給Client2。
11、群聊消息發(fā)送原理
群聊消息的分發(fā)通常有兩種技術(shù)實(shí)現(xiàn)方式，我們一一來看看。
方式一：假設(shè)一個群有100人，如果Client1給一個群的所有人發(fā)消息，其實(shí)相當(dāng)于Client1分別給其余99人分別發(fā)一條消息。我們可以直接在Client端，通過循環(huán)，分別給群里的99人發(fā)消息即可，相當(dāng)于Client發(fā)送給NettyServer發(fā)送了99次相同的消息（除了to_uid不同）。
上述方案有很嚴(yán)重的性能問題：Client1通過循環(huán)99次，分別把消息發(fā)給NettyServer，NettyServer收到這99條消息后，分別將消息發(fā)給群內(nèi)其余的用戶。先拋開移動端的特殊性（比如循環(huán)還沒完成手機(jī)就有可能退到后臺被系統(tǒng)掛起），顯然Client1到NettyServer的99次循環(huán)存在明顯不合理地方。
方式二：上節(jié)的消息體中to_uid_list字段就是為了解決這個方式一的性能問題的。Client1把群內(nèi)其余99個Client的uid保存在to_uid_list中，然后NettyServer只發(fā)一條消息，NettyServer收到這一條消息后，通過to_uid_list字段解析群內(nèi)其余99的Client的uid，再通過循環(huán)把消息分別發(fā)送給群內(nèi)其余的Client。
可以看到：方式二的群聊時，Client1與NettyServer只進(jìn)行1次消息傳輸，相比于方式一，效率提高了50%。
11、技術(shù)關(guān)鍵點(diǎn)1：客戶端分別連接在不同IM實(shí)例時如何通信？
針對本文中的架構(gòu)，如果多個Client分別連接在不同的Server上，Client之間應(yīng)該如何通信呢？
為了回答這個問題，我們首先要明白Session的作用。
我們做過JavaWeb開發(fā)的朋友都知道，Session用來保存用戶的登錄信息。
在IM系統(tǒng)中也是如此：Session中保存用戶的Channel信息。當(dāng)Client與Server建立鏈接成功后，會產(chǎn)生一個Channel，Client和Server是通過Channel，實(shí)現(xiàn)數(shù)據(jù)傳輸。當(dāng)兩端鏈接建立起來后，Server會構(gòu)建出一個Session對象，保存uid和Channel等信息，并把這個Session保存在一個SessionMap里（NettyServer的內(nèi)存里），uid為key，我們可以通過uid就可以找到這個uid對應(yīng)的Session。
但只有SessionMap還不夠：我們需要利用Redis，它的作用是保存整個NettyServer集群全部鏈接成功的用戶，這也是一種Session，但這種Session沒有保存uid和Channel的對應(yīng)關(guān)系，而是保存Client鏈接到NettyServer的信息，如Client鏈接到的這個NettyServer的ip、port等。通過uid，我們同樣可以從Redis中拿到當(dāng)前Client鏈接到的NettyServer的信息。正是有了這個信息，我們才能做到，NettyServer集群任意節(jié)點(diǎn)水平擴(kuò)容。
當(dāng)用戶量少的時候：我們只需要一臺NettyServer節(jié)點(diǎn)便可以扛住流量，所有的Client鏈接到同一個NettyServer上，并在NettyServer的SessionMap中保存每個Client的會話。Client1與Client2通信時，Client1把消息發(fā)給NettyServer，NettyServer從SessionMap中取出Client2的Session和Channel，將消息發(fā)給Client2。
隨著用戶量不斷增多：一臺NettyServer不夠，我們增加了幾臺NettyServer，這時Client1鏈接到NettyServer1上并在SessionMap和Redis中保存了會話和Client1的鏈接信息，Client2鏈接到NettyServer2上并在SessionMap和Redis中保存了會話和Client2的鏈接信息。Client1給Client2發(fā)消息時，通過NettyServer1的SessionMap找不到Client2的會話，消息無法發(fā)送，于是便從Redis中獲取Client2鏈接在哪臺NettyServer上。獲取到Client2所鏈接的NettyServer信息后，我們可以把消息轉(zhuǎn)發(fā)給NettyServer2，NettyServer2收到消息后，從NettyServer2的SessionMap中獲取Client2的Session和Channel，然后將消息發(fā)送給Client2。
那么：NettyServer1的消息如何轉(zhuǎn)發(fā)給NettyServer2呢？答案是通過消息隊(duì)列，如Redis中的list數(shù)據(jù)結(jié)構(gòu)。每臺NettyServer啟動后都需要監(jiān)聽一個自己的Redis中的消息隊(duì)列，這個隊(duì)列用戶接收其他NettyServer轉(zhuǎn)發(fā)給當(dāng)前NettyServer的消息。
* Jack Jiang點(diǎn)評：上述集群方案中，Redis既作為在線用戶列表存儲中心，又作為集群中不同IM長連接實(shí)例的消息中轉(zhuǎn)服務(wù)（此時的Redis作用相當(dāng)于MQ），那Redis不就成為了整個分布式集群的單點(diǎn)瓶頸了嗎？
12、技術(shù)關(guān)鍵點(diǎn)2：鏈接斷開，如何處理？
如果Client與NettyServer，由于某種原因（客戶端退出、服務(wù)端重啟、網(wǎng)絡(luò)因素等）斷開鏈接，我們必須要從SessionMap刪除會話和Redis中保留的數(shù)據(jù)。
如果不清除這兩類數(shù)據(jù)的話，很有可能Client1發(fā)送給Client2的消息，可能會發(fā)給其他用戶，或者就算Client2處于登錄狀態(tài)，Client2也收到不到消息。
我們可以在Netty框架中的channelInactive方法里，處理鏈接斷開后的會話清除操作。
13、技術(shù)關(guān)鍵點(diǎn)3：ping、pong的作用
當(dāng)Client與NettyServer建立鏈接后，由于雙端網(wǎng)絡(luò)較差，Client與NettyServer斷開鏈接后，如果NettyServer沒有感知到，也就沒有清除SessionMap和Redis中的數(shù)據(jù)，這將會造成嚴(yán)重的問題（對于服務(wù)端來說，這個Client的會話實(shí)際處于“假死”狀態(tài)，消息是無法實(shí)時發(fā)送過去的）。
此時就需要一種ping/pong機(jī)制（也就是心跳機(jī)制啦）。
實(shí)現(xiàn)原理就是：通過定時任務(wù)，Client每隔一段時間給NettyServer發(fā)一個ping消息，NettyServer收到ping消息后給客戶端回復(fù)一個pong消息，確?？蛻舳撕头?wù)端能一直保持鏈接狀態(tài)。如果Client與NettyServer斷連了，NettyServer可以立即發(fā)現(xiàn)并清空會話數(shù)據(jù)。Netty中的我們可以在Pipeline中添加IdleStateHandler，可達(dá)到這樣的目的。
如果你不明白心跳的作用，務(wù)必讀以下文章：
《為何基于TCP協(xié)議的移動端IM仍然需要心跳?；顧C(jī)制？》
《一文讀懂即時通訊應(yīng)用中的網(wǎng)絡(luò)心跳包機(jī)制：作用、原理、實(shí)現(xiàn)思路等》
也可以學(xué)習(xí)一下主流IM的心跳邏輯：
《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺?；顚?shí)戰(zhàn)分享(進(jìn)程保活篇)》
《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺?；顚?shí)戰(zhàn)分享(網(wǎng)絡(luò)保活篇)》
《移動端IM實(shí)踐：實(shí)現(xiàn)Android版微信的智能心跳機(jī)制》
《移動端IM實(shí)踐：WhatsApp、Line、微信的心跳策略分析》
如果覺得理論不夠直觀，下面的代碼實(shí)例可以直觀地進(jìn)行學(xué)習(xí)：
《正確理解IM長連接的心跳及重連機(jī)制，并動手實(shí)現(xiàn)（有完整IM源碼）》
《一種Android端IM智能心跳算法的設(shè)計(jì)與實(shí)現(xiàn)探討（含樣例代碼）》
《自已開發(fā)IM有那么難嗎？手把手教你自擼一個Andriod版簡易IM (有源碼)》
《手把手教你用Netty實(shí)現(xiàn)網(wǎng)絡(luò)通信程序的心跳機(jī)制、斷線重連機(jī)制》
其實(shí)，心跳算法的實(shí)際效果，還是有一些邏輯技巧的，以下兩篇建議必讀：
《Web端即時通訊實(shí)踐干貨：如何讓你的WebSocket斷網(wǎng)重連更快速？》
《融云技術(shù)分享：融云安卓端IM產(chǎn)品的網(wǎng)絡(luò)鏈路?；罴夹g(shù)實(shí)踐》
14、技術(shù)關(guān)鍵點(diǎn)4：為Server和Client添加Hook
如果NettyServer重啟了或者進(jìn)程被kill掉，我們需要清除當(dāng)前節(jié)點(diǎn)的SessionMap（其實(shí)不用清理SessionMap，數(shù)據(jù)在內(nèi)存里重啟會自動刪除的）和Redis保存的Client的鏈接信息。
我們需要遍歷SessionMap找出所有的uid，然后一一清除Redis的數(shù)據(jù)，然后優(yōu)雅退出。此時，我們就需要為我們的NettyServer添加一個Hook，來做數(shù)據(jù)清理。
15、技術(shù)關(guān)鍵點(diǎn)5：對方不在線該如何處理消息？
Client1給對方發(fā)消息，我們通過SessionMap或Redis拿不到對方的會話數(shù)據(jù)，這就表明對方不在線。
此時：我們需要把消息存儲在離線消息表中，當(dāng)對方下次登錄時，NettyServer查離線消息表，把消息發(fā)給登錄用戶（最好是批量發(fā)送，提高性能）。
IM中的離線消息處理，也不是個簡單的技術(shù)點(diǎn)，有興趣可以深入學(xué)習(xí)一下：
《IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(二)：保證離線消息的可靠投遞》
《阿里IM技術(shù)分享(六)：閑魚億級IM消息系統(tǒng)的離線推送到達(dá)率優(yōu)化》
《IM開發(fā)干貨分享：我是如何解決大量離線消息導(dǎo)致客戶端卡頓的》
《IM開發(fā)干貨分享：如何優(yōu)雅的實(shí)現(xiàn)大量離線消息的可靠投遞》
《喜馬拉雅億級用戶量的離線消息推送系統(tǒng)架構(gòu)設(shè)計(jì)實(shí)踐》
16、寫在最后
代碼寫成這樣，也算是了確了自已手?jǐn)]IM的心愿。唯一遺憾的是，時間比較緊張，還沒來得及實(shí)現(xiàn)消息ack機(jī)制，保證消息一定會送達(dá)，這個筆者以后會補(bǔ)充上去的。
好了，這就是我開發(fā)的這個簡易的聊天系統(tǒng)，麻雀雖小，五臟俱全，大家有什么不明白的地方，可以直接在下方留言，筆者會一一回復(fù)的，謝謝大家。
17、系列文章
《跟著源碼學(xué)IM(一)：手把手教你用Netty實(shí)現(xiàn)心跳機(jī)制、斷線重連機(jī)制》
《跟著源碼學(xué)IM(二)：自已開發(fā)IM很難？手把手教你擼一個Andriod版IM》
《跟著源碼學(xué)IM(三)：基于Netty，從零開發(fā)一個IM服務(wù)端》
《跟著源碼學(xué)IM(四)：拿起鍵盤就是干，教你徒手開發(fā)一套分布式IM系統(tǒng)》
《跟著源碼學(xué)IM(五)：正確理解IM長連接、心跳及重連機(jī)制，并動手實(shí)現(xiàn)》
《跟著源碼學(xué)IM(六)：手把手教你用Go快速搭建高性能、可擴(kuò)展的IM系統(tǒng)》
《跟著源碼學(xué)IM(七)：手把手教你用WebSocket打造Web端IM聊天》
《跟著源碼學(xué)IM(八)：萬字長文，手把手教你用Netty打造IM聊天》
《跟著源碼學(xué)IM(九)：基于Netty實(shí)現(xiàn)一套分布式IM系統(tǒng)》
《跟著源碼學(xué)IM(十)：基于Netty，搭建高性能IM集群（含技術(shù)思路+源碼）》（* 本文）
18、參考資料
[1]?新手入門：目前為止最透徹的的Netty高性能原理和框架架構(gòu)解析
[2]?寫給初學(xué)者：Java高性能NIO框架Netty的學(xué)習(xí)方法和進(jìn)階策略
[3]?史上最強(qiáng)Java NIO入門：擔(dān)心從入門到放棄的，請讀這篇！
[4]?Java的BIO和NIO很難懂？用代碼實(shí)踐給你看，再不懂我轉(zhuǎn)行！
[5]?史上最通俗Netty框架入門長文：基本介紹、環(huán)境搭建、動手實(shí)戰(zhàn)
[6]?理論聯(lián)系實(shí)際：一套典型的IM通信協(xié)議設(shè)計(jì)詳解
[7]?淺談IM系統(tǒng)的架構(gòu)設(shè)計(jì)
[8]?簡述移動端IM開發(fā)的那些坑：架構(gòu)設(shè)計(jì)、通信協(xié)議和客戶端
[9]?一套海量在線用戶的移動端IM架構(gòu)設(shè)計(jì)實(shí)踐分享(含詳細(xì)圖文)
[10]?一套原創(chuàng)分布式即時通訊(IM)系統(tǒng)理論架構(gòu)方案
[11]??一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構(gòu)方案設(shè)計(jì)實(shí)踐
[12]?一套億級用戶的IM架構(gòu)技術(shù)干貨(上篇)：整體架構(gòu)、服務(wù)拆分等
[13]?一套億級用戶的IM架構(gòu)技術(shù)干貨(下篇)：可靠性、有序性、弱網(wǎng)優(yōu)化等
[14]?從新手到專家：如何設(shè)計(jì)一套億級消息量的分布式IM系統(tǒng)
[15]?基于實(shí)踐：一套百萬消息量小規(guī)模IM系統(tǒng)技術(shù)要點(diǎn)總結(jié)
（本文已同步發(fā)布于：http://www.52im.net/thread-3816-1-1.html?）
