1、引言
好久沒寫技術(shù)文章了，今天這篇不是原理性文章，而是為大家分享一下由筆者主導(dǎo)開發(fā)實施的IM即時通訊聊天系統(tǒng)，針對大量離線消息（包括消息漫游）導(dǎo)致的用戶體驗問題的升級改造全過程。
文章中，我將從如下幾個方面進(jìn)行介紹：
- 1）這款I(lǐng)M產(chǎn)品的主要業(yè)務(wù)及特點；
- 2）IM系統(tǒng)業(yè)務(wù)現(xiàn)狀和痛點；
- 3）升級改造之路；
- 4）消息ACK邏輯的優(yōu)化。
下述內(nèi)容都是根據(jù)筆者開發(fā)IM的親身經(jīng)歷總結(jié)下來的寶貴經(jīng)驗，干貨滿滿，期待你的點贊。
學(xué)習(xí)交流：
- 即時通訊/推送技術(shù)開發(fā)交流5群：215477170 [推薦]
- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》
本文已同步發(fā)布于“即時通訊技術(shù)圈”公眾號，歡迎關(guān)注：
▲ 本文公眾號鏈接是：https://mp.weixin.qq.com/s/XHdt1IpCrdmaMDxL8WKn3w，原文鏈接是：http://www.52im.net/thread-3036-1-1.html
2、IM開發(fā)干貨系列文章
本文是系列文章中的第25篇，總目錄如下：
《IM消息送達(dá)保證機(jī)制實現(xiàn)(一)：保證在線實時消息的可靠投遞》
《IM消息送達(dá)保證機(jī)制實現(xiàn)(二)：保證離線消息的可靠投遞》
《如何保證IM實時消息的“時序性”與“一致性”？》
《IM單聊和群聊中的在線狀態(tài)同步應(yīng)該用“推”還是“拉”？》
《IM群聊消息如此復(fù)雜，如何保證不丟不重？》
《一種Android端IM智能心跳算法的設(shè)計與實現(xiàn)探討（含樣例代碼）》
《移動端IM登錄時拉取數(shù)據(jù)如何作到省流量？》
《通俗易懂：基于集群的移動端IM接入層負(fù)載均衡方案分享》
《淺談移動端IM的多點登陸和消息漫游原理》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(一)：正確理解前置HTTP SSO單點登陸接口的原理》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(二)：如何設(shè)計大量圖片文件的服務(wù)端存儲架構(gòu)？》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(三)：快速理解服務(wù)端數(shù)據(jù)庫讀寫分離原理及實踐建議》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(四)：正確理解HTTP短連接中的Cookie、Session和Token》
《IM群聊消息的已讀回執(zhí)功能該怎么實現(xiàn)？》
《IM群聊消息究竟是存1份(即擴(kuò)散讀)還是存多份(即擴(kuò)散寫)？》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(五)：通俗易懂，正確理解并用好MQ消息隊列》
《一個低成本確保IM消息時序的方法探討》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(六)：數(shù)據(jù)庫用NoSQL還是SQL？讀這篇就夠了！》
《IM里“附近的人”功能實現(xiàn)原理是什么？如何高效率地實現(xiàn)它？》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(七)：主流移動端賬號登錄方式的原理及設(shè)計思路》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(八)：史上最通俗，徹底搞懂字符亂碼問題的本質(zhì)》
《IM的掃碼登功能如何實現(xiàn)？一文搞懂主流應(yīng)用的掃碼登陸技術(shù)原理》
《IM要做手機(jī)掃碼登陸？先看看微信的掃碼登錄功能技術(shù)原理》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(九)：想開發(fā)IM集群？先搞懂什么是RPC！》
《IM開發(fā)實戰(zhàn)干貨：我是如何解決大量離線聊天消息導(dǎo)致客戶端卡頓的》（本文）
另外，如果您是IM開發(fā)初學(xué)者，強(qiáng)烈建議首先閱讀《新手入門一篇就夠：從零開發(fā)移動端IM》。
3、此IM產(chǎn)品的主要業(yè)務(wù)及特點
和傳統(tǒng)互聯(lián)網(wǎng)行業(yè)有所不同，筆者所在的公司（名字就不透露了）是一家做娛樂社交app的公司，包括小游戲、聊天、朋友圈feed等。
大家應(yīng)該都有體會：游戲業(yè)務(wù)在技術(shù)上和產(chǎn)品形態(tài)上與電商、旅游等行業(yè)有著本質(zhì)上的區(qū)別。
大部分做后端開發(fā)的朋友，都在開發(fā)接口。客戶端或瀏覽器h5通過HTTP請求到我們后端的Controller接口，后端查數(shù)據(jù)庫等返回JSON給客戶端。大家都知道，HTTP協(xié)議有短連接、無狀態(tài)、三次握手四次揮手等特點。而像游戲、實時通信等業(yè)務(wù)反而很不適合用HTTP協(xié)議。
原因如下：
- 1）HTTP達(dá)不到實時通信的效果，可以用客戶端輪詢但是太浪費資源；
- 2）三次握手四次揮手有嚴(yán)重的性能問題；
- 3）無狀態(tài)。
比如說，兩個用戶通過App聊天，一方發(fā)出去的消息，對方要實時感知到消息的到來。兩個人或多個人玩游戲，玩家要實時看到對方的狀態(tài)，這些場景用HTTP根本不可能實現(xiàn)！因為HTTP只能pull（即“拉”），而聊天、游戲業(yè)務(wù)需要push（即“推”）。
4、IM系統(tǒng)業(yè)務(wù)現(xiàn)狀和痛點
4.1 業(yè)務(wù)現(xiàn)狀
筆者負(fù)責(zé)整個公司的實時聊天系統(tǒng)，類似與微信、QQ那樣，有私聊、群聊、發(fā)消息、語音圖片、紅包等功能。
下面我詳細(xì)介紹一下，整個聊天系統(tǒng)是如何運轉(zhuǎn)的。
首先：為了達(dá)到實時通信的效果，我們基于Netty開發(fā)了一套長鏈接網(wǎng)關(guān)gateway（擴(kuò)展閱讀：《Netty干貨分享：京東京麥的生產(chǎn)級TCP網(wǎng)關(guān)技術(shù)實踐總結(jié)》），采用的協(xié)議是MQTT協(xié)議，客戶端登錄時App通過MQTT協(xié)議連接到gateway（NettyServer），然后通過MQTT協(xié)議把聊天消息push給NettyServer，NettyServer與NettyClient保持長鏈接，NettyClient用于處理業(yè)務(wù)邏輯(如敏感詞攔截、數(shù)據(jù)校驗等)處理，最后將消息push給NettyServer，再由NettyServer通過MQTT push給客戶端。
其次：客戶端與服務(wù)端想要正常通信，我們需要制定一套統(tǒng)一的協(xié)議。拿聊天舉例，我們要和對方聊天，需要通過uid等信息定位到對方的Channel（Netty中的通道，相當(dāng)于一條socket連接），才能將消息發(fā)送給正確的客戶端，同時客戶端必須通過協(xié)議中的數(shù)據(jù)（uid、groupId等），將消息顯示在私聊或者群聊的會話中。
協(xié)議中主要字段如下（我們將數(shù)據(jù)編碼成protobuf格式進(jìn)行傳輸）：
{
"cmd":"chat",
"time":1554964794220,
"uid":"69212694",
"clientInfo":{
"deviceId":"b3b1519c-89ec",
"deviceInfo":"MI 6X"
},
"body":{
"v":1,
"msgId":"5ab2fe83-59ec-44f0-8adc-abf26c1e1029",
"chatType":1,
"ackFlg":1,
"from":"69212694",
"to":"872472068",
"time":1554964793813,
"msg":{
"message":"聊天消息"
}
}
}
補(bǔ)充說明：如果你不了Protobuf格式是什么，請詳讀《Protobuf通信協(xié)議詳解：代碼演示、詳細(xì)原理介紹等》。
如上json，協(xié)議主要字段包括：
如果客戶端不在線，我們服務(wù)端需要把發(fā)送的消息存儲在離線消息表中，等下次對方客戶端上線，服務(wù)端NettyServer通過長鏈接把離線消息push給客戶端。
4.2 業(yè)務(wù)痛點
隨著業(yè)務(wù)蓬勃發(fā)展，用戶的不斷增多，用戶創(chuàng)建的群、加入的群和好友不斷增多和聊天活躍度的上升，某些用戶不在線期間，產(chǎn)生大量的離線消息（尤其是針對群聊，離線消息特別多）。
等下次客戶端上線時，服務(wù)端會給客戶端強(qiáng)推全部的離線消息，導(dǎo)致客戶端卡死在登錄后的首頁。并且產(chǎn)品提出的需求，要擴(kuò)大群成員的人數(shù)（由之前的百人群擴(kuò)展到千人群、萬人群等）。
這樣一來，某些客戶端登錄后必定會因為大量離線消息而卡死，用戶體驗極為不好。
和客戶端的同事一起分析了一下原因：
- 1）用戶登錄，服務(wù)端通過循環(huán)分批下發(fā)所有離線消息，數(shù)據(jù)量較大；
- 2）客戶端登錄后進(jìn)入首頁，需要加載的數(shù)據(jù)不光有離線消息，還有其他初始化數(shù)據(jù)；
- 3）不同價位的客戶端處理數(shù)據(jù)能力有限，處理聊天消息時，需要把消息存儲到本地數(shù)據(jù)庫，并且刷新UI界面，回復(fù)給服務(wù)端ack消息，整個過程很耗性能。
（慶幸的是，在線消息目前沒有性能問題）。
所以針對上述問題，結(jié)合產(chǎn)品對IM系統(tǒng)的遠(yuǎn)大規(guī)劃，我們服務(wù)端決定優(yōu)化離線消息（稍微吐槽一下，客戶端處理能力不夠，為什么要服務(wù)端做優(yōu)化？服務(wù)端的性能遠(yuǎn)沒達(dá)到瓶頸。。。）。
5、升級改造之路
值得慶幸的是，筆者100%參與這次系統(tǒng)優(yōu)化的全部過程，包括技術(shù)選型、方案制定和最后的代碼編寫。在此期間，筆者思考出多種方案，然后和服務(wù)端、客戶端同事一起討論，最后定下來一套穩(wěn)定的方案。
5.1 方案一（被pass掉的一個方案）
▶ 【問題癥狀】：
客戶端登錄卡頓的主要原因是，服務(wù)端會強(qiáng)推大量離線消息給客戶端，客戶端收到離線消息后會回復(fù)服務(wù)端ack，然后將消息存儲到本地數(shù)據(jù)庫、刷新UI等?？蛻舳朔答仯词箍蛻舳瞬捎卯惒椒绞揭矔斜容^嚴(yán)重的性能問題。
▶ 【于是我想】：
為什么客戶端收到消息后還沒有將數(shù)據(jù)存儲到數(shù)據(jù)庫就回復(fù)給服務(wù)端ack？很有可能存儲失敗，這本身不合理，這是其一。其二，服務(wù)端強(qiáng)推導(dǎo)致客戶端卡死，不關(guān)心客戶端的處理能力，不合理。
▶ 【偽代碼如下】：
int max = 100;
//從新庫讀
while(max > 0) {
List<OfflineMsgInfo> offlineMsgListNew = shardChatOfflineMsgDao.getByToUid(uid, 20);
if(CollectionUtils.isEmpty(offlineMsgListNew)) {
break;
}
handleOfflineMsg(uid, offlineMsgListNew, checkOnlineWhenSendingOfflineMsg);
max--;
}
▶ 【初步方案】：
既然強(qiáng)推不合理，我們可以換一種方式，根據(jù)客戶端不同機(jī)型的處理能力的不同，服務(wù)端采用不同的速度下發(fā)。
我們可以把整個過程當(dāng)成一種生產(chǎn)者消費者模型，服務(wù)端是消息生產(chǎn)者，客戶端是消息消費者。客戶端收到消息，將消息存儲在本地數(shù)據(jù)庫，刷新UI界面后，再向服務(wù)端發(fā)送ack消息，服務(wù)端收到客戶端的ack消息后，再推送下一批消息。
這么一來，消息下發(fā)速度完全根據(jù)客戶端的處理能力，分批下發(fā)。但這種方式仍然屬于推方式。
▶ 【悲劇結(jié)果】：
然而，理想很豐滿，現(xiàn)實卻很骨感。
針對這個方案，客戶端提出一些問題：
- 1）雖然這種方案，客戶端不會卡死，但是如果當(dāng)前用戶的離線消息特別多，那么收到所有離線消息的時間會非常長；
- 2）客戶端每次收到消息后會刷新界面，很有可能客戶端會發(fā)生，界面上下亂跳的畫面。
so，這個方案被否定了。。。
5.2 方案二
▶ 【我的思考】：
既然強(qiáng)推的數(shù)據(jù)量過大，我們是否可以做到，按需加載？客戶端需要讀取離線消息的時候服務(wù)端給客戶端下發(fā)，不需要的時候，服務(wù)端就不下發(fā)。
▶ 【技術(shù)方案】：針對離線消息，我們做了如下方案的優(yōu)化
1）我們增加了離線消息計數(shù)器的概念：保存了每個用戶的每個會話，未讀的消息的元數(shù)據(jù)(包括未讀消息數(shù)，最近的一條未讀消息、時間戳等數(shù)據(jù))，這個計數(shù)器用于客戶端顯示未讀消息的的紅色氣泡。這個數(shù)據(jù)屬于增量數(shù)據(jù)，只保留離線期間收到的消息元數(shù)據(jù)。
消息格式如下：
{
"sessionId1":{
"count":20,
"lastMsg":[
"最后N條消息"
],
"timestamp":1234567890
},
"sessionId2":{
}
}
2）客戶端每次登錄時，服務(wù)端不推送全量離線消息，只推送離線消息計數(shù)器（這部分?jǐn)?shù)據(jù)存儲在redis里，并且數(shù)據(jù)量很小），這個數(shù)量用戶顯示在客戶端消息列表的未讀消息小紅點上。
3）客戶端拿到這些離線消息計數(shù)器數(shù)據(jù)，遍歷會話列表，依次將未讀消息數(shù)量累加(注意：不是覆蓋，服務(wù)端保存客戶端離線后的增量數(shù)據(jù))，然后通知服務(wù)端清空離線消息計數(shù)器的增量數(shù)據(jù)。
4）當(dāng)客戶端進(jìn)入某會話后，上拉加載時，通過消息的msgId等信息發(fā)送HTTP請求給服務(wù)端，服務(wù)端再去分頁查詢離線消息返回給客戶端。
5）客戶端收到消息并保存在本地數(shù)據(jù)庫后，向服務(wù)端發(fā)送ack，然后服務(wù)端刪除離線消息表的離線消息。
▶ 【預(yù)期結(jié)果】：
客戶端、服務(wù)端的技術(shù)人員認(rèn)可這個方案。我們通過推拉結(jié)合的方式，解決了客戶端加載離線消息卡頓的問題。（改造前是強(qiáng)推，改造后采用推拉結(jié)合的方式）
流程圖如下：
▶ 【新的問題】：
方案雖然通過了，但是引發(fā)了一個新問題：即客戶端消息銜接問題。
問題描述如下：客戶端登錄后進(jìn)入會話頁面，因為客戶端本身就保存著歷史消息，那么客戶端下拉加載新消息時，到底怎么判斷要加載本地歷史消息？還是要請求服務(wù)端加載離線消息呢？
經(jīng)過一番思考，服務(wù)端和客戶端最終達(dá)成了一致的方案：
- 1）在未讀消息計數(shù)器的小紅點邏輯中，服務(wù)端會把每個會話的最近N條消息一起下發(fā)給客戶端；
- 2）客戶端進(jìn)入會話時，會根據(jù)未讀消息計數(shù)器的最近N條消息展示首頁數(shù)據(jù)；
- 3）客戶端每次下拉加載時，請求服務(wù)端，服務(wù)端按時間倒排離線消息返回當(dāng)前會話最近一頁離線消息，直到離線消息庫中的數(shù)據(jù)全部返回給客戶端；
- 4）當(dāng)離線消息庫中沒有離線消息后，返回給客戶端一個標(biāo)識，客戶端根據(jù)這個標(biāo)識，在會話頁面下一次下拉加載時不請求服務(wù)端的離線消息，直接請求本地數(shù)據(jù)庫。
6、消息ACK邏輯的優(yōu)化
最后，我們也對消息ack的邏輯進(jìn)行了優(yōu)化。
優(yōu)化前：服務(wù)端采用push模型給客戶端推消息，不論是在線消息還是離線消息，ack的邏輯都一樣，其中還用到了kafka、redis等中間件，流程很復(fù)雜（我在這里就不詳細(xì)展開介紹ack的具體流程了，反正不合理）。
離線消息和在線消息不同的是，我們不存儲在線消息，而離線消息會有一個單獨的庫存儲。完全沒必要用在線消息的ack邏輯去處理離線消息，反而很不合理，不僅流程上有問題，也浪費kafka、redis等中間件性能。
優(yōu)化后：我們和客戶端決定在每次下拉加載離線消息時，將收到的上一批離線消息的msgId或消息偏移量等信息發(fā)送給服務(wù)端，服務(wù)端直接根據(jù)msgId刪除離線庫中已經(jīng)發(fā)送給客戶端的離線消息，再返回給客戶端下一批離線消息。
另外：我們還增加了消息漫游功能，用戶切換手機(jī)登錄后仍然可以查到歷史消息，這部分內(nèi)容我就不展開詳細(xì)介紹給大家了。
7、設(shè)計優(yōu)化方案時的文檔截圖（僅供參考）
下面是優(yōu)化的方案文檔截圖，請大家參考。
附錄：更多IM開發(fā)相關(guān)文章匯總
[1] IM開發(fā)熱門文章：
《新手入門一篇就夠：從零開發(fā)移動端IM》
《移動端IM開發(fā)者必讀(一)：通俗易懂，理解移動網(wǎng)絡(luò)的“弱”和“慢”》
《移動端IM開發(fā)者必讀(二)：史上最全移動弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》
《從客戶端的角度來談?wù)勔苿佣薎M的消息可靠性和送達(dá)機(jī)制》
《現(xiàn)代移動端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請求速度、弱網(wǎng)適應(yīng)、安全保障》
《騰訊技術(shù)分享：社交網(wǎng)絡(luò)圖片的帶寬壓縮技術(shù)演進(jìn)之路》
《小白必讀：閑話HTTP短連接中的Session和Token》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課：正確理解前置HTTP SSO單點登錄接口的原理》
《移動端IM中大規(guī)模群消息的推送如何保證效率、實時性？》
《移動端IM開發(fā)需要面對的技術(shù)問題》
《開發(fā)IM是自己設(shè)計協(xié)議用字節(jié)流好還是字符流好？》
《請問有人知道語音留言聊天的主流實現(xiàn)方式嗎？》
《IM消息送達(dá)保證機(jī)制實現(xiàn)(一)：保證在線實時消息的可靠投遞》
《IM消息送達(dá)保證機(jī)制實現(xiàn)(二)：保證離線消息的可靠投遞》
《如何保證IM實時消息的“時序性”與“一致性”？》
《一個低成本確保IM消息時序的方法探討》
《IM單聊和群聊中的在線狀態(tài)同步應(yīng)該用“推”還是“拉”？》
《IM群聊消息如此復(fù)雜，如何保證不丟不重？》
《談?wù)勔苿佣?IM 開發(fā)中登錄請求的優(yōu)化》
《移動端IM登錄時拉取數(shù)據(jù)如何作到省流量？》
《淺談移動端IM的多點登錄和消息漫游原理》
《完全自已開發(fā)的IM該如何設(shè)計“失敗重試”機(jī)制？》
《通俗易懂：基于集群的移動端IM接入層負(fù)載均衡方案分享》
《微信對網(wǎng)絡(luò)影響的技術(shù)試驗及分析（論文全文）》
《即時通訊系統(tǒng)的原理、技術(shù)和應(yīng)用（技術(shù)論文）》
《開源IM工程“蘑菇街TeamTalk”的現(xiàn)狀：一場有始無終的開源秀》
《QQ音樂團(tuán)隊分享：Android中的圖片壓縮技術(shù)詳解（上篇）》
《QQ音樂團(tuán)隊分享：Android中的圖片壓縮技術(shù)詳解（下篇）》
《騰訊原創(chuàng)分享(一)：如何大幅提升移動網(wǎng)絡(luò)下手機(jī)QQ的圖片傳輸速度和成功率》
《騰訊原創(chuàng)分享(二)：如何大幅壓縮移動網(wǎng)絡(luò)下APP的流量消耗（上篇）》
《騰訊原創(chuàng)分享(三)：如何大幅壓縮移動網(wǎng)絡(luò)下APP的流量消耗（下篇）》
《如約而至：微信自用的移動端IM網(wǎng)絡(luò)層跨平臺組件庫Mars已正式開源》
《基于社交網(wǎng)絡(luò)的Yelp是如何實現(xiàn)海量用戶圖片的無損壓縮的？》
《騰訊技術(shù)分享：騰訊是如何大幅降低帶寬和網(wǎng)絡(luò)流量的(圖片壓縮篇)》
《騰訊技術(shù)分享：騰訊是如何大幅降低帶寬和網(wǎng)絡(luò)流量的(音視頻技術(shù)篇)》
《字符編碼那點事：快速理解ASCII、Unicode、GBK和UTF-8》
《全面掌握移動端主流圖片格式的特點、性能、調(diào)優(yōu)等》
《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級IM平臺的技術(shù)實踐》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(五)：通俗易懂，正確理解并用好MQ消息隊列》
《微信技術(shù)分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《自已開發(fā)IM有那么難嗎？手把手教你自擼一個Andriod版簡易IM (有源碼)》
《融云技術(shù)分享：解密融云IM產(chǎn)品的聊天消息ID生成策略》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(六)：數(shù)據(jù)庫用NoSQL還是SQL？讀這篇就夠了！》
《適合新手：從零開發(fā)一個IM服務(wù)端（基于Netty，有完整源碼）》
《拿起鍵盤就是干：跟我一起徒手開發(fā)一套分布式IM系統(tǒng)》
《適合新手：手把手教你用Go快速搭建高性能、可擴(kuò)展的IM系統(tǒng)(有源碼)》
《IM里“附近的人”功能實現(xiàn)原理是什么？如何高效率地實現(xiàn)它？》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(七)：主流移動端賬號登錄方式的原理及設(shè)計思路》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(八)：史上最通俗，徹底搞懂字符亂碼問題的本質(zhì)》
《IM“掃一掃”功能很好做？看看微信“掃一掃識物”的完整技術(shù)實現(xiàn)》
《IM的掃碼登錄功能如何實現(xiàn)？一文搞懂主流應(yīng)用的掃碼登錄技術(shù)原理》
《IM要做手機(jī)掃碼登錄？先看看微信的掃碼登錄功能技術(shù)原理》
《IM消息ID技術(shù)專題(一)：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《IM消息ID技術(shù)專題(二)：微信的海量IM聊天消息序列號生成實踐（容災(zāi)方案篇）》
《IM消息ID技術(shù)專題(三)：解密融云IM產(chǎn)品的聊天消息ID生成策略》
《IM消息ID技術(shù)專題(四)：深度解密美團(tuán)的分布式ID生成算法》
《IM消息ID技術(shù)專題(五)：開源分布式ID生成器UidGenerator的技術(shù)實現(xiàn)》
《IM開發(fā)寶典：史上最全，微信各種功能參數(shù)和邏輯規(guī)則資料匯總》
《IM開發(fā)干貨分享：我是如何解決大量離線聊天消息導(dǎo)致客戶端卡頓的》
>> 更多同類文章 ……
[2] IM群聊相關(guān)的技術(shù)文章：
《快速裂變：見證微信強(qiáng)大后臺架構(gòu)從0到1的演進(jìn)歷程（一）》
《如何保證IM實時消息的“時序性”與“一致性”？》
《IM單聊和群聊中的在線狀態(tài)同步應(yīng)該用“推”還是“拉”？》
《IM群聊消息如此復(fù)雜，如何保證不丟不重？》
《微信后臺團(tuán)隊：微信后臺異步消息隊列的優(yōu)化升級實踐分享》
《移動端IM中大規(guī)模群消息的推送如何保證效率、實時性？》
《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲方案探討》
《關(guān)于IM即時通訊群聊消息的亂序問題討論》
《IM群聊消息的已讀回執(zhí)功能該怎么實現(xiàn)？》
《IM群聊消息究竟是存1份(即擴(kuò)散讀)還是存多份(即擴(kuò)散寫)？》
《一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構(gòu)方案設(shè)計實踐》
《[技術(shù)腦洞] 如果把14億中國人拉到一個微信群里技術(shù)上能實現(xiàn)嗎？》
《IM群聊機(jī)制，除了循環(huán)去發(fā)消息還有什么方式？如何優(yōu)化？》
《網(wǎng)易云信技術(shù)分享：IM中的萬人群聊技術(shù)方案實踐總結(jié)》
《阿里釘釘技術(shù)分享：企業(yè)級IM王者——釘釘在后端架構(gòu)上的過人之處》
>> 更多同類文章 ……
[3] 有關(guān)IM架構(gòu)設(shè)計的文章：
《淺談IM系統(tǒng)的架構(gòu)設(shè)計》
《簡述移動端IM開發(fā)的那些坑：架構(gòu)設(shè)計、通信協(xié)議和客戶端》
《一套海量在線用戶的移動端IM架構(gòu)設(shè)計實踐分享(含詳細(xì)圖文)》
《一套原創(chuàng)分布式即時通訊(IM)系統(tǒng)理論架構(gòu)方案》
《從零到卓越：京東客服即時通訊系統(tǒng)的技術(shù)架構(gòu)演進(jìn)歷程》
《蘑菇街即時通訊/IM服務(wù)器開發(fā)之架構(gòu)選擇》
《騰訊QQ1.4億在線用戶的技術(shù)挑戰(zhàn)和架構(gòu)演進(jìn)之路PPT》
《微信后臺基于時間序的海量數(shù)據(jù)冷熱分級架構(gòu)設(shè)計實踐》
《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(演講全文)》
《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡》》
《快速裂變：見證微信強(qiáng)大后臺架構(gòu)從0到1的演進(jìn)歷程（一）》
《17年的實踐：騰訊海量產(chǎn)品的技術(shù)方法論》
《移動端IM中大規(guī)模群消息的推送如何保證效率、實時性？》
《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲方案探討》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(二)：如何設(shè)計大量圖片文件的服務(wù)端存儲架構(gòu)？》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(三)：快速理解服務(wù)端數(shù)據(jù)庫讀寫分離原理及實踐建議》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(四)：正確理解HTTP短連接中的Cookie、Session和Token》
《WhatsApp技術(shù)實踐分享：32人工程團(tuán)隊創(chuàng)造的技術(shù)神話》
《微信朋友圈千億訪問量背后的技術(shù)挑戰(zhàn)和實踐總結(jié)》
《王者榮耀2億用戶量的背后：產(chǎn)品定位、技術(shù)架構(gòu)、網(wǎng)絡(luò)方案等》
《IM系統(tǒng)的MQ消息中間件選型：Kafka還是RabbitMQ？》
《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計的方方面面》
《以微博類應(yīng)用場景為例，總結(jié)海量社交系統(tǒng)的架構(gòu)設(shè)計步驟》
《快速理解高性能HTTP服務(wù)端的負(fù)載均衡技術(shù)原理》
《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級IM平臺的技術(shù)實踐》
《知乎技術(shù)分享：從單機(jī)到2000萬QPS并發(fā)的Redis高性能緩存實踐之路》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(五)：通俗易懂，正確理解并用好MQ消息隊列》
《微信技術(shù)分享：微信的海量IM聊天消息序列號生成實踐（算法原理篇）》
《微信技術(shù)分享：微信的海量IM聊天消息序列號生成實踐（容災(zāi)方案篇）》
《新手入門：零基礎(chǔ)理解大型分布式架構(gòu)的演進(jìn)歷史、技術(shù)原理、最佳實踐》
《一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構(gòu)方案設(shè)計實踐》
《阿里技術(shù)分享：深度揭秘阿里數(shù)據(jù)庫技術(shù)方案的10年變遷史》
《阿里技術(shù)分享：阿里自研金融級數(shù)據(jù)庫OceanBase的艱辛成長之路》
《社交軟件紅包技術(shù)解密(一)：全面解密QQ紅包技術(shù)方案——架構(gòu)、技術(shù)實現(xiàn)等》
《社交軟件紅包技術(shù)解密(二)：解密微信搖一搖紅包從0到1的技術(shù)演進(jìn)》
《社交軟件紅包技術(shù)解密(三)：微信搖一搖紅包雨背后的技術(shù)細(xì)節(jié)》
《社交軟件紅包技術(shù)解密(四)：微信紅包系統(tǒng)是如何應(yīng)對高并發(fā)的》
《社交軟件紅包技術(shù)解密(五)：微信紅包系統(tǒng)是如何實現(xiàn)高可用性的》
《社交軟件紅包技術(shù)解密(六)：微信紅包系統(tǒng)的存儲層架構(gòu)演進(jìn)實踐》
《社交軟件紅包技術(shù)解密(七)：支付寶紅包的海量高并發(fā)技術(shù)實踐》
《社交軟件紅包技術(shù)解密(八)：全面解密微博紅包技術(shù)方案》
《社交軟件紅包技術(shù)解密(九)：談?wù)勈諵紅包的功能邏輯、容災(zāi)、運維、架構(gòu)等》
《社交軟件紅包技術(shù)解密(十)：手Q客戶端針對2020年春節(jié)紅包的技術(shù)實踐》
《即時通訊新手入門：一文讀懂什么是Nginx？它能否實現(xiàn)IM的負(fù)載均衡？》
《即時通訊新手入門：快速理解RPC技術(shù)——基本概念、原理和用途》
《多維度對比5款主流分布式MQ消息隊列，媽媽再也不擔(dān)心我的技術(shù)選型了》
《從游擊隊到正規(guī)軍(一)：馬蜂窩旅游網(wǎng)的IM系統(tǒng)架構(gòu)演進(jìn)之路》
《從游擊隊到正規(guī)軍(二)：馬蜂窩旅游網(wǎng)的IM客戶端架構(gòu)演進(jìn)和實踐總結(jié)》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(六)：數(shù)據(jù)庫用NoSQL還是SQL？讀這篇就夠了！》
《瓜子IM智能客服系統(tǒng)的數(shù)據(jù)架構(gòu)設(shè)計（整理自現(xiàn)場演講，有配套PPT）》
《阿里釘釘技術(shù)分享：企業(yè)級IM王者——釘釘在后端架構(gòu)上的過人之處》
《從游擊隊到正規(guī)軍(三)：基于Go的馬蜂窩旅游網(wǎng)分布式IM系統(tǒng)技術(shù)實踐》
《微信后臺基于時間序的新一代海量數(shù)據(jù)存儲架構(gòu)的設(shè)計實踐》
《IM開發(fā)基礎(chǔ)知識補(bǔ)課(九)：想開發(fā)IM集群？先搞懂什么是RPC！》
>> 更多同類文章 ……
（本文同步發(fā)布于：http://www.52im.net/thread-3036-1-1.html）