1、引言

好久沒(méi)寫(xiě)技術(shù)文章了，今天這篇不是原理性文章，而是為大家分享一下由筆者主導(dǎo)開(kāi)發(fā)實(shí)施的IM即時(shí)通訊聊天系統(tǒng)，針對(duì)大量離線消息（包括消息漫游）導(dǎo)致的用戶體驗(yàn)問(wèn)題的升級(jí)改造全過(guò)程。

文章中，我將從如下幾個(gè)方面進(jìn)行介紹：

• 1）這款I(lǐng)M產(chǎn)品的主要業(yè)務(wù)及特點(diǎn)；
• 2）IM系統(tǒng)業(yè)務(wù)現(xiàn)狀和痛點(diǎn)；
• 3）升級(jí)改造之路；
• 4）消息ACK邏輯的優(yōu)化。

下述內(nèi)容都是根據(jù)筆者開(kāi)發(fā)IM的親身經(jīng)歷總結(jié)下來(lái)的寶貴經(jīng)驗(yàn)，干貨滿滿，期待你的點(diǎn)贊。

學(xué)習(xí)交流：

- 即時(shí)通訊/推送技術(shù)開(kāi)發(fā)交流5群：215477170 [推薦]

- 移動(dòng)端IM開(kāi)發(fā)入門文章：《新手入門一篇就夠：從零開(kāi)發(fā)移動(dòng)端IM》

本文已同步發(fā)布于“即時(shí)通訊技術(shù)圈”公眾號(hào)，歡迎關(guān)注：

▲ 本文公眾號(hào)鏈接是：https://mp.weixin.qq.com/s/XHdt1IpCrdmaMDxL8WKn3w，原文鏈接是：http://www.52im.net/thread-3036-1-1.html

2、IM開(kāi)發(fā)干貨系列文章

本文是系列文章中的第25篇，總目錄如下：

《IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(一)：保證在線實(shí)時(shí)消息的可靠投遞》

《IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(二)：保證離線消息的可靠投遞》

《如何保證IM實(shí)時(shí)消息的“時(shí)序性”與“一致性”？》

《IM單聊和群聊中的在線狀態(tài)同步應(yīng)該用“推”還是“拉”？》

《IM群聊消息如此復(fù)雜，如何保證不丟不重？》

《一種Android端IM智能心跳算法的設(shè)計(jì)與實(shí)現(xiàn)探討（含樣例代碼）》

《移動(dòng)端IM登錄時(shí)拉取數(shù)據(jù)如何作到省流量？》

《通俗易懂：基于集群的移動(dòng)端IM接入層負(fù)載均衡方案分享》

《淺談移動(dòng)端IM的多點(diǎn)登陸和消息漫游原理》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(一)：正確理解前置HTTP SSO單點(diǎn)登陸接口的原理》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(二)：如何設(shè)計(jì)大量圖片文件的服務(wù)端存儲(chǔ)架構(gòu)？》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(三)：快速理解服務(wù)端數(shù)據(jù)庫(kù)讀寫(xiě)分離原理及實(shí)踐建議》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(四)：正確理解HTTP短連接中的Cookie、Session和Token》

《IM群聊消息的已讀回執(zhí)功能該怎么實(shí)現(xiàn)？》

《IM群聊消息究竟是存1份(即擴(kuò)散讀)還是存多份(即擴(kuò)散寫(xiě))？》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(五)：通俗易懂，正確理解并用好MQ消息隊(duì)列》

《一個(gè)低成本確保IM消息時(shí)序的方法探討》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(六)：數(shù)據(jù)庫(kù)用NoSQL還是SQL？讀這篇就夠了！》

《IM里“附近的人”功能實(shí)現(xiàn)原理是什么？如何高效率地實(shí)現(xiàn)它？》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(七)：主流移動(dòng)端賬號(hào)登錄方式的原理及設(shè)計(jì)思路》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(八)：史上最通俗，徹底搞懂字符亂碼問(wèn)題的本質(zhì)》

《IM的掃碼登功能如何實(shí)現(xiàn)？一文搞懂主流應(yīng)用的掃碼登陸技術(shù)原理》

《IM要做手機(jī)掃碼登陸？先看看微信的掃碼登錄功能技術(shù)原理》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(九)：想開(kāi)發(fā)IM集群？先搞懂什么是RPC！》

《IM開(kāi)發(fā)實(shí)戰(zhàn)干貨：我是如何解決大量離線聊天消息導(dǎo)致客戶端卡頓的》（本文）

另外，如果您是IM開(kāi)發(fā)初學(xué)者，強(qiáng)烈建議首先閱讀《新手入門一篇就夠：從零開(kāi)發(fā)移動(dòng)端IM》。

3、此IM產(chǎn)品的主要業(yè)務(wù)及特點(diǎn)

和傳統(tǒng)互聯(lián)網(wǎng)行業(yè)有所不同，筆者所在的公司（名字就不透露了）是一家做娛樂(lè)社交app的公司，包括小游戲、聊天、朋友圈feed等。

大家應(yīng)該都有體會(huì)：游戲業(yè)務(wù)在技術(shù)上和產(chǎn)品形態(tài)上與電商、旅游等行業(yè)有著本質(zhì)上的區(qū)別。

大部分做后端開(kāi)發(fā)的朋友，都在開(kāi)發(fā)接口。客戶端或?yàn)g覽器h5通過(guò)HTTP請(qǐng)求到我們后端的Controller接口，后端查數(shù)據(jù)庫(kù)等返回JSON給客戶端。大家都知道，HTTP協(xié)議有短連接、無(wú)狀態(tài)、三次握手四次揮手等特點(diǎn)。而像游戲、實(shí)時(shí)通信等業(yè)務(wù)反而很不適合用HTTP協(xié)議。

原因如下：

• 1）HTTP達(dá)不到實(shí)時(shí)通信的效果，可以用客戶端輪詢但是太浪費(fèi)資源；
• 2）三次握手四次揮手有嚴(yán)重的性能問(wèn)題；
• 3）無(wú)狀態(tài)。

比如說(shuō)，兩個(gè)用戶通過(guò)App聊天，一方發(fā)出去的消息，對(duì)方要實(shí)時(shí)感知到消息的到來(lái)。兩個(gè)人或多個(gè)人玩游戲，玩家要實(shí)時(shí)看到對(duì)方的狀態(tài)，這些場(chǎng)景用HTTP根本不可能實(shí)現(xiàn)！因?yàn)镠TTP只能pull（即“拉”），而聊天、游戲業(yè)務(wù)需要push（即“推”）。

4、IM系統(tǒng)業(yè)務(wù)現(xiàn)狀和痛點(diǎn)

4.1 業(yè)務(wù)現(xiàn)狀

筆者負(fù)責(zé)整個(gè)公司的實(shí)時(shí)聊天系統(tǒng)，類似與微信、QQ那樣，有私聊、群聊、發(fā)消息、語(yǔ)音圖片、紅包等功能。

下面我詳細(xì)介紹一下，整個(gè)聊天系統(tǒng)是如何運(yùn)轉(zhuǎn)的。

首先：為了達(dá)到實(shí)時(shí)通信的效果，我們基于Netty開(kāi)發(fā)了一套長(zhǎng)鏈接網(wǎng)關(guān)gateway（擴(kuò)展閱讀：《Netty干貨分享：京東京麥的生產(chǎn)級(jí)TCP網(wǎng)關(guān)技術(shù)實(shí)踐總結(jié)》），采用的協(xié)議是MQTT協(xié)議，客戶端登錄時(shí)App通過(guò)MQTT協(xié)議連接到gateway（NettyServer），然后通過(guò)MQTT協(xié)議把聊天消息push給NettyServer，NettyServer與NettyClient保持長(zhǎng)鏈接，NettyClient用于處理業(yè)務(wù)邏輯(如敏感詞攔截、數(shù)據(jù)校驗(yàn)等)處理，最后將消息push給NettyServer，再由NettyServer通過(guò)MQTT push給客戶端。

其次：客戶端與服務(wù)端想要正常通信，我們需要制定一套統(tǒng)一的協(xié)議。拿聊天舉例，我們要和對(duì)方聊天，需要通過(guò)uid等信息定位到對(duì)方的Channel（Netty中的通道，相當(dāng)于一條socket連接），才能將消息發(fā)送給正確的客戶端，同時(shí)客戶端必須通過(guò)協(xié)議中的數(shù)據(jù)（uid、groupId等），將消息顯示在私聊或者群聊的會(huì)話中。

協(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ǔ)充說(shuō)明：如果你不了Protobuf格式是什么，請(qǐng)?jiān)斪x《Protobuf通信協(xié)議詳解：代碼演示、詳細(xì)原理介紹等》。

如上json，協(xié)議主要字段包括： 

如果客戶端不在線，我們服務(wù)端需要把發(fā)送的消息存儲(chǔ)在離線消息表中，等下次對(duì)方客戶端上線，服務(wù)端NettyServer通過(guò)長(zhǎng)鏈接把離線消息push給客戶端。

4.2 業(yè)務(wù)痛點(diǎn)

隨著業(yè)務(wù)蓬勃發(fā)展，用戶的不斷增多，用戶創(chuàng)建的群、加入的群和好友不斷增多和聊天活躍度的上升，某些用戶不在線期間，產(chǎn)生大量的離線消息（尤其是針對(duì)群聊，離線消息特別多）。

等下次客戶端上線時(shí)，服務(wù)端會(huì)給客戶端強(qiáng)推全部的離線消息，導(dǎo)致客戶端卡死在登錄后的首頁(yè)。并且產(chǎn)品提出的需求，要擴(kuò)大群成員的人數(shù)（由之前的百人群擴(kuò)展到千人群、萬(wàn)人群等）。

這樣一來(lái)，某些客戶端登錄后必定會(huì)因?yàn)榇罅侩x線消息而卡死，用戶體驗(yàn)極為不好。

和客戶端的同事一起分析了一下原因：

• 1）用戶登錄，服務(wù)端通過(guò)循環(huán)分批下發(fā)所有離線消息，數(shù)據(jù)量較大；
• 2）客戶端登錄后進(jìn)入首頁(yè)，需要加載的數(shù)據(jù)不光有離線消息，還有其他初始化數(shù)據(jù)；
• 3）不同價(jià)位的客戶端處理數(shù)據(jù)能力有限，處理聊天消息時(shí)，需要把消息存儲(chǔ)到本地?cái)?shù)據(jù)庫(kù)，并且刷新UI界面，回復(fù)給服務(wù)端ack消息，整個(gè)過(guò)程很耗性能。

（慶幸的是，在線消息目前沒(méi)有性能問(wèn)題）。

所以針對(duì)上述問(wèn)題，結(jié)合產(chǎn)品對(duì)IM系統(tǒng)的遠(yuǎn)大規(guī)劃，我們服務(wù)端決定優(yōu)化離線消息（稍微吐槽一下，客戶端處理能力不夠，為什么要服務(wù)端做優(yōu)化？服務(wù)端的性能遠(yuǎn)沒(méi)達(dá)到瓶頸。。。）。

5、升級(jí)改造之路

值得慶幸的是，筆者100%參與這次系統(tǒng)優(yōu)化的全部過(guò)程，包括技術(shù)選型、方案制定和最后的代碼編寫(xiě)。在此期間，筆者思考出多種方案，然后和服務(wù)端、客戶端同事一起討論，最后定下來(lái)一套穩(wěn)定的方案。

5.1 方案一（被pass掉的一個(gè)方案）

▶ 【問(wèn)題癥狀】：

客戶端登錄卡頓的主要原因是，服務(wù)端會(huì)強(qiáng)推大量離線消息給客戶端，客戶端收到離線消息后會(huì)回復(fù)服務(wù)端ack，然后將消息存儲(chǔ)到本地?cái)?shù)據(jù)庫(kù)、刷新UI等。客戶端反饋，即使客戶端采用異步方式也會(huì)有比較嚴(yán)重的性能問(wèn)題。

▶ 【于是我想】：

為什么客戶端收到消息后還沒(méi)有將數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)庫(kù)就回復(fù)給服務(wù)端ack？很有可能存儲(chǔ)失敗，這本身不合理，這是其一。其二，服務(wù)端強(qiáng)推導(dǎo)致客戶端卡死，不關(guān)心客戶端的處理能力，不合理。

▶ 【偽代碼如下】：

int max = 100;

//從新庫(kù)讀

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ā)。

我們可以把整個(gè)過(guò)程當(dāng)成一種生產(chǎn)者消費(fèi)者模型，服務(wù)端是消息生產(chǎn)者，客戶端是消息消費(fèi)者。客戶端收到消息，將消息存儲(chǔ)在本地?cái)?shù)據(jù)庫(kù)，刷新UI界面后，再向服務(wù)端發(fā)送ack消息，服務(wù)端收到客戶端的ack消息后，再推送下一批消息。

這么一來(lái)，消息下發(fā)速度完全根據(jù)客戶端的處理能力，分批下發(fā)。但這種方式仍然屬于推方式。

▶ 【悲劇結(jié)果】：

然而，理想很豐滿，現(xiàn)實(shí)卻很骨感。

針對(duì)這個(gè)方案，客戶端提出一些問(wèn)題：

• 1）雖然這種方案，客戶端不會(huì)卡死，但是如果當(dāng)前用戶的離線消息特別多，那么收到所有離線消息的時(shí)間會(huì)非常長(zhǎng)；
• 2）客戶端每次收到消息后會(huì)刷新界面，很有可能客戶端會(huì)發(fā)生，界面上下亂跳的畫(huà)面。

so，這個(gè)方案被否定了。。。

5.2 方案二

▶ 【我的思考】：

既然強(qiáng)推的數(shù)據(jù)量過(guò)大，我們是否可以做到，按需加載？客戶端需要讀取離線消息的時(shí)候服務(wù)端給客戶端下發(fā)，不需要的時(shí)候，服務(wù)端就不下發(fā)。

▶ 【技術(shù)方案】：針對(duì)離線消息，我們做了如下方案的優(yōu)化

1）我們?cè)黾恿穗x線消息計(jì)數(shù)器的概念：保存了每個(gè)用戶的每個(gè)會(huì)話，未讀的消息的元數(shù)據(jù)(包括未讀消息數(shù)，最近的一條未讀消息、時(shí)間戳等數(shù)據(jù))，這個(gè)計(jì)數(shù)器用于客戶端顯示未讀消息的的紅色氣泡。這個(gè)數(shù)據(jù)屬于增量數(shù)據(jù)，只保留離線期間收到的消息元數(shù)據(jù)。

消息格式如下：

{

    "sessionId1":{

        "count":20,

        "lastMsg":[

            "最后N條消息"

        ],

        "timestamp":1234567890

    },

    "sessionId2":{

    }

}

 

 

2）客戶端每次登錄時(shí)，服務(wù)端不推送全量離線消息，只推送離線消息計(jì)數(shù)器（這部分?jǐn)?shù)據(jù)存儲(chǔ)在redis里，并且數(shù)據(jù)量很小），這個(gè)數(shù)量用戶顯示在客戶端消息列表的未讀消息小紅點(diǎn)上。

3）客戶端拿到這些離線消息計(jì)數(shù)器數(shù)據(jù)，遍歷會(huì)話列表，依次將未讀消息數(shù)量累加(注意：不是覆蓋，服務(wù)端保存客戶端離線后的增量數(shù)據(jù))，然后通知服務(wù)端清空離線消息計(jì)數(shù)器的增量數(shù)據(jù)。

4）當(dāng)客戶端進(jìn)入某會(huì)話后，上拉加載時(shí)，通過(guò)消息的msgId等信息發(fā)送HTTP請(qǐng)求給服務(wù)端，服務(wù)端再去分頁(yè)查詢離線消息返回給客戶端。

5）客戶端收到消息并保存在本地?cái)?shù)據(jù)庫(kù)后，向服務(wù)端發(fā)送ack，然后服務(wù)端刪除離線消息表的離線消息。

▶ 【預(yù)期結(jié)果】：

客戶端、服務(wù)端的技術(shù)人員認(rèn)可這個(gè)方案。我們通過(guò)推拉結(jié)合的方式，解決了客戶端加載離線消息卡頓的問(wèn)題。（改造前是強(qiáng)推，改造后采用推拉結(jié)合的方式）

流程圖如下：

▶ 【新的問(wèn)題】：

方案雖然通過(guò)了，但是引發(fā)了一個(gè)新問(wèn)題：即客戶端消息銜接問(wèn)題。

問(wèn)題描述如下：客戶端登錄后進(jìn)入會(huì)話頁(yè)面，因?yàn)榭蛻舳吮旧砭捅４嬷鴼v史消息，那么客戶端下拉加載新消息時(shí)，到底怎么判斷要加載本地歷史消息？還是要請(qǐng)求服務(wù)端加載離線消息呢？

經(jīng)過(guò)一番思考，服務(wù)端和客戶端最終達(dá)成了一致的方案：

• 1）在未讀消息計(jì)數(shù)器的小紅點(diǎn)邏輯中，服務(wù)端會(huì)把每個(gè)會(huì)話的最近N條消息一起下發(fā)給客戶端；
• 2）客戶端進(jìn)入會(huì)話時(shí)，會(huì)根據(jù)未讀消息計(jì)數(shù)器的最近N條消息展示首頁(yè)數(shù)據(jù)；
• 3）客戶端每次下拉加載時(shí)，請(qǐng)求服務(wù)端，服務(wù)端按時(shí)間倒排離線消息返回當(dāng)前會(huì)話最近一頁(yè)離線消息，直到離線消息庫(kù)中的數(shù)據(jù)全部返回給客戶端；
• 4）當(dāng)離線消息庫(kù)中沒(méi)有離線消息后，返回給客戶端一個(gè)標(biāo)識(shí)，客戶端根據(jù)這個(gè)標(biāo)識(shí)，在會(huì)話頁(yè)面下一次下拉加載時(shí)不請(qǐng)求服務(wù)端的離線消息，直接請(qǐng)求本地?cái)?shù)據(jù)庫(kù)。

6、消息ACK邏輯的優(yōu)化

最后，我們也對(duì)消息ack的邏輯進(jìn)行了優(yōu)化。

優(yōu)化前：服務(wù)端采用push模型給客戶端推消息，不論是在線消息還是離線消息，ack的邏輯都一樣，其中還用到了kafka、redis等中間件，流程很復(fù)雜（我在這里就不詳細(xì)展開(kāi)介紹ack的具體流程了，反正不合理）。

離線消息和在線消息不同的是，我們不存儲(chǔ)在線消息，而離線消息會(huì)有一個(gè)單獨(dú)的庫(kù)存儲(chǔ)。完全沒(méi)必要用在線消息的ack邏輯去處理離線消息，反而很不合理，不僅流程上有問(wèn)題，也浪費(fèi)kafka、redis等中間件性能。

優(yōu)化后：我們和客戶端決定在每次下拉加載離線消息時(shí)，將收到的上一批離線消息的msgId或消息偏移量等信息發(fā)送給服務(wù)端，服務(wù)端直接根據(jù)msgId刪除離線庫(kù)中已經(jīng)發(fā)送給客戶端的離線消息，再返回給客戶端下一批離線消息。

另外：我們還增加了消息漫游功能，用戶切換手機(jī)登錄后仍然可以查到歷史消息，這部分內(nèi)容我就不展開(kāi)詳細(xì)介紹給大家了。

7、設(shè)計(jì)優(yōu)化方案時(shí)的文檔截圖（僅供參考）

下面是優(yōu)化的方案文檔截圖，請(qǐng)大家參考。

 

 

 

 

 

附錄：更多IM開(kāi)發(fā)相關(guān)文章匯總

[1] IM開(kāi)發(fā)熱門文章：

《新手入門一篇就夠：從零開(kāi)發(fā)移動(dòng)端IM》

《移動(dòng)端IM開(kāi)發(fā)者必讀(一)：通俗易懂，理解移動(dòng)網(wǎng)絡(luò)的“弱”和“慢”》

《移動(dòng)端IM開(kāi)發(fā)者必讀(二)：史上最全移動(dòng)弱網(wǎng)絡(luò)優(yōu)化方法總結(jié)》

《從客戶端的角度來(lái)談?wù)勔苿?dòng)端IM的消息可靠性和送達(dá)機(jī)制》

《現(xiàn)代移動(dòng)端網(wǎng)絡(luò)短連接的優(yōu)化手段總結(jié)：請(qǐng)求速度、弱網(wǎng)適應(yīng)、安全保障》

《騰訊技術(shù)分享：社交網(wǎng)絡(luò)圖片的帶寬壓縮技術(shù)演進(jìn)之路》

《小白必讀：閑話HTTP短連接中的Session和Token》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課：正確理解前置HTTP SSO單點(diǎn)登錄接口的原理》

《移動(dòng)端IM中大規(guī)模群消息的推送如何保證效率、實(shí)時(shí)性？》

《移動(dòng)端IM開(kāi)發(fā)需要面對(duì)的技術(shù)問(wèn)題》

《開(kāi)發(fā)IM是自己設(shè)計(jì)協(xié)議用字節(jié)流好還是字符流好？》

《請(qǐng)問(wèn)有人知道語(yǔ)音留言聊天的主流實(shí)現(xiàn)方式嗎？》

《IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(一)：保證在線實(shí)時(shí)消息的可靠投遞》

《IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(二)：保證離線消息的可靠投遞》

《如何保證IM實(shí)時(shí)消息的“時(shí)序性”與“一致性”？》

《一個(gè)低成本確保IM消息時(shí)序的方法探討》

《IM單聊和群聊中的在線狀態(tài)同步應(yīng)該用“推”還是“拉”？》

《IM群聊消息如此復(fù)雜，如何保證不丟不重？》

《談?wù)勔苿?dòng)端 IM 開(kāi)發(fā)中登錄請(qǐng)求的優(yōu)化》

《移動(dòng)端IM登錄時(shí)拉取數(shù)據(jù)如何作到省流量？》

《淺談移動(dòng)端IM的多點(diǎn)登錄和消息漫游原理》

《完全自已開(kāi)發(fā)的IM該如何設(shè)計(jì)“失敗重試”機(jī)制？》

《通俗易懂：基于集群的移動(dòng)端IM接入層負(fù)載均衡方案分享》

《微信對(duì)網(wǎng)絡(luò)影響的技術(shù)試驗(yàn)及分析（論文全文）》

《即時(shí)通訊系統(tǒng)的原理、技術(shù)和應(yīng)用（技術(shù)論文）》

《開(kāi)源IM工程“蘑菇街TeamTalk”的現(xiàn)狀：一場(chǎng)有始無(wú)終的開(kāi)源秀》

《QQ音樂(lè)團(tuán)隊(duì)分享：Android中的圖片壓縮技術(shù)詳解（上篇）》

《QQ音樂(lè)團(tuán)隊(duì)分享：Android中的圖片壓縮技術(shù)詳解（下篇）》

《騰訊原創(chuàng)分享(一)：如何大幅提升移動(dòng)網(wǎng)絡(luò)下手機(jī)QQ的圖片傳輸速度和成功率》

《騰訊原創(chuàng)分享(二)：如何大幅壓縮移動(dòng)網(wǎng)絡(luò)下APP的流量消耗（上篇）》

《騰訊原創(chuàng)分享(三)：如何大幅壓縮移動(dòng)網(wǎng)絡(luò)下APP的流量消耗（下篇）》

《如約而至：微信自用的移動(dòng)端IM網(wǎng)絡(luò)層跨平臺(tái)組件庫(kù)Mars已正式開(kāi)源》

《基于社交網(wǎng)絡(luò)的Yelp是如何實(shí)現(xiàn)海量用戶圖片的無(wú)損壓縮的？》

《騰訊技術(shù)分享：騰訊是如何大幅降低帶寬和網(wǎng)絡(luò)流量的(圖片壓縮篇)》

《騰訊技術(shù)分享：騰訊是如何大幅降低帶寬和網(wǎng)絡(luò)流量的(音視頻技術(shù)篇)》

《字符編碼那點(diǎn)事：快速理解ASCII、Unicode、GBK和UTF-8》

《全面掌握移動(dòng)端主流圖片格式的特點(diǎn)、性能、調(diào)優(yōu)等》

《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級(jí)IM平臺(tái)的技術(shù)實(shí)踐》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(五)：通俗易懂，正確理解并用好MQ消息隊(duì)列》

《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（算法原理篇）》

《自已開(kāi)發(fā)IM有那么難嗎？手把手教你自擼一個(gè)Andriod版簡(jiǎn)易IM (有源碼)》

《融云技術(shù)分享：解密融云IM產(chǎn)品的聊天消息ID生成策略》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(六)：數(shù)據(jù)庫(kù)用NoSQL還是SQL？讀這篇就夠了！》

《適合新手：從零開(kāi)發(fā)一個(gè)IM服務(wù)端（基于Netty，有完整源碼）》

《拿起鍵盤(pán)就是干：跟我一起徒手開(kāi)發(fā)一套分布式IM系統(tǒng)》

《適合新手：手把手教你用Go快速搭建高性能、可擴(kuò)展的IM系統(tǒng)(有源碼)》

《IM里“附近的人”功能實(shí)現(xiàn)原理是什么？如何高效率地實(shí)現(xiàn)它？》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(七)：主流移動(dòng)端賬號(hào)登錄方式的原理及設(shè)計(jì)思路》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(八)：史上最通俗，徹底搞懂字符亂碼問(wèn)題的本質(zhì)》

《IM“掃一掃”功能很好做？看看微信“掃一掃識(shí)物”的完整技術(shù)實(shí)現(xiàn)》

《IM的掃碼登錄功能如何實(shí)現(xiàn)？一文搞懂主流應(yīng)用的掃碼登錄技術(shù)原理》

《IM要做手機(jī)掃碼登錄？先看看微信的掃碼登錄功能技術(shù)原理》

《IM消息ID技術(shù)專題(一)：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（算法原理篇）》

《IM消息ID技術(shù)專題(二)：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（容災(zāi)方案篇）》

《IM消息ID技術(shù)專題(三)：解密融云IM產(chǎn)品的聊天消息ID生成策略》

《IM消息ID技術(shù)專題(四)：深度解密美團(tuán)的分布式ID生成算法》

《IM消息ID技術(shù)專題(五)：開(kāi)源分布式ID生成器UidGenerator的技術(shù)實(shí)現(xiàn)》

《IM開(kāi)發(fā)寶典：史上最全，微信各種功能參數(shù)和邏輯規(guī)則資料匯總》

《IM開(kāi)發(fā)干貨分享：我是如何解決大量離線聊天消息導(dǎo)致客戶端卡頓的》

>> 更多同類文章 …… 

[2] IM群聊相關(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ò)散寫(xiě))？》

《一套高可用、易伸縮、高并發(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é)》

《阿里釘釘技術(shù)分享：企業(yè)級(jí)IM王者——釘釘在后端架構(gòu)上的過(guò)人之處》

>> 更多同類文章 ……

[3] 有關(guān)IM架構(gòu)設(shè)計(jì)的文章：

《淺談IM系統(tǒng)的架構(gòu)設(shè)計(jì)》

《簡(jiǎn)述移動(dòng)端IM開(kāi)發(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ù)器開(kāi)發(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)：微信之道——大道至簡(jiǎn)(演講全文)》

《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(jiǎn)》》

《快速裂變：見(jiàn)證微信強(qiáng)大后臺(tái)架構(gòu)從0到1的演進(jìn)歷程（一）》

《17年的實(shí)踐：騰訊海量產(chǎn)品的技術(shù)方法論》

《移動(dòng)端IM中大規(guī)模群消息的推送如何保證效率、實(shí)時(shí)性？》

《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲(chǔ)方案探討》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(二)：如何設(shè)計(jì)大量圖片文件的服務(wù)端存儲(chǔ)架構(gòu)？》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(三)：快速理解服務(wù)端數(shù)據(jù)庫(kù)讀寫(xiě)分離原理及實(shí)踐建議》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(四)：正確理解HTTP短連接中的Cookie、Session和Token》

《WhatsApp技術(shù)實(shí)踐分享：32人工程團(tuán)隊(duì)創(chuàng)造的技術(shù)神話》

《微信朋友圈千億訪問(wèn)量背后的技術(shù)挑戰(zhàn)和實(shí)踐總結(jié)》

《王者榮耀2億用戶量的背后：產(chǎn)品定位、技術(shù)架構(gòu)、網(wǎng)絡(luò)方案等》

《IM系統(tǒng)的MQ消息中間件選型：Kafka還是RabbitMQ？》

《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計(jì)的方方面面》

《以微博類應(yīng)用場(chǎng)景為例，總結(jié)海量社交系統(tǒng)的架構(gòu)設(shè)計(jì)步驟》

《快速理解高性能HTTP服務(wù)端的負(fù)載均衡技術(shù)原理》

《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級(jí)IM平臺(tái)的技術(shù)實(shí)踐》

《知乎技術(shù)分享：從單機(jī)到2000萬(wàn)QPS并發(fā)的Redis高性能緩存實(shí)踐之路》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(五)：通俗易懂，正確理解并用好MQ消息隊(duì)列》

《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（算法原理篇）》

《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（容災(zāi)方案篇）》

《新手入門：零基礎(chǔ)理解大型分布式架構(gòu)的演進(jìn)歷史、技術(shù)原理、最佳實(shí)踐》

《一套高可用、易伸縮、高并發(fā)的IM群聊、單聊架構(gòu)方案設(shè)計(jì)實(shí)踐》

《阿里技術(shù)分享：深度揭秘阿里數(shù)據(jù)庫(kù)技術(shù)方案的10年變遷史》

《阿里技術(shù)分享：阿里自研金融級(jí)數(shù)據(jù)庫(kù)OceanBase的艱辛成長(zhǎng)之路》

《社交軟件紅包技術(shù)解密(一)：全面解密QQ紅包技術(shù)方案——架構(gòu)、技術(shù)實(shí)現(xiàn)等》

《社交軟件紅包技術(shù)解密(二)：解密微信搖一搖紅包從0到1的技術(shù)演進(jìn)》

《社交軟件紅包技術(shù)解密(三)：微信搖一搖紅包雨背后的技術(shù)細(xì)節(jié)》

《社交軟件紅包技術(shù)解密(四)：微信紅包系統(tǒng)是如何應(yīng)對(duì)高并發(fā)的》

《社交軟件紅包技術(shù)解密(五)：微信紅包系統(tǒng)是如何實(shí)現(xiàn)高可用性的》

《社交軟件紅包技術(shù)解密(六)：微信紅包系統(tǒng)的存儲(chǔ)層架構(gòu)演進(jìn)實(shí)踐》

《社交軟件紅包技術(shù)解密(七)：支付寶紅包的海量高并發(fā)技術(shù)實(shí)踐》

《社交軟件紅包技術(shù)解密(八)：全面解密微博紅包技術(shù)方案》

《社交軟件紅包技術(shù)解密(九)：談?wù)勈諵紅包的功能邏輯、容災(zāi)、運(yùn)維、架構(gòu)等》

《社交軟件紅包技術(shù)解密(十)：手Q客戶端針對(duì)2020年春節(jié)紅包的技術(shù)實(shí)踐》

《即時(shí)通訊新手入門：一文讀懂什么是Nginx？它能否實(shí)現(xiàn)IM的負(fù)載均衡？》

《即時(shí)通訊新手入門：快速理解RPC技術(shù)——基本概念、原理和用途》

《多維度對(duì)比5款主流分布式MQ消息隊(duì)列，媽媽再也不擔(dān)心我的技術(shù)選型了》

《從游擊隊(duì)到正規(guī)軍(一)：馬蜂窩旅游網(wǎng)的IM系統(tǒng)架構(gòu)演進(jìn)之路》

《從游擊隊(duì)到正規(guī)軍(二)：馬蜂窩旅游網(wǎng)的IM客戶端架構(gòu)演進(jìn)和實(shí)踐總結(jié)》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(六)：數(shù)據(jù)庫(kù)用NoSQL還是SQL？讀這篇就夠了！》

《瓜子IM智能客服系統(tǒng)的數(shù)據(jù)架構(gòu)設(shè)計(jì)（整理自現(xiàn)場(chǎng)演講，有配套PPT）》

《阿里釘釘技術(shù)分享：企業(yè)級(jí)IM王者——釘釘在后端架構(gòu)上的過(guò)人之處》

《從游擊隊(duì)到正規(guī)軍(三)：基于Go的馬蜂窩旅游網(wǎng)分布式IM系統(tǒng)技術(shù)實(shí)踐》

《微信后臺(tái)基于時(shí)間序的新一代海量數(shù)據(jù)存儲(chǔ)架構(gòu)的設(shè)計(jì)實(shí)踐》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(九)：想開(kāi)發(fā)IM集群？先搞懂什么是RPC！》

>> 更多同類文章 ……

（本文同步發(fā)布于：http://www.52im.net/thread-3036-1-1.html）