本文由阿里閑魚技術(shù)團(tuán)隊(duì)景松分享，原題“到達(dá)率99.9%：閑魚消息在高速上換引擎（集大成）”，有修訂和改動(dòng)，感謝作者的分享。
1、引言
在2020年年初的時(shí)候接手了閑魚的IM即時(shí)消息系統(tǒng)，當(dāng)時(shí)的消息存在各種問題，網(wǎng)上的用戶輿情也是接連不斷。
典型的問題，比如：
- 1）“聊天消息經(jīng)常丟失”；
- 2）“消息用戶頭像亂了”；
- 3）“訂單狀態(tài)不對(duì)”（相信現(xiàn)在看文章的你還在吐槽閑魚的消息）。
所以閑魚的即時(shí)消息系統(tǒng)穩(wěn)定性、可靠性是一個(gè)亟待解決的問題。
我們調(diào)研了集團(tuán)內(nèi)的一些解決方案，例如釘釘?shù)腎MPass。如果貿(mào)然直接遷移，技術(shù)成本和風(fēng)險(xiǎn)都是比較大，包括服務(wù)端數(shù)據(jù)需要雙寫、新老版本兼容等。
那么基于閑魚現(xiàn)有的即時(shí)消息系統(tǒng)架構(gòu)和技術(shù)體系，如何來優(yōu)化它的消息穩(wěn)定性、可靠性？應(yīng)該從哪里開始治理？當(dāng)前系統(tǒng)現(xiàn)狀到底是什么樣？如何客觀進(jìn)行衡量？希望本文能讓大家看到一個(gè)不一樣的閑魚即時(shí)消息系統(tǒng)。
PS：如果您對(duì)IM消息可靠性還沒有概念，建議先閱讀這篇入門文章《零基礎(chǔ)IM開發(fā)入門(三)：什么是IM系統(tǒng)的可靠性？》。
（本文同步發(fā)布于：http://www.52im.net/thread-3706-1-1.html）
2、系列文章
本文是系列文章的第4篇，總目錄如下：
3、行業(yè)方案
經(jīng)過查閱網(wǎng)上分享的主流消息可靠投遞技術(shù)方案，我進(jìn)行了簡單總結(jié)。
通常IM消息的投遞鏈路大致分為三步：
- 1）發(fā)送者發(fā)送；
- 2）服務(wù)端接收然后落庫；
- 3）服務(wù)端通知接收端。
特別是移動(dòng)端的網(wǎng)絡(luò)環(huán)境比較復(fù)雜：
- 1）可能你發(fā)著消息，網(wǎng)絡(luò)突然斷掉了；
- 2）可能消息正在發(fā)送中，網(wǎng)絡(luò)突然好了，需要重發(fā)。
技術(shù)原理圖大如下：
PS：可能很多人對(duì)移動(dòng)網(wǎng)絡(luò)的復(fù)雜性沒有個(gè)系統(tǒng)的認(rèn)知，以下文章有必要系統(tǒng)閱讀：
- 《通俗易懂，理解移動(dòng)網(wǎng)絡(luò)的“弱”和“慢”》
- 《史上最全移動(dòng)弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》
- 《為什么WiFi信號(hào)差？一文即懂！》
- 《為什么手機(jī)信號(hào)差？一文即懂！》
- 《高鐵上無線上網(wǎng)有多難？一文即懂！》
那么，在如此復(fù)雜的網(wǎng)絡(luò)環(huán)境下，是如何穩(wěn)定可靠的進(jìn)行IM消息投遞的？
對(duì)于發(fā)送者來說，它不知道消息是否有送達(dá)，要想做到確定送達(dá)，就需要加一個(gè)響應(yīng)機(jī)制。
這個(gè)機(jī)制類似于下面的響應(yīng)邏輯：
- 1）發(fā)送者發(fā)送了一條消息“Hello”，進(jìn)入等待狀態(tài)；
- 2）接收者收到這條消息“Hello”，然后告訴發(fā)送者說我已經(jīng)收到這條消息了的確認(rèn)信息；
- 3）發(fā)送者接收到確認(rèn)信息后，這個(gè)流程就算完成了，否則會(huì)重試。
上面流程看似簡單，關(guān)鍵是中間有個(gè)服務(wù)端轉(zhuǎn)發(fā)過程，問題就在于誰來回這個(gè)確認(rèn)信息，以及什么時(shí)候回這個(gè)確認(rèn)信息。
網(wǎng)上查到比較多的是如下一個(gè)消息必達(dá)模型：
各報(bào)文類型解釋如下：
如上面兩圖所示，發(fā)送流程是：
- 1）A向IM-server發(fā)送一個(gè)消息請(qǐng)求包，即msg:R1；
- 2）IM-server在成功處理后，回復(fù)A一個(gè)消息響應(yīng)包，即msg:A1；
- 3）如果此時(shí)B在線，則IM-server主動(dòng)向B發(fā)送一個(gè)消息通知包，即msg:N1（當(dāng)然，如果B不在線，則消息會(huì)存儲(chǔ)離線）。
如上面兩圖所示，接收流程是：
- 1）B向IM-server發(fā)送一個(gè)ack請(qǐng)求包，即ack:R2；
- 2）IM-server在成功處理后，回復(fù)B一個(gè)ack響應(yīng)包，即ack:A2；
- 3）IM-server主動(dòng)向A發(fā)送一個(gè)ack通知包，即ack:N2。
正如上述模型所示：一個(gè)可靠的消息投遞機(jī)制就是靠的6條報(bào)文來保證的，中間任何一個(gè)環(huán)節(jié)出錯(cuò)，都可以基于這個(gè)request-ack機(jī)制來判定是否出錯(cuò)并重試。
我們最終采用的方案也正是參考了上面這個(gè)模型，客戶端發(fā)送的邏輯是直接基于http的所以暫時(shí)不用做重試，主要是在服務(wù)端往客戶端推送的時(shí)候，會(huì)加上重試的邏輯。
限于篇幅，本文就不詳細(xì)展開，有興趣可以系統(tǒng)學(xué)習(xí)以下幾篇：
- 《從客戶端的角度來談?wù)勔苿?dòng)端IM的消息可靠性和送達(dá)機(jī)制》
- 《IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(一)：保證在線實(shí)時(shí)消息的可靠投遞》
- 《IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(二)：保證離線消息的可靠投遞》
- 《完全自已開發(fā)的IM該如何設(shè)計(jì)“失敗重試”機(jī)制？》
- 《一套億級(jí)用戶的IM架構(gòu)技術(shù)干貨(下篇)：可靠性、有序性、弱網(wǎng)優(yōu)化等》
- 《理解IM消息“可靠性”和“一致性”問題，以及解決方案探討》
- 《融云技術(shù)分享：全面揭秘億級(jí)IM消息的可靠投遞機(jī)制》
4、當(dāng)前面臨的具體問題
4.1 概述
在解決消息可靠投遞這個(gè)問題之前，我們肯定首先應(yīng)該搞清楚當(dāng)前面臨的具體問題到底有哪些。
然而在接手這套即時(shí)消息系統(tǒng)時(shí)，并沒有相關(guān)的準(zhǔn)確數(shù)據(jù)可供參考，所以當(dāng)前第一步還是要對(duì)這套消息系統(tǒng)做一個(gè)完整的排查，于是我們對(duì)消息做了全鏈路埋點(diǎn)。
具體的埋點(diǎn)環(huán)節(jié)如下：
基于消息的整個(gè)鏈路，我們梳理出來了幾個(gè)關(guān)鍵的指標(biāo)：
- 1）發(fā)送成功率；
- 2）消息到達(dá)率；
- 3）客戶端落庫率。
這次整個(gè)數(shù)據(jù)的統(tǒng)計(jì)都是基于埋點(diǎn)來做的，但在埋點(diǎn)的過程中發(fā)現(xiàn)了一個(gè)很大的問題：當(dāng)前這套即時(shí)消息系統(tǒng)沒有一個(gè)全局唯一的消息ID。這導(dǎo)致在全鏈路埋點(diǎn)的過程中，無法唯一確定這條消息的生命周期。
4.2 消息唯一性問題
如上圖所示，當(dāng)前的消息是通過3個(gè)變量來確定唯一性的：
- 1）SessionID: 當(dāng)前會(huì)話的ID；
- 2）SeqID：用戶當(dāng)前本地發(fā)送的消息序號(hào)，服務(wù)端是不關(guān)心此數(shù)據(jù)，完全是透傳；
- 3）Version：這個(gè)比較重要，是消息在當(dāng)前會(huì)話中的序號(hào)，已服務(wù)端為準(zhǔn)，但是客戶端也會(huì)生成一個(gè)假的version。
以上圖為例：當(dāng)A和B同時(shí)發(fā)送消息的時(shí)候，都會(huì)在本地生成如上幾個(gè)關(guān)鍵信息，當(dāng)A發(fā)送的消息（黃色）首先到達(dá)服務(wù)端，因?yàn)榍懊鏇]有其他version的消息，所以會(huì)將原數(shù)據(jù)返回給A，客戶端A接收到消息的時(shí)候，再跟本地的消息做合并，只會(huì)保留一條消息。同時(shí)服務(wù)端也會(huì)將此消息發(fā)送給B，因?yàn)锽本地也有一個(gè)version=1的消息，所以服務(wù)端過來的消息就會(huì)被過濾掉，這就出現(xiàn)消息丟失的問題。
當(dāng)B發(fā)送消息到達(dá)服務(wù)端后，因?yàn)橐呀?jīng)有version=1的消息，所以服務(wù)端會(huì)將B的消息version遞增，此時(shí)消息的version=2。這條消息發(fā)送給A，和本地消息可以正常合并。但是當(dāng)此消息返回給B的時(shí)候，和本地的消息合并，會(huì)出現(xiàn)2條一樣的消息，出現(xiàn)消息重復(fù)，這也是為什么閑魚之前總是出現(xiàn)消息丟失和消息重復(fù)最主要的原因。
4.3 消息推送邏輯問題
當(dāng)前消息的推送邏輯也存在很大的問題，發(fā)送端因?yàn)槭褂胔ttp請(qǐng)求，發(fā)送的消息內(nèi)容基本不會(huì)出問題，問題是出現(xiàn)在服務(wù)端給另外一端推送的時(shí)候。
如下圖所示：
如上圖所示：服務(wù)端在給客戶端推送的時(shí)候，會(huì)先判斷此時(shí)客戶端是否在線，如果在線才會(huì)推送，如果不在線就會(huì)推離線消息。
這個(gè)做法就非常的簡單粗暴：長連接的狀態(tài)如果不穩(wěn)定，導(dǎo)致客戶端真實(shí)狀態(tài)和服務(wù)端的存儲(chǔ)狀態(tài)不一致，就導(dǎo)致消息不會(huì)推送到端上。
4.4 客戶端邏輯問題
除了以上跟服務(wù)端有關(guān)系外，還有一類問題是客戶端本身設(shè)計(jì)的問題。
可以歸結(jié)為以下幾種情況：
- 1）多線程問題：反饋消息列表頁面會(huì)出現(xiàn)布局錯(cuò)亂，本地?cái)?shù)據(jù)還沒有完全初始化好，就開始渲染界面；
- 2）未讀數(shù)和小紅點(diǎn)的計(jì)數(shù)不準(zhǔn)：本地的顯示數(shù)據(jù)和數(shù)據(jù)庫存儲(chǔ)的不一致；
- 3）消息合并問題：本地在合并消息的時(shí)候，是分段合并的，不能保證消息的連續(xù)性和唯一性。
諸如以上的幾種情況，我們首先是對(duì)客戶端的代碼做了梳理與重構(gòu)。
架構(gòu)如下圖所示：
5、我們的優(yōu)化工作1：升級(jí)通心核心
解決問題第一步就是解決當(dāng)前消息系統(tǒng)唯一性的問題。
我們也調(diào)研了釘釘?shù)姆桨福斸斒欠?wù)端全局維護(hù)消息的唯一ID，考慮到閑魚即時(shí)消息系統(tǒng)的歷史包袱，我們這邊采用UUID作為消息的唯一ID，這樣就可以在消息鏈路埋點(diǎn)以及去重上得到很大的改善。
5.1 解決消息唯一性
在新版本的APP上面，客戶端會(huì)生成一個(gè)uuid，對(duì)于老版本無法生成的情況，服務(wù)端也會(huì)補(bǔ)充上相關(guān)信息。
消息的ID類似于 a1a3ffa118834033ac7a8b8353b7c6d9，客戶端在接收到消息后，會(huì)先根據(jù)MessageID來去重，然后基于Timestamp排序就可以了，雖然客戶端的時(shí)間可能不一樣，但是重復(fù)的概率還是比較小。
以iOS端為例，代碼大致如下：
- (void)combileMessages:(NSArray<PMessage*>*)messages {
...
// 1. 根據(jù)消息MessageId進(jìn)行去重
NSMutableDictionary *messageMaps = [self containerMessageMap];
for (PMessage *message in msgs) {
[messageMaps setObject:message forKey:message.messageId];
}
// 2. 消息合并后排序
NSMutableArray *tempMsgs = [NSMutableArray array];
[tempMsgs addObjectsFromArray:messageMaps.allValues];
[tempMsgs sortUsingComparator:^NSComparisonResult(PMessage * _Nonnull obj1, PMessage * _Nonnull obj2) {
// 根據(jù)消息的timestamp進(jìn)行排序
return obj1.timestamp > obj2.timestamp;
}];
...
}
5.2 實(shí)現(xiàn)消息重發(fā)、斷線重連機(jī)制
基于本文“3、行業(yè)方案”一節(jié)中的重發(fā)重連模型，我們完善了服務(wù)端的消息重發(fā)的邏輯、客戶端完善了斷線重連的邏輯。
具體措施是：
- 1）客戶端會(huì)定時(shí)檢測ACCS長連接是否聯(lián)通；
- 2）服務(wù)端會(huì)檢測設(shè)備是否在線，如果在線會(huì)推送消息，并會(huì)有超時(shí)等待；
- 3）客戶端接收到消息之后，會(huì)返回一個(gè)Ack。
5.3 優(yōu)化數(shù)據(jù)同步邏輯
重發(fā)重連解決的基礎(chǔ)網(wǎng)絡(luò)層的問題，接下來就要看下業(yè)務(wù)層的問題。
現(xiàn)有消息系統(tǒng)中，很多復(fù)雜情況是通過在業(yè)務(wù)層增加兼容代碼來解決的，消息的數(shù)據(jù)同步就是一個(gè)很典型的場景。
在完善數(shù)據(jù)同步的邏輯之前，我們也調(diào)研過釘釘?shù)囊徽讛?shù)據(jù)同步方案，他們主要是由服務(wù)端來保證的，背后有一個(gè)穩(wěn)定的長連接保證。
釘釘?shù)臄?shù)據(jù)同步方案大致流程如下：
我們的服務(wù)端暫時(shí)還沒有這種能力，所以閑魚這邊只能從客戶端來控制數(shù)據(jù)同步的邏輯。
數(shù)據(jù)同步的方式包括：
- 1）拉取會(huì)話；
- 2）拉取消息；
- 3）推送消息等。
因?yàn)樯婕暗降膱鼍氨容^復(fù)雜，之前有個(gè)場景就是推送會(huì)觸發(fā)增量同步，如果推送過多的話，會(huì)同時(shí)觸發(fā)多次網(wǎng)絡(luò)請(qǐng)求，為了解決這個(gè)問題，我們也做了相關(guān)的推拉隊(duì)列隔離。
客戶端控制的策略就是如果在拉取的話，會(huì)先將push過來的消息加到緩存隊(duì)列里面，等拉取的結(jié)果回來，會(huì)再跟本地緩存的邏輯做合并，這樣就可以避免多次網(wǎng)絡(luò)請(qǐng)求的問題。
5.4 客戶端數(shù)據(jù)模型優(yōu)化
客戶端在數(shù)據(jù)組織形式上，主要分2中：會(huì)話和消息，會(huì)話又分為：虛擬節(jié)點(diǎn)、會(huì)話節(jié)點(diǎn)和文件夾節(jié)點(diǎn)。
在客戶端會(huì)構(gòu)建上圖一樣的樹，這棵樹主要保存的是會(huì)話顯示的相關(guān)信息，比如未讀數(shù)、紅點(diǎn)以及最新消息摘要，子節(jié)點(diǎn)更新，會(huì)順帶更新到父節(jié)點(diǎn)，構(gòu)建樹的過程也是已讀和未讀數(shù)更新的過程。
其中比較復(fù)雜的場景是閑魚情報(bào)社，這個(gè)其實(shí)是一個(gè)文件夾節(jié)點(diǎn)，它包含了很多個(gè)子的會(huì)話，這就決定了他的消息排序、紅點(diǎn)計(jì)數(shù)以及消息摘要的更新邏輯會(huì)更復(fù)雜，服務(wù)端告知客戶端子會(huì)話的列表，然后客戶端再去拼接這些數(shù)據(jù)模型。
5.5 服務(wù)端存儲(chǔ)模型優(yōu)化
在前述內(nèi)容中，我大概講了客戶端的請(qǐng)求邏輯，即歷史消息會(huì)分為增量和全量域同步。
這個(gè)域其實(shí)是服務(wù)端的一層概念，本質(zhì)上就是用戶消息的一層緩存，消息過來之后會(huì)暫存在緩存中，加速消息讀取。
但是這個(gè)設(shè)計(jì)也存在一個(gè)缺陷：就是域環(huán)是有長度的，最多保存256條，當(dāng)用戶的消息數(shù)多于256條，只能從數(shù)據(jù)庫中讀取。
關(guān)于服務(wù)端的存儲(chǔ)方式，我們也調(diào)研過釘釘?shù)姆桨?#8212;—是寫擴(kuò)散，優(yōu)點(diǎn)就是可以很好地對(duì)每位用戶的消息做定制化，缺點(diǎn)就是存儲(chǔ)量很很大。
我們的這套解決方案，應(yīng)該是介于讀擴(kuò)散和寫擴(kuò)散之間的一種解決方案。這個(gè)設(shè)計(jì)方式不僅使客戶端邏輯復(fù)雜，服務(wù)端的數(shù)據(jù)讀取速度也會(huì)比較慢，后續(xù)這塊也可以做優(yōu)化。
6、我們的優(yōu)化工作2：增加質(zhì)量監(jiān)控體系
在做客戶端和服務(wù)端的全鏈路改造的同時(shí)，我們也對(duì)消息線上的行為做了監(jiān)控和排查的邏輯。
6.1 全鏈路排查
全鏈路排查是基于用戶的實(shí)時(shí)行為日志，客戶端的埋點(diǎn)通過集團(tuán)實(shí)時(shí)處理引擎Flink，將數(shù)據(jù)清洗到SLS里面。
用戶的行為包括：
- 1）消息引擎對(duì)消息的處理；
- 2）用戶的點(diǎn)擊/訪問頁面的行為；
- 3）用戶的網(wǎng)絡(luò)請(qǐng)求。
服務(wù)端側(cè)會(huì)有一些長連接推送以及重試的日志，也會(huì)清洗到SLS，這樣就組成了從服務(wù)端到客戶端全鏈路的排查的方案。
6.2 對(duì)賬系統(tǒng)
當(dāng)然為了驗(yàn)證消息的準(zhǔn)確性，我們還做了對(duì)賬系統(tǒng)：
在用戶離開會(huì)話的時(shí)候，我們會(huì)統(tǒng)計(jì)當(dāng)前會(huì)話一定數(shù)量的消息，生成一個(gè)md5的校驗(yàn)碼，上報(bào)到服務(wù)端。服務(wù)端拿到這個(gè)校驗(yàn)碼之后再判定是否消息是正確的。
經(jīng)過抽樣數(shù)據(jù)驗(yàn)證，消息的準(zhǔn)確性基本都在99.99%。
7、數(shù)據(jù)指標(biāo)統(tǒng)計(jì)方法優(yōu)化
我們?cè)诮y(tǒng)計(jì)消息的關(guān)鍵指標(biāo)時(shí)，遇到點(diǎn)問題：之前我們是用用戶埋點(diǎn)來統(tǒng)計(jì)的，發(fā)現(xiàn)會(huì)有3%~5%的數(shù)據(jù)差。
后來我們采用抽樣實(shí)時(shí)上報(bào)的數(shù)據(jù)來計(jì)算數(shù)據(jù)指標(biāo)：
消息到達(dá)率 = 客戶端實(shí)際收到的消息量 / 客戶端應(yīng)該收到的消息量
客戶端實(shí)際收到的消息的定義為“消息落庫才算是”。
該指標(biāo)不區(qū)分離線在線，取用戶當(dāng)日最后一次更新設(shè)備時(shí)間，理論上當(dāng)天且在此時(shí)間之前下發(fā)的消息都應(yīng)該收到。
經(jīng)過前述優(yōu)化工作，我們最新版本的消息到達(dá)率已經(jīng)基本達(dá)到99.9%，從輿情上來看，反饋丟消息的也確實(shí)少了很多。
8、未來規(guī)劃
整體看來，經(jīng)過一年的優(yōu)化治理，我們的即時(shí)消息系統(tǒng)各項(xiàng)指標(biāo)在慢慢變好。
但還是存在一些待優(yōu)化的方面：
- 1）消息的安全性不足：容易被黑產(chǎn)利用，借助消息發(fā)送一些違規(guī)的內(nèi)容；
- 2）消息的擴(kuò)展性較弱：增加一些卡片或者能力就要發(fā)版，缺少了動(dòng)態(tài)化和擴(kuò)展的能力。
- 3）底層的伸縮性不足：現(xiàn)在底層協(xié)議比較難擴(kuò)展，后續(xù)還是要規(guī)范一下協(xié)議。
從業(yè)務(wù)角度看，消息應(yīng)該是一個(gè)橫向支撐的工具性或者平臺(tái)型的產(chǎn)品，且可以快速對(duì)接二方和三方的快速對(duì)接。
接下來，我們會(huì)持續(xù)關(guān)注消息相關(guān)的用戶輿情，希望閑魚即時(shí)消息系統(tǒng)能幫助用戶更好的完成業(yè)務(wù)交易。
附錄：更多相關(guān)文章
[1] 更多阿里巴巴的技術(shù)資源：
《阿里釘釘技術(shù)分享：企業(yè)級(jí)IM王者——釘釘在后端架構(gòu)上的過人之處》
《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲(chǔ)方案探討》
《阿里技術(shù)分享：深度揭秘阿里數(shù)據(jù)庫技術(shù)方案的10年變遷史》
《阿里技術(shù)分享：阿里自研金融級(jí)數(shù)據(jù)庫OceanBase的艱辛成長之路》
《來自阿里OpenIM：打造安全可靠即時(shí)通訊服務(wù)的技術(shù)實(shí)踐分享》
《釘釘——基于IM技術(shù)的新一代企業(yè)OA平臺(tái)的技術(shù)挑戰(zhàn)(視頻+PPT) [附件下載]》
《阿里技術(shù)結(jié)晶：《阿里巴巴Java開發(fā)手冊(cè)(規(guī)約)-華山版》[附件下載]》
《重磅發(fā)布：《阿里巴巴Android開發(fā)手冊(cè)(規(guī)約)》[附件下載]》
《作者談《阿里巴巴Java開發(fā)手冊(cè)(規(guī)約)》背后的故事》
《《阿里巴巴Android開發(fā)手冊(cè)(規(guī)約)》背后的故事》
《干了這碗雞湯：從理發(fā)店小弟到阿里P10技術(shù)大牛》
《揭秘阿里、騰訊、華為、百度的職級(jí)和薪酬體系》
《淘寶技術(shù)分享：手淘億級(jí)移動(dòng)端接入層網(wǎng)關(guān)的技術(shù)演進(jìn)之路》
《難得干貨，揭秘支付寶的2維碼掃碼技術(shù)優(yōu)化實(shí)踐之路》
《淘寶直播技術(shù)干貨：高清、低延時(shí)的實(shí)時(shí)視頻直播技術(shù)解密》
《阿里技術(shù)分享：電商IM消息平臺(tái)，在群聊、直播場景下的技術(shù)實(shí)踐》
《阿里技術(shù)分享：閑魚IM基于Flutter的移動(dòng)端跨端改造實(shí)踐》
《阿里IM技術(shù)分享(三)：閑魚億級(jí)IM消息系統(tǒng)的架構(gòu)演進(jìn)之路》
《阿里IM技術(shù)分享(四)：閑魚億級(jí)IM消息系統(tǒng)的可靠投遞優(yōu)化實(shí)踐》
[2] 有關(guān)IM架構(gòu)設(shè)計(jì)的文章：
《淺談IM系統(tǒng)的架構(gòu)設(shè)計(jì)》
《簡述移動(dòng)端IM開發(fā)的那些坑：架構(gòu)設(shè)計(jì)、通信協(xié)議和客戶端》
《一套海量在線用戶的移動(dòng)端IM架構(gòu)設(shè)計(jì)實(shí)踐分享(含詳細(xì)圖文)》
《一套原創(chuàng)分布式即時(shí)通訊(IM)系統(tǒng)理論架構(gòu)方案》
《從零到卓越：京東客服即時(shí)通訊系統(tǒng)的技術(shù)架構(gòu)演進(jìn)歷程》
《蘑菇街即時(shí)通訊/IM服務(wù)器開發(fā)之架構(gòu)選擇》
《騰訊QQ1.4億在線用戶的技術(shù)挑戰(zhàn)和架構(gòu)演進(jìn)之路PPT》
《微信后臺(tái)基于時(shí)間序的海量數(shù)據(jù)冷熱分級(jí)架構(gòu)設(shè)計(jì)實(shí)踐》
《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(演講全文)》
《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡》》
《快速裂變：見證微信強(qiáng)大后臺(tái)架構(gòu)從0到1的演進(jìn)歷程（一）》
《移動(dòng)端IM中大規(guī)模群消息的推送如何保證效率、實(shí)時(shí)性？》
《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲(chǔ)方案探討》
《微信朋友圈千億訪問量背后的技術(shù)挑戰(zhàn)和實(shí)踐總結(jié)》
《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級(jí)IM平臺(tái)的技術(shù)實(shí)踐》
《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（算法原理篇）》
《一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構(gòu)方案設(shè)計(jì)實(shí)踐》
《社交軟件紅包技術(shù)解密(一)：全面解密QQ紅包技術(shù)方案——架構(gòu)、技術(shù)實(shí)現(xiàn)等》
《從游擊隊(duì)到正規(guī)軍(一)：馬蜂窩旅游網(wǎng)的IM系統(tǒng)架構(gòu)演進(jìn)之路》
《從游擊隊(duì)到正規(guī)軍(二)：馬蜂窩旅游網(wǎng)的IM客戶端架構(gòu)演進(jìn)和實(shí)踐總結(jié)》
《從游擊隊(duì)到正規(guī)軍(三)：基于Go的馬蜂窩旅游網(wǎng)分布式IM系統(tǒng)技術(shù)實(shí)踐》
《瓜子IM智能客服系統(tǒng)的數(shù)據(jù)架構(gòu)設(shè)計(jì)（整理自現(xiàn)場演講，有配套PPT）》
《IM開發(fā)基礎(chǔ)知識(shí)補(bǔ)課(九)：想開發(fā)IM集群？先搞懂什么是RPC！》
《阿里技術(shù)分享：電商IM消息平臺(tái)，在群聊、直播場景下的技術(shù)實(shí)踐》
《一套億級(jí)用戶的IM架構(gòu)技術(shù)干貨(上篇)：整體架構(gòu)、服務(wù)拆分等》
《一套億級(jí)用戶的IM架構(gòu)技術(shù)干貨(下篇)：可靠性、有序性、弱網(wǎng)優(yōu)化等》
《從新手到專家：如何設(shè)計(jì)一套億級(jí)消息量的分布式IM系統(tǒng)》
《企業(yè)微信的IM架構(gòu)設(shè)計(jì)揭秘：消息模型、萬人群、已讀回執(zhí)、消息撤回等》
《融云技術(shù)分享：全面揭秘億級(jí)IM消息的可靠投遞機(jī)制》
《IM開發(fā)技術(shù)學(xué)習(xí)：揭秘微信朋友圈這種信息推流背后的系統(tǒng)設(shè)計(jì)》
《阿里IM技術(shù)分享(三)：閑魚億級(jí)IM消息系統(tǒng)的架構(gòu)演進(jìn)之路》
>> 更多同類文章 ……
本文已同步發(fā)布于“即時(shí)通訊技術(shù)圈”公眾號(hào)。
同步發(fā)布鏈接是：http://www.52im.net/thread-3706-1-1.html