本文由阿里閑魚(yú)技術(shù)團(tuán)隊(duì)今朝、有攸分享，本次有修訂。
1、引言
閑魚(yú)即時(shí)消息系統(tǒng)歷經(jīng)數(shù)代迭代，目前已能穩(wěn)定的支撐億級(jí)消息體量。
在此消息系統(tǒng)的建設(shè)過(guò)程中，我們經(jīng)歷了從簡(jiǎn)單到復(fù)雜、從困擾到破局，每一次的技術(shù)改變都是為了更好的解決當(dāng)下業(yè)務(wù)所面臨的問(wèn)題。
本文分享的是閑魚(yú)即時(shí)消息系統(tǒng)架構(gòu)從零開(kāi)始的技術(shù)變遷之路，以期更多的同行們?cè)诖嘶A(chǔ)上汲取經(jīng)驗(yàn)，得到有價(jià)值的啟發(fā)。
（本文同步發(fā)布于：http://www.52im.net/thread-3699-1-1.html ）
2、系列文章
本文是系列文章的第3篇，總目錄如下：
- 《阿里IM技術(shù)分享(一)：企業(yè)級(jí)IM王者——釘釘在后端架構(gòu)上的過(guò)人之處》
- 《阿里IM技術(shù)分享(二)：閑魚(yú)IM基于Flutter的移動(dòng)端跨端改造實(shí)踐》
- 《阿里IM技術(shù)分享(三)：閑魚(yú)億級(jí)IM消息系統(tǒng)的架構(gòu)演進(jìn)之路》（* 本文）
- 《阿里IM技術(shù)分享(四)：閑魚(yú)億級(jí)IM消息系統(tǒng)的可靠性投遞技術(shù)實(shí)踐》（* 稍后發(fā)布）
3、1.0版：業(yè)務(wù)初創(chuàng)期、最小化可用
3.1 技術(shù)背景
2014年啟動(dòng)閑置交易獨(dú)立APP “閑魚(yú)”，一期構(gòu)建完成APP主鏈路，包含商品：發(fā)布→搜索→商品詳情→IM會(huì)話→交易。
作為初創(chuàng)app，業(yè)務(wù)需盡快上線驗(yàn)證效果，技術(shù)建設(shè)上需要完成閑魚(yú)消息從無(wú)到有的系統(tǒng)搭建。
3.2 技術(shù)方案
作為即時(shí)通訊系統(tǒng)，最小化能力包含：
- 1）消息存儲(chǔ)：會(huì)話、摘要、消息；
- 2）消息同步：推、拉；
- 3）消息通道：長(zhǎng)連接、廠商推送。
與一般IM會(huì)話模型不同的是，閑魚(yú)會(huì)話以商品為主體，“人＋人+商品”為要素構(gòu)建會(huì)話。
因會(huì)話模型的差異，淘系已有的消息系統(tǒng)，短期內(nèi)無(wú)法滿足業(yè)務(wù)需求，而閑魚(yú)完全自建消息系統(tǒng)耗時(shí)巨大。
為了保障業(yè)務(wù)高效上線，技術(shù)選型上最大化復(fù)用已有系統(tǒng)能力，避免重復(fù)造輪子。
所以，我們的技術(shù)方案是：
- 1）數(shù)據(jù)模型與底層存儲(chǔ)依賴淘系私信體系進(jìn)行建設(shè)；
- 2）消息數(shù)據(jù)獲取上，客戶端全量從服務(wù)端拉取消息數(shù)據(jù)；
- 3）通訊協(xié)議使用來(lái)往SDK及mtop。
總體架構(gòu)如下圖，以此模式完成快速交付保障了業(yè)務(wù)最小化可用：
4、2.0版：用戶量增速快、需要重建消息系統(tǒng)
4.1 技術(shù)背景
閑魚(yú)用戶量正快速突破100萬(wàn)，即時(shí)消息服務(wù)的調(diào)用量暴漲。在這樣的背景下，用戶反饋消息數(shù)據(jù)獲取的卡頓、白屏成為常態(tài)，大量的消息Push發(fā)送下，系統(tǒng)告警頻發(fā)。
造成這些問(wèn)題的原因：1.0版的架構(gòu)模式下，獲取消息數(shù)據(jù)全量拉模式，客戶端純UI不做數(shù)據(jù)存儲(chǔ)。
具體就是：
- 1）當(dāng)用戶需要查看消息數(shù)據(jù)時(shí)，數(shù)據(jù)拉取成功與否取決于網(wǎng)絡(luò)、數(shù)據(jù)訪問(wèn)速度，偶發(fā)性的造成卡頓、白屏；
- 2）中心化的數(shù)據(jù)存儲(chǔ)，讀遠(yuǎn)大于寫(xiě)，高并發(fā)下，服務(wù)端負(fù)載過(guò)大。
針對(duì)第2）點(diǎn)：比如1W個(gè)用戶同時(shí)在線聊天，按照當(dāng)前架構(gòu)并發(fā)拉取全量消息，估算5萬(wàn)QPS。不妨假設(shè)，同時(shí)在線聊天用戶數(shù)10萬(wàn)時(shí)，對(duì)服務(wù)端壓力可想而知。
4.2 技術(shù)方案
基于上述問(wèn)題，我們決定重建消息系統(tǒng)架構(gòu)，以應(yīng)對(duì)未來(lái)更大的用戶增量。
回歸到IM系統(tǒng)的核心功能：
4.2.1）消息存儲(chǔ)模型：
- 1）會(huì)話模型：由owner、itemid、user、sessionType 來(lái)標(biāo)識(shí)唯一會(huì)話，增加擴(kuò)展屬性支持個(gè)性化；
- 2）摘要模型：作為用戶會(huì)話視圖，同一會(huì)話的不同用戶可個(gè)性化呈現(xiàn)，由userid、sid標(biāo)識(shí)唯一摘要；
- 3）消息模型：由sender、消息內(nèi)容、消息版本、sid組成。sid+消息版本唯一確定一條消息；
- 4）指令模型：是一種雙端約定，由服務(wù)端下發(fā)，客戶端執(zhí)行的指令集。如免打擾指令、刪除指令等。
4.2.2）消息通道：
1）在線通道：使用淘寶無(wú)線ACCS長(zhǎng)連接提供的全雙工、低延時(shí)、高安全的通道服務(wù)；
2）離線通道：使用淘寶消息推送平臺(tái)AGOO. 其屏蔽了各主流廠商對(duì)接的復(fù)雜度，直接對(duì)業(yè)務(wù)系統(tǒng)提供服務(wù)。
4.2.3）消息同步模型：
1）客戶端建立數(shù)據(jù)庫(kù)，存儲(chǔ)消息數(shù)據(jù)：當(dāng)消息數(shù)據(jù)存儲(chǔ)在本地設(shè)備上，消息同步從全量拉取優(yōu)化為全量+增量同步結(jié)合的模式。
增量和全量同步具體指的是：
- a. 增量同步：客戶端存儲(chǔ)消息位點(diǎn)信息，通過(guò)與服務(wù)端最新位點(diǎn)比較，僅同步增量消息；
- b. 全量同步：當(dāng)用戶卸載重裝或位點(diǎn)gap過(guò)大時(shí)，客戶端全量拉取歷史消息數(shù)據(jù)，進(jìn)行端上數(shù)據(jù)重建。
2）服務(wù)端建設(shè)個(gè)人消息域環(huán)(收件箱模型)：以和客戶端進(jìn)行增量數(shù)據(jù)同步。同時(shí)，1.0版本架構(gòu)中存在的讀多寫(xiě)少的問(wèn)題，通過(guò)個(gè)人域環(huán)的寫(xiě)擴(kuò)散來(lái)平衡讀寫(xiě)壓力。
下圖為一條消息從發(fā)送到接收的過(guò)程以及服務(wù)端和客戶端的執(zhí)行流程：
如上圖所示：假設(shè)Ua給Ub發(fā)送一條消息，消息寫(xiě)擴(kuò)散至Ua和Ub的各自的域環(huán)中：
- 1）當(dāng)客戶端online時(shí)，接收到推送的消息位點(diǎn)=當(dāng)前端上域版本+1，本地消息數(shù)據(jù)庫(kù)merge即可；
- 2）當(dāng)客戶端offline時(shí)，僅進(jìn)行離線推送通知，當(dāng)用戶重新上線時(shí)，進(jìn)行數(shù)據(jù)同步，由服務(wù)端判斷觸發(fā)增量同步還是全量同步。
針對(duì)第2）點(diǎn)，具體邏輯是：
- 1）如果域環(huán)版本差值小于閥值，增量同步后，進(jìn)行本地消息數(shù)據(jù)庫(kù)merge；
- 2）當(dāng)域環(huán)版本差值大于閥值，進(jìn)行全量消息拉取，做端上數(shù)據(jù)重建。
整個(gè)同步邏輯基于閑魚(yú)的即時(shí)消息域環(huán)，域環(huán)可以看作是有著固定容量的用戶消息收件箱，給一個(gè)用戶發(fā)送的所有消息都會(huì)同步到他的域環(huán)中。
具體就是：
- 1）域環(huán)存儲(chǔ)：域環(huán)需要支持高并發(fā)數(shù)據(jù)讀寫(xiě)，使用阿里分布式KV存儲(chǔ)系統(tǒng)tair來(lái)實(shí)現(xiàn)；
- 2）域環(huán)容量：為減少全量消息同步，以用戶下次進(jìn)入閑魚(yú)需要同步的平均消息量來(lái)規(guī)劃個(gè)人域環(huán)容量。同時(shí)利用FIFO循環(huán)覆蓋歷史數(shù)據(jù)；
- 3）域環(huán)版本：用戶當(dāng)前消息位點(diǎn)，在消息進(jìn)入個(gè)人域環(huán)時(shí)通過(guò)tair的counter實(shí)現(xiàn)域環(huán)版本嚴(yán)格連續(xù)遞增，用于全量、增量同步判斷。
上述建設(shè)完成后，閑魚(yú)具備了自己獨(dú)立的即時(shí)消息系統(tǒng)，當(dāng)下遇到的問(wèn)題得到了緩解，用戶體驗(yàn)度有大幅提升。
5、3.0版：隨著業(yè)務(wù)快速發(fā)展，系統(tǒng)穩(wěn)定性需得到保障
5.1 技術(shù)背景
隨著閑魚(yú)業(yè)務(wù)生態(tài)的豐富，IM會(huì)話與消息內(nèi)容類型不斷擴(kuò)展，同時(shí)在用戶量的快速增長(zhǎng)下，用戶反饋消息收不到、消息延遲等輿情問(wèn)題日漸突出。
5.2 問(wèn)題分析
問(wèn)題1：閑魚(yú)app進(jìn)程無(wú)有效保活機(jī)制，app退到后臺(tái)后進(jìn)程很快就會(huì)被系統(tǒng)掛起，導(dǎo)致長(zhǎng)連接中斷。此時(shí)消息推送走廠商通道，而廠商通道的實(shí)時(shí)性較差，且對(duì)消息推送的優(yōu)先級(jí)設(shè)定有差異，從而造成用戶感知消息延遲。
問(wèn)題2：accs在線消息推送時(shí)，平均延時(shí)較短，但存在假連情況。而且目前的消息推送鏈路無(wú)ack機(jī)制，造成服務(wù)端以為消息發(fā)出去了但實(shí)際上客戶端并沒(méi)有收到，用戶下次打開(kāi)app后才能看到消息，用戶感知消息延遲。
PS：造成假連接的原因主要是用戶退到后臺(tái)，accs長(zhǎng)連中斷，但是設(shè)備狀態(tài)更新有延時(shí)。
問(wèn)題3：目前消息同步的推模式(accs push)、拉模式(mtop)，客戶端未做隔離，異步進(jìn)行處理，導(dǎo)致在某些極端情況下消息數(shù)據(jù)庫(kù)處理異常，引發(fā)消息丟失。
如：某用戶上線后連續(xù)收到多條消息，其中一條觸發(fā)域黑洞，在進(jìn)行消息同步端上數(shù)據(jù)重建時(shí)，小概率處理出錯(cuò)。
問(wèn)題4：大部分線上消息問(wèn)題發(fā)現(xiàn)靠輿情反饋，如消息錯(cuò)亂，出問(wèn)題后系統(tǒng)無(wú)感知、無(wú)補(bǔ)救措施且排查困難，僅能跟隨版本做修復(fù)。
問(wèn)題5：業(yè)務(wù)不斷豐富，孵化出基于消息系統(tǒng)的服務(wù)號(hào)及小程序內(nèi)容營(yíng)銷、消息群組等，各類消息發(fā)送鏈路共用域環(huán)與數(shù)據(jù)存儲(chǔ)，造成穩(wěn)定性問(wèn)題。
如：個(gè)人域環(huán)的消息包括IM聊天和營(yíng)銷消息，IM聊天由用戶觸發(fā)，需要保證強(qiáng)到達(dá)；而營(yíng)銷消息一般是由系統(tǒng)通過(guò)班車等方式批量發(fā)送，消息量級(jí)大，tps高，影響IM服務(wù)穩(wěn)定性。
5.3 解案決方案
基于上述分析，我們逐個(gè)問(wèn)題進(jìn)行專項(xiàng)解決。
1）消息重發(fā)與推拉隔離：
如上圖所示：
- a. ACK：保障消息及時(shí)到達(dá)。服務(wù)端下行accs消息時(shí)，將消息加入重試隊(duì)列并延遲重試，客戶端在收到accs消息并處理成功后，給服務(wù)端回一個(gè)ack，服務(wù)端收到ack后更新消息到達(dá)狀態(tài)，并終止重試，以此避免設(shè)備假連或網(wǎng)絡(luò)不穩(wěn)定的情況；
- b. 重發(fā)：根據(jù)延遲重發(fā)策略決定何時(shí)重發(fā)消息，保障消息確定性到達(dá)。自適應(yīng)延遲重發(fā)策略是指新消息先通過(guò)4次固定N秒的短延遲來(lái)探測(cè)設(shè)備的網(wǎng)絡(luò)狀況，然后根據(jù)網(wǎng)絡(luò)狀況來(lái)遞增固定步長(zhǎng)M的延遲策略，這種策略可以保障在最短的時(shí)間內(nèi)，使用最少的重發(fā)次數(shù)將消息投遞成功；
- c. 消息隊(duì)列：端上引入消息隊(duì)列，按順序處理消息，保證消息處理的準(zhǔn)確性。同時(shí)進(jìn)行推拉隔離，保障隊(duì)列有序消費(fèi)，解決了復(fù)雜狀況下并發(fā)處理消息數(shù)據(jù)合并出錯(cuò)的問(wèn)題。
2）數(shù)據(jù)存儲(chǔ)拆分：
閑魚(yú)每天發(fā)送的即時(shí)消息中有一半以上是營(yíng)銷消息，營(yíng)銷消息的發(fā)送具有明顯的波峰波谷流量，高峰期會(huì)導(dǎo)致消息數(shù)據(jù)庫(kù)抖動(dòng)，影響IM消息。我來(lái)對(duì)消息、摘要、域環(huán)存儲(chǔ)做業(yè)務(wù)隔離，以適應(yīng)不同業(yè)務(wù)場(chǎng)景對(duì)穩(wěn)定性不同的要求。
具體做法是：
- 1）IM消息需要極高的穩(wěn)定性保證，其消息及摘要繼續(xù)使用mysql存儲(chǔ)；
- 2）營(yíng)銷消息存儲(chǔ)周期短，穩(wěn)定性要求低于IM，采用Lindorm存儲(chǔ)；
- 3）域環(huán)做實(shí)例級(jí)別隔離，保證IM域環(huán)的容量不會(huì)被其他消息占用，從而影響到消息同步。
PS：Lindorm是一種多模型的云原生數(shù)據(jù)庫(kù)服務(wù)，具有成本低、自定義TTL、容量橫向擴(kuò)展等優(yōu)勢(shì)。
3）線上問(wèn)題發(fā)現(xiàn)與恢復(fù)：
保障穩(wěn)定性的關(guān)鍵要素是做好各種核心指標(biāo)的監(jiān)控，而監(jiān)控首先要有數(shù)據(jù)來(lái)源，對(duì)服務(wù)端+客戶端的關(guān)鍵鏈路節(jié)點(diǎn)埋點(diǎn)，基于集團(tuán)UT、SLS，通過(guò)blink進(jìn)行實(shí)時(shí)清洗、計(jì)算，最終形成統(tǒng)一規(guī)范的日志數(shù)據(jù)落至SLS，以供實(shí)時(shí)監(jiān)控及鏈路排查。
消息系統(tǒng)的核心目標(biāo)是保障用戶消息發(fā)的出、收得到且及時(shí)收到，所以我們通過(guò)計(jì)算發(fā)送成功率、到達(dá)率、消息延遲來(lái)監(jiān)控系統(tǒng)的穩(wěn)定性。
此外，為了解決用戶輿情排查困難的問(wèn)題：
- 1）我們?cè)O(shè)計(jì)了一套指令集，通過(guò)約定指令協(xié)議，服務(wù)端向指定用戶下發(fā)指令，客戶端執(zhí)行對(duì)應(yīng)指令進(jìn)行異常數(shù)據(jù)上報(bào)，提高排查效率；
- 2）擴(kuò)展了強(qiáng)制全量同步、數(shù)據(jù)校正等指令，定向修復(fù)用戶消息數(shù)據(jù)問(wèn)題，相較以往出現(xiàn)嚴(yán)重bug只能讓用戶卸載重裝解決，這種方式顯然對(duì)用戶是更友好的。
經(jīng)過(guò)一系列專項(xiàng)治理，技術(shù)類輿情下降50%，從0到1建設(shè)了消息穩(wěn)定性體系，用戶體驗(yàn)進(jìn)一步提升。
6、展望未來(lái)
閑魚(yú)作為電商交易APP， 其中IM是交易的前置鏈路，IM的產(chǎn)品體驗(yàn)極大影響用戶交易效率。
前段時(shí)間進(jìn)行用戶調(diào)研，從閑魚(yú)IM的NPS低于預(yù)期（NPS是用戶忠誠(chéng)度衡量指標(biāo) = 推薦者%-貶損者%）。
從用戶反饋來(lái)看：
- 1）部分用戶對(duì)產(chǎn)品功能有較強(qiáng)烈的訴求，諸如消息搜索、分組等；
- 2）大部分用戶對(duì)發(fā)送消息過(guò)程中的違規(guī)問(wèn)題難以理解；
- 3）仍有較多輿情反饋消息收不到或延遲。
映射到目前閑魚(yú)的即時(shí)消息系統(tǒng)上，我們的系統(tǒng)架構(gòu)依然有很多需要持續(xù)改進(jìn)的地方。
典型的如：同步協(xié)議冗余，在需求迭代過(guò)程中容易引發(fā)問(wèn)題、有效保活機(jī)制的缺失對(duì)消息即時(shí)送達(dá)的影響、小眾機(jī)型離線消息收不到、多年的數(shù)據(jù)積累在線庫(kù)臃腫等問(wèn)題，影響著閑魚(yú)業(yè)務(wù)迭代速度與NPS。
作為技術(shù)團(tuán)隊(duì)，下一步將提升NPS作為核心技術(shù)目標(biāo)，閑魚(yú)的即時(shí)消息系統(tǒng)4.0版架構(gòu)正在路上 ......
附錄：更多相關(guān)文章
[1] 更多阿里巴巴的技術(shù)資源：
《阿里釘釘技術(shù)分享：企業(yè)級(jí)IM王者——釘釘在后端架構(gòu)上的過(guò)人之處》
《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲(chǔ)方案探討》
《阿里技術(shù)分享：深度揭秘阿里數(shù)據(jù)庫(kù)技術(shù)方案的10年變遷史》
《阿里技術(shù)分享：阿里自研金融級(jí)數(shù)據(jù)庫(kù)OceanBase的艱辛成長(zhǎng)之路》
《來(lái)自阿里OpenIM：打造安全可靠即時(shí)通訊服務(wù)的技術(shù)實(shí)踐分享》
《釘釘——基于IM技術(shù)的新一代企業(yè)OA平臺(tái)的技術(shù)挑戰(zhàn)(視頻+PPT) [附件下載]》
《阿里技術(shù)結(jié)晶：《阿里巴巴Java開(kāi)發(fā)手冊(cè)(規(guī)約)-華山版》[附件下載]》
《重磅發(fā)布：《阿里巴巴Android開(kāi)發(fā)手冊(cè)(規(guī)約)》[附件下載]》
《作者談《阿里巴巴Java開(kāi)發(fā)手冊(cè)(規(guī)約)》背后的故事》
《《阿里巴巴Android開(kāi)發(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)，在群聊、直播場(chǎng)景下的技術(shù)實(shí)踐》
《阿里技術(shù)分享：閑魚(yú)IM基于Flutter的移動(dòng)端跨端改造實(shí)踐》
《阿里IM技術(shù)分享(三)：閑魚(yú)億級(jí)IM消息系統(tǒng)的架構(gòu)演進(jìn)之路》
[2] 有關(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)歷程（一）》
《移動(dòng)端IM中大規(guī)模群消息的推送如何保證效率、實(shí)時(shí)性？》
《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲(chǔ)方案探討》
《微信朋友圈千億訪問(wèn)量背后的技術(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)場(chǎng)演講，有配套PPT）》
《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(九)：想開(kāi)發(fā)IM集群？先搞懂什么是RPC！》
《阿里技術(shù)分享：電商IM消息平臺(tái)，在群聊、直播場(chǎng)景下的技術(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ì)揭秘：消息模型、萬(wàn)人群、已讀回執(zhí)、消息撤回等》
《融云技術(shù)分享：全面揭秘億級(jí)IM消息的可靠投遞機(jī)制》
《IM開(kāi)發(fā)技術(shù)學(xué)習(xí)：揭秘微信朋友圈這種信息推流背后的系統(tǒng)設(shè)計(jì)》
《阿里IM技術(shù)分享(三)：閑魚(yú)億級(jí)IM消息系統(tǒng)的架構(gòu)演進(jìn)之路》
>> 更多同類文章 ……
本文已同步發(fā)布于“即時(shí)通訊技術(shù)圈”公眾號(hào)。
同步發(fā)布鏈接是：http://www.52im.net/thread-3699-1-1.html