本文由will分享，個(gè)人博客zhangyaoo.github.io，原題“基于Netty的IM系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)”，有修訂和重新排版。

1、引言

本文將要分享的是如何從零實(shí)現(xiàn)一套基于Netty框架的分布式高可用IM系統(tǒng)，它將支持長連接網(wǎng)關(guān)管理、單聊、群聊、聊天記錄查詢、離線消息存儲(chǔ)、消息推送、心跳、分布式唯一ID、紅包、消息同步等功能，并且還支持集群部署。

本文中針對(duì)這套架構(gòu)和系統(tǒng)設(shè)計(jì)，同時(shí)還會(huì)提供完整的源碼，比較適合有一定Java開發(fā)能力和Netty知識(shí)的IM初學(xué)者。

(相關(guān)資料圖)

*友情提示：如果你對(duì)IM即時(shí)通訊的基礎(chǔ)技術(shù)理論了解的太少，建議可以先讀：《新手入門一篇就夠：從零開發(fā)移動(dòng)端IM》。

技術(shù)交流：

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

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點(diǎn)此）

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

2、配套源碼

本文配套源碼的開源托管地址是：

• 1）主地址：https://github.com/zhangyaoo/fastim
• 2）備地址：https://github.com/52im/fastim2023

如果你訪問Github太慢，可直接從以下附件打包下載：

fastim-master(52im.net).zip(1.12 MB, 下載次數(shù):5, 售價(jià):1金幣)

完整源碼的目錄結(jié)構(gòu)，如下圖：

3、知識(shí)準(zhǔn)備

關(guān)于 Netty 是什么，這里簡單介紹下：

Netty 是一個(gè) Java 開源框架。Netty 提供異步的、事件驅(qū)動(dòng)的網(wǎng)絡(luò)應(yīng)用程序框架和工具，用以快速開發(fā)高性能、高可靠性的網(wǎng)絡(luò)服務(wù)器和客戶端程序。

也就是說，Netty 是一個(gè)基于 NIO 的客戶、服務(wù)器端編程框架，使用Netty 可以確保你快速和簡單的開發(fā)出一個(gè)網(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)境搭建、動(dòng)手實(shí)戰(zhàn)

如果你連Java NIO都不知道，下面的文章建議優(yōu)先讀：

• 1）少啰嗦！一分鐘帶你讀懂Java的NIO和經(jīng)典IO的區(qū)別
• 2）史上最強(qiáng)Java NIO入門：擔(dān)心從入門到放棄的，請(qǐng)讀這篇！
• 3）Java的BIO和NIO很難懂？用代碼實(shí)踐給你看，再不懂我轉(zhuǎn)行！

Netty源碼和API 在線查閱地址：

• 1）Netty-4.1.x 完整源碼（在線閱讀版）
• 2）Netty-4.1.x API文檔（在線版）

4、整體架構(gòu)設(shè)計(jì)概覽

本次的IM系統(tǒng)設(shè)計(jì)主要基于可擴(kuò)展性高可用原則，把網(wǎng)關(guān)層、邏輯層、數(shù)據(jù)層進(jìn)行了分離，并且還要支持分布式部署。

以下是整體系統(tǒng)的架構(gòu)設(shè)計(jì)概覽圖：

下面將針對(duì)整體架構(gòu)來逐一分享設(shè)計(jì)的主要思路等。

5、整體架構(gòu)設(shè)計(jì)之客戶端設(shè)計(jì)

5.1客戶端設(shè)計(jì)

客戶端的設(shè)計(jì)主要從以下幾點(diǎn)出發(fā)：

• 1）client每個(gè)設(shè)備會(huì)在本地存每一個(gè)會(huì)話，保留有最新一條消息的順序 ID；
• 2）為了避免client宕機(jī)，也就是退出應(yīng)用，保存在內(nèi)存的消息ID丟失，會(huì)存到本地的文件中；
• 3）client需要在本地維護(hù)一個(gè)等待ack隊(duì)列，并配合timer超時(shí)機(jī)制，來記錄哪些消息沒有收到ack：N，以定時(shí)重發(fā)；
• 4）客戶端本地生成一個(gè)遞增序列號(hào)發(fā)送給服務(wù)器，用作保證發(fā)送順序性。該序列號(hào)還用作ack隊(duì)列收消息時(shí)候的移除。

5.2客戶端序列號(hào)設(shè)計(jì)

1）方案一：

設(shè)計(jì)思路：

• 1）數(shù)據(jù)傳輸中的大小盡量小用int，不用bigint，節(jié)省傳輸大??；
• 2）只保證遞增即可,在用戶重新登錄或者重連后可以進(jìn)行日期重置，只保證單次；
• 3）客戶端發(fā)號(hào)器不需要像類似服務(wù)器端發(fā)號(hào)器那樣集群部署，不需要考慮集群同步問題。

注：上述生成器可以用18年[(2^29-1)/3600/24/365]左右，一秒內(nèi)最多產(chǎn)生4個(gè)消息。

優(yōu)點(diǎn)：可以在斷線重連和重裝APP的情況下，18年之內(nèi)是有序的。

缺點(diǎn)：每秒只能發(fā)4個(gè)消息，限制太大，對(duì)于群發(fā)場(chǎng)景不合適。

改進(jìn)：使用long進(jìn)行傳輸，年限擴(kuò)展很久并且有序。

2）方案二：

設(shè)計(jì)思路：

• 1）每次重新建立鏈接后進(jìn)行重置，將sequence_id（int表示）從0開始進(jìn)行嚴(yán)格遞增；
• 2）客戶端發(fā)送消息會(huì)帶上唯一的遞增sequence_id，同一條消息重復(fù)投遞的sequence_id是一樣的；
• 3）后端存儲(chǔ)每個(gè)用戶的sequence_id，當(dāng)sequence_id歸0，用戶的epoch年代加1存儲(chǔ)入庫，單聊場(chǎng)景下轉(zhuǎn)發(fā)給接收者時(shí)候，接收者按照sequence_id和epoch來進(jìn)行排序。

優(yōu)點(diǎn)：可以在斷線重連和重裝APP的情況下，接收者可以按照發(fā)送者發(fā)送時(shí)序來顯示，并且對(duì)發(fā)送消息的速率沒限制。

6、整體架構(gòu)設(shè)計(jì)之LSB設(shè)計(jì)

6.1思路

IM接入層的高可用、負(fù)載均衡、擴(kuò)展性全部在這里面做?？蛻舳送ㄟ^LSB，來獲取gate IP地址，通過IP直連。

這樣做的目的是：

• 1）靈活的負(fù)載均衡策略 可根據(jù)最少連接數(shù)來分配IP；
• 2）做灰度策略來分配IP；
• 3）AppId業(yè)務(wù)隔離策略 不同業(yè)務(wù)連接不同的gate，防止相互影響；
• 4）單聊和群聊的im接入層通道分開。

6.2優(yōu)化

上述設(shè)計(jì)存在一個(gè)問題：就是當(dāng)某個(gè)實(shí)例重啟后，該實(shí)例的連接斷開后，客戶端會(huì)發(fā)起重連，重連就大概率轉(zhuǎn)移其他實(shí)例上，導(dǎo)致最近啟動(dòng)的實(shí)例連接數(shù)較少，最早啟動(dòng)的實(shí)例連接數(shù)較多。

解決方法：

• 1）客戶端會(huì)發(fā)起重連，跟服務(wù)器申請(qǐng)重連的新的服務(wù)器IP，系統(tǒng)提供合適的算法來平攤gate層的壓力，防止雪崩效應(yīng)；
• 2）gate層定時(shí)上報(bào)本機(jī)的元數(shù)據(jù)信息以及連接數(shù)信息，提供給LSB中心，LSB根據(jù)最少連接數(shù)負(fù)載均衡實(shí)現(xiàn)，來計(jì)算一個(gè)節(jié)點(diǎn)供連接。

7、整體架構(gòu)設(shè)計(jì)之GATE層網(wǎng)關(guān)設(shè)計(jì)

GATE層網(wǎng)關(guān)設(shè)計(jì)主要遵從以下幾點(diǎn)：

• 1）任何一個(gè)gate網(wǎng)關(guān)斷掉，用戶端檢測(cè)到以后重新連接LSB服務(wù)獲取另一個(gè)gate網(wǎng)關(guān)IP，拿到IP重新進(jìn)行長連接通信（對(duì)整體服務(wù)可靠性基本沒有影響）；
• 2）gate可以無狀態(tài)的橫向部署，來擴(kuò)展接入層的接入能力；
• 3）根據(jù)協(xié)議分類將入口請(qǐng)求打到不同的網(wǎng)關(guān)上去，HTTP網(wǎng)關(guān)接收HTTP請(qǐng)求，TCP網(wǎng)關(guān)接收tcp長連接請(qǐng)求；
• 4）長連接網(wǎng)關(guān)，提供各種監(jiān)控功能，比如網(wǎng)關(guān)執(zhí)行線程數(shù)、隊(duì)列任務(wù)數(shù)、ByteBuf使用堆內(nèi)存數(shù)、堆外內(nèi)存數(shù)、消息上行和下行的數(shù)量以及時(shí)間。

8、整體架構(gòu)設(shè)計(jì)之LOGIC和路由SDK設(shè)計(jì)

logic按照分布式微服務(wù)的拆分思想進(jìn)行拆分，拆分為多個(gè)模塊，集群部署。

主要包括：

• 1）消息服務(wù)；
• 2）紅包服務(wù)；
• 3）其他服務(wù)。

消息logic服務(wù)集成路由客戶端的SDK，SDK職責(zé)主要是：

• 1）負(fù)責(zé)和網(wǎng)關(guān)底層通信交互；
• 2）負(fù)責(zé)網(wǎng)關(guān)服務(wù)尋址；
• 3）負(fù)責(zé)存儲(chǔ)uid和gate層機(jī)器ID關(guān)系（有狀態(tài)：多級(jí)緩存避免和中間件多次交互。無狀態(tài)：在業(yè)務(wù)初期可以不用存）；
• 4）配合網(wǎng)關(guān)負(fù)責(zé)路由信息一致性保證。

針對(duì)上述第4）點(diǎn)：

• 1）如果路由狀態(tài)和channel通道不一致，比如有路由狀態(tài)，沒有channel通道（已關(guān)閉）那么，就會(huì)走離線消息流出，并且清除路由信息；
• 2）動(dòng)態(tài)重啟gate，會(huì)及時(shí)清理路由信息。

SDK和網(wǎng)關(guān)底層通信設(shè)計(jì)：

如上圖所示：網(wǎng)關(guān)層到服務(wù)層，只需要單向傳輸發(fā)請(qǐng)求，網(wǎng)關(guān)層不需要關(guān)心調(diào)用的結(jié)果。而客戶端想要的ack或者notify請(qǐng)求是由SDK發(fā)送數(shù)據(jù)到網(wǎng)關(guān)層，SDK也不需要關(guān)心調(diào)用的結(jié)果，最后網(wǎng)關(guān)層只轉(zhuǎn)發(fā)數(shù)據(jù)，不做額外的邏輯處理。

SDK和所有的網(wǎng)關(guān)進(jìn)行長連接，當(dāng)發(fā)送信息給客戶端時(shí)，根據(jù)路由尋址信息，即可通過長連接推送信息。

9、通信協(xié)議設(shè)計(jì)

9.1目標(biāo)

通信協(xié)議設(shè)計(jì)的主要目標(biāo)是：

• 1）高性能：協(xié)議設(shè)計(jì)緊湊，保證數(shù)據(jù)包小，并且序列化性能好；
• 2）可擴(kuò)展：針對(duì)后續(xù)業(yè)務(wù)發(fā)展，可以自由的自定義協(xié)議，無需較大改動(dòng)協(xié)議結(jié)構(gòu)。

9.2設(shè)計(jì)

IM協(xié)議采用二進(jìn)制定長包頭和變長包體來實(shí)現(xiàn)客戶端和服務(wù)端的通信，并且采用谷歌protobuf序列化協(xié)議。

設(shè)計(jì)如下：

各個(gè)字段解釋如下：

• 1）headData：頭部標(biāo)識(shí)，協(xié)議頭標(biāo)識(shí)，用作粘包半包處理。4個(gè)字節(jié)；
• 2）version：客戶端版本。4個(gè)字節(jié)；
• 3）cmd：業(yè)務(wù)命令，比如心跳、推送、單聊、群聊。1個(gè)字節(jié)；
• 4）msgType：消息通知類型 request response notify。1個(gè)字節(jié)；
• 5）logId：調(diào)試性日志，追溯一個(gè)請(qǐng)求的全路徑。4個(gè)字節(jié)；
• 6）sequenceId：序列號(hào)，可以用作異步處理。4個(gè)字節(jié)；
• 7）dataLength：數(shù)據(jù)體的長度。4個(gè)字節(jié)；
• 8）data：數(shù)據(jù)。

PS：如果你對(duì)Protobuf不了解，建議詳讀以下系列文章：

1.《強(qiáng)列建議將Protobuf作為你的即時(shí)通訊應(yīng)用數(shù)據(jù)傳輸格式》

2.《IM通訊協(xié)議專題學(xué)習(xí)(一)：Protobuf從入門到精通，一篇就夠！》

3.《IM通訊協(xié)議專題學(xué)習(xí)(二)：快速理解Protobuf的背景、原理、使用、優(yōu)缺點(diǎn)》

4.《IM通訊協(xié)議專題學(xué)習(xí)(三)：由淺入深，從根上理解Protobuf的編解碼原理》

5.《IM通訊協(xié)議專題學(xué)習(xí)(四)：從Base64到Protobuf，詳解Protobuf的數(shù)據(jù)編碼原理》

6.《IM通訊協(xié)議專題學(xué)習(xí)(五)：Protobuf到底比JSON快幾倍？全方位實(shí)測(cè)！》

7.《IM通訊協(xié)議專題學(xué)習(xí)(六)：手把手教你如何在Android上從零使用Protobuf》

8.《IM通訊協(xié)議專題學(xué)習(xí)(七)：手把手教你如何在NodeJS中從零使用Protobuf》

9.《IM通訊協(xié)議專題學(xué)習(xí)(八)：金蝶隨手記團(tuán)隊(duì)的Protobuf應(yīng)用實(shí)踐(原理篇)》

10.《IM通訊協(xié)議專題學(xué)習(xí)(九)：手把手教你如何在iOS上從零使用Protobuf》

9.3實(shí)踐

針對(duì)數(shù)據(jù)data，網(wǎng)關(guān)gate層不做反序列化，反序列化步驟在service做，避免重復(fù)序列化和反序列化導(dǎo)致的性能損失。

網(wǎng)關(guān)層不做業(yè)務(wù)邏輯處理，只做消息轉(zhuǎn)發(fā)和推送，減少網(wǎng)關(guān)層的復(fù)雜度。

10、安全設(shè)計(jì)

為防止消息傳輸過程中不被截獲、篡改、偽造，采用TLS傳輸層加密協(xié)議（可參考《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》）。

私有化協(xié)議天然具備一定的防竊取和防篡改的能力，相對(duì)于使用JSON、XML、HTML等明文傳輸系統(tǒng)，被第三方截獲后在內(nèi)容破解上相對(duì)成本更高，因此安全性上會(huì)更好一些。

消息存儲(chǔ)安全性：將針對(duì)賬號(hào)密碼的存儲(chǔ)安全可以通過“高強(qiáng)度單向散列算法”和“加鹽”機(jī)制來提升加密密碼可逆性；IM消息采用“端到端加密”方式來提供更加安全的消息傳輸保護(hù)。

安全層協(xié)議設(shè)計(jì)：基于動(dòng)態(tài)密鑰，借鑒類似SSL，不需要用證書來管理（可參考《探討組合加密算法在IM中的應(yīng)用》）。

11、消息投遞設(shè)計(jì)

11.1概述

一個(gè)正常的消息流轉(zhuǎn)需要如下圖所示的流程：

如上圖所示：

• 1）客戶端A發(fā)送請(qǐng)求包R；
• 2）server將消息存儲(chǔ)到DB；
• 3）存儲(chǔ)成功后返回確認(rèn)ack；
• 4）server push消息給客戶端B；
• 5）客戶端B收到消息后返回確認(rèn)ack；
• 6）server收到ack后更新消息的狀態(tài)或者刪除消息。

需要考慮的是：一個(gè)健壯的IM系統(tǒng)需要考慮各種異常情況，比如丟消息，重復(fù)消息，消息時(shí)序問題。

11.2消息可靠性如何保證（不丟消息）

我的設(shè)計(jì)和實(shí)現(xiàn)思路是這樣的：

• 1）應(yīng)用層ACK；
• 2）客戶端需要超時(shí)與重傳；
• 3）服務(wù)端需要超時(shí)與重傳，具體做法就是增加ack隊(duì)列和定時(shí)器Timer；
• 4）業(yè)務(wù)側(cè)兜底保證，客戶端拉消息通過一個(gè)本地的舊的序列號(hào)來拉取服務(wù)器的最新消息；
• 5）為了保證消息必達(dá)，在線客戶端還增加一個(gè)定時(shí)器，定時(shí)向服務(wù)端拉取消息，避免服務(wù)端向客戶端發(fā)送拉取通知的包丟失導(dǎo)致客戶端未及時(shí)拉取數(shù)據(jù)。

相關(guān)資料可參考：

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

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

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

4.《IM開發(fā)干貨分享：如何優(yōu)雅的實(shí)現(xiàn)大量離線消息的可靠投遞》

5.《理解IM消息“可靠性”和“一致性”問題，以及解決方案探討》

6.《融云技術(shù)分享：全面揭秘億級(jí)IM消息的可靠投遞機(jī)制》

11.3消息重復(fù)性如何保證（不重復(fù)）

超時(shí)與重傳機(jī)制將導(dǎo)致接收的client收到重復(fù)的消息，具體做法就是一份消息使用同一個(gè)消息ID進(jìn)行去重處理。

相關(guān)資料可參考：

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

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

11.4消息順序性如何保證（不亂序）

消息亂序影響的因素：

• 1）時(shí)鐘不一致，分布式環(huán)境下每個(gè)機(jī)器的時(shí)間可能是不一致的；
• 2）多發(fā)送方和多接收方，這種情況下，無法保先發(fā)的消息被先收到；
• 3）網(wǎng)絡(luò)傳輸和多線程，網(wǎng)絡(luò)傳輸不穩(wěn)定的話可能導(dǎo)致包在數(shù)據(jù)傳輸過程中有的慢有的快。多線程也可能是會(huì)導(dǎo)致時(shí)序不一致影響的因素。

以上：如果保持絕對(duì)的實(shí)現(xiàn)，那么只能是一個(gè)發(fā)送方，一個(gè)接收方，一個(gè)線程阻塞式通訊來實(shí)現(xiàn)。那么性能會(huì)降低。

1）如何保證時(shí)序：

單聊：通過發(fā)送方的絕對(duì)時(shí)序seq，來作為接收方的展現(xiàn)時(shí)序seq。

實(shí)現(xiàn)方式：可以通過時(shí)間戳或者本地序列號(hào)方式來實(shí)現(xiàn)

缺點(diǎn)：本地時(shí)間戳不準(zhǔn)確或者本地序列號(hào)在意外情況下可能會(huì)清0，都會(huì)導(dǎo)致發(fā)送方的絕對(duì)時(shí)序不準(zhǔn)確

群聊：因?yàn)榘l(fā)送方多點(diǎn)發(fā)送時(shí)序不一致，所以通過服務(wù)器的單點(diǎn)做序列化，也就是通過ID遞增發(fā)號(hào)器服務(wù)來生成seq，接收方通過seq來進(jìn)行展現(xiàn)時(shí)序。

實(shí)現(xiàn)方式：通過服務(wù)端統(tǒng)一生成唯一趨勢(shì)遞增消息ID來實(shí)現(xiàn)或者通過redis的遞增incr來實(shí)現(xiàn)。

缺點(diǎn)：redis的遞增incr來實(shí)現(xiàn)，redis取號(hào)都是從主取的，會(huì)有性能瓶頸。ID遞增發(fā)號(hào)器服務(wù)是集群部署，可能不同發(fā)號(hào)服務(wù)上的集群時(shí)間戳不同，可能會(huì)導(dǎo)致后到的消息seq還小。

群聊時(shí)序的優(yōu)化：按照上面的群聊處理，業(yè)務(wù)上按照道理只需要保證單個(gè)群的時(shí)序，不需要保證所有群的絕對(duì)時(shí)序，所以解決思路就是同一個(gè)群的消息落到同一個(gè)發(fā)號(hào)service上面，消息seq通過service本地生成即可。

2）客戶端如何保證順序：

為什么要保證順序？因?yàn)橄⒓词拱凑枕樞虻竭_(dá)服務(wù)器端，也會(huì)可能出現(xiàn)：不同消息到達(dá)接收端后，可能會(huì)出現(xiàn)“先產(chǎn)生的消息后到”“后產(chǎn)生的消息先到”等問題。所以客戶端需要進(jìn)行兜底的流量整形機(jī)制

如何保證順序？可以在接收方收到消息后進(jìn)行判定，如果當(dāng)前消息序號(hào)大于前一條消息的序號(hào)就將當(dāng)前消息追加在會(huì)話里。否則繼續(xù)往前查找倒數(shù)第二條、第三條等消息，一直查找到恰好小于當(dāng)前推送消息的那條消息，然后插入在其后展示。

相關(guān)資料可參考：

《零基礎(chǔ)IM開發(fā)入門(四)：什么是IM系統(tǒng)的消息時(shí)序一致性？》

《一套億級(jí)用戶的IM架構(gòu)技術(shù)干貨(下篇)：可靠性、有序性、弱網(wǎng)優(yōu)化等》

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

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

12、消息通知設(shè)計(jì)

12.1概述

整體消息推送和拉取的時(shí)序圖如下：

12.2消息拉取方式的選擇

本系統(tǒng)是通過推拉結(jié)合來進(jìn)行服務(wù)器端消息的推送和客戶端的拉取。我們知道單pull和單push有以下缺點(diǎn)。

對(duì)于單pull：

• 1）pull要考慮到消息的實(shí)時(shí)性，不知道消息何時(shí)送達(dá)；
• 2）pull要考慮到哪些好友和群收到了消息，要循環(huán)每個(gè)群和好友拿到消息列表，讀擴(kuò)散。

對(duì)于單push：

• 1）push實(shí)時(shí)性高，只要將消息推送給接收者就ok，但是會(huì)集中消耗服務(wù)器資源；
• 2）并且再群聊非常多、聊天頻率非常高的情況下，會(huì)增加客戶端和服務(wù)端的網(wǎng)絡(luò)交互次數(shù)。

對(duì)于推拉結(jié)合：

• 1）推拉結(jié)合的方式能夠分?jǐn)偡?wù)端的壓力,能保證時(shí)效性，又能保證性能；
• 2）具體做法就是有新消息時(shí)候，推送哪個(gè)好友或者哪個(gè)群有新消息，以及新消息的數(shù)量或者最新消息ID，客戶端按需根據(jù)自身數(shù)據(jù)進(jìn)行拉取。

12.3推拉隔離設(shè)計(jì)

為什么做隔離？

如果客戶端一邊正在拉取數(shù)據(jù)，一邊有新的增量消息push過來。

如何做隔離？

本地設(shè)置一個(gè)全局的狀態(tài)，當(dāng)客戶端拉取完離線消息后設(shè)置狀態(tài)為1（表示離線消息拉取完畢）。當(dāng)客戶端收到拉取實(shí)時(shí)消息，會(huì)啟用一個(gè)輪詢監(jiān)聽這個(gè)狀態(tài)，狀態(tài)為1后，再去向服務(wù)器拉取消息。

如果是push消息過來（不是主動(dòng)拉?。敲磿?huì)先將消息存儲(chǔ)到本地的消息隊(duì)列中，等待客戶端上一次拉取數(shù)據(jù)完畢，然后將數(shù)據(jù)進(jìn)行合并即可。

相關(guān)資料可參考：

《阿里IM技術(shù)分享(六)：閑魚億級(jí)IM消息系統(tǒng)的離線推送到達(dá)率優(yōu)化》

《阿里IM技術(shù)分享(七)：閑魚IM的在線、離線聊天數(shù)據(jù)同步機(jī)制優(yōu)化實(shí)踐》

13、消息ID生成設(shè)計(jì)

以下是我設(shè)計(jì)的場(chǎng)景：

• 1）單機(jī)高峰并發(fā)量小于1W，預(yù)計(jì)未來5年單機(jī)高峰并發(fā)量小于10W；
• 2）有2個(gè)機(jī)房，預(yù)計(jì)未來5年機(jī)房數(shù)量小于4個(gè) 每個(gè)機(jī)房機(jī)器數(shù)小于150臺(tái)；
• 3）目前只有單聊和群聊兩個(gè)業(yè)務(wù)線，后續(xù)可以擴(kuò)展為系統(tǒng)消息、聊天室、客服等業(yè)務(wù)線，最多8個(gè)業(yè)務(wù)線。

根據(jù)以上業(yè)務(wù)情況，來設(shè)計(jì)分布式ID：

優(yōu)點(diǎn)：

• 1）不同機(jī)房不同機(jī)器不同業(yè)務(wù)線內(nèi)生成的ID互不相同；
• 2）每個(gè)機(jī)器的每毫秒內(nèi)生成的ID不同；
• 3）預(yù)留兩位留作擴(kuò)展位。

缺點(diǎn)：當(dāng)并發(fā)度不高的時(shí)候，時(shí)間跨毫秒的消息，區(qū)分不出來消息的先后順序。因?yàn)闀r(shí)間跨毫秒的消息生成的ID后面的最后一位都是0，后續(xù)如果按照消息ID維度進(jìn)行分庫分表，會(huì)導(dǎo)致數(shù)據(jù)傾斜。

兩種解決方案：

• 1）方案一：去掉snowflake最后8位，然后對(duì)剩余的位進(jìn)行取模；
• 2）方案二：不同毫秒的計(jì)數(shù)，每次不是歸0，而是歸為隨機(jī)數(shù)，相比方案一，比較簡單實(shí)用。

相關(guān)資料可參考：

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

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

《解密融云IM產(chǎn)品的聊天消息ID生成策略》

《深度解密美團(tuán)的分布式ID生成算法》

《開源分布式ID生成器UidGenerator的技術(shù)實(shí)現(xiàn)》

《深度解密滴滴的高性能ID生成器(Tinyid)》

14、消息未讀數(shù)設(shè)計(jì)

14.1基本

實(shí)現(xiàn)思路大致如下：

• 1）每發(fā)一個(gè)消息，消息接收者的會(huì)話未讀數(shù)+1，并且接收者所有未讀數(shù)+1；
• 2）消息接收者返回消息接收確認(rèn)ack后，消息未讀數(shù)會(huì)-1；
• 3）消息接收者的未讀數(shù)+1，服務(wù)端就會(huì)推算有多少條未讀數(shù)的通知。

分布式鎖保證總未讀數(shù)和會(huì)話未讀數(shù)一致：

• 1）原因：當(dāng)總未讀數(shù)增加，這個(gè)時(shí)候客戶端來了請(qǐng)求將未知數(shù)置0，然后再增加會(huì)話未讀數(shù)，那么會(huì)導(dǎo)致不一致；
• 2）保證：為了保證總未讀數(shù)和會(huì)話未讀數(shù)原子性，需要用分布式鎖來保證。

14.2群聊消息未讀數(shù)的難點(diǎn)和優(yōu)化思路

對(duì)于群聊來說，消息未讀數(shù)的技術(shù)難點(diǎn)主要是：一個(gè)群聊每秒幾百的并發(fā)聊天，比如消息未讀數(shù)，相當(dāng)于每秒W級(jí)別的寫入redis，即便redis做了集群數(shù)據(jù)分片+主從，但是寫入還是單節(jié)點(diǎn)，會(huì)有寫入瓶頸。

我的優(yōu)化思路是：按群ID分組或者用戶ID分組，批量寫入，寫入的兩種方式：定時(shí)flush和滿多少消息進(jìn)行flush。

15、網(wǎng)關(guān)設(shè)計(jì)

15.1概述

本套IM系統(tǒng)在設(shè)計(jì)時(shí)，將網(wǎng)關(guān)分為了接入層網(wǎng)關(guān)和應(yīng)用層網(wǎng)關(guān)兩種。

• 接入層網(wǎng)關(guān)和應(yīng)用層網(wǎng)關(guān)區(qū)別主要是：
• 1）接入層網(wǎng)關(guān)需要有接收通知包或者下行接收數(shù)據(jù)的端口，并且需要另外開啟線程池。應(yīng)用層網(wǎng)關(guān)不需要開端口，并且不需要開啟線程池；
• 2）接入層網(wǎng)關(guān)需要保持長連接，接入層網(wǎng)關(guān)需要本地緩存channel映射關(guān)系。應(yīng)用層網(wǎng)關(guān)無狀態(tài)不需要保存。

15.2接入層網(wǎng)關(guān)設(shè)計(jì)

我的設(shè)計(jì)目標(biāo)是：

• 1）網(wǎng)關(guān)的線程池實(shí)現(xiàn)1+8+4+1，減少線程切換；
• 2）集中實(shí)現(xiàn)長連接管理和推送能力；
• 3）與業(yè)務(wù)服務(wù)器解耦，集群部署縮容擴(kuò)容以及重啟升級(jí)不相互影響；
• 4）長連接的監(jiān)控與報(bào)警能力；
• 5）客戶端重連指令一鍵實(shí)現(xiàn)。

主要技術(shù)要點(diǎn)：

• 1）支持自定義協(xié)議以及序列化；
• 2）支持websocket協(xié)議；
• 3）通道連接自定義?；钜约靶奶鴻z測(cè)；
• 4）本地緩存channel；
• 5）責(zé)任鏈；
• 6）服務(wù)調(diào)用完全異步；
• 7）泛化調(diào)用；
• 8）轉(zhuǎn)發(fā)通知包或者Push包；
• 9）容錯(cuò)網(wǎng)關(guān)down機(jī)處理。

設(shè)計(jì)方案（一個(gè)Notify包的數(shù)據(jù)經(jīng)網(wǎng)關(guān)的線程模型圖）：

15.3應(yīng)用層API網(wǎng)關(guān)設(shè)計(jì)

我的設(shè)計(jì)目標(biāo)是：

• 1）基于版本的自動(dòng)發(fā)現(xiàn)以及灰度/擴(kuò)容 ，不需要關(guān)注IP；
• 2）網(wǎng)關(guān)的線程池實(shí)現(xiàn)1+8+1，減少線程切換；
• 3）支持協(xié)議轉(zhuǎn)換實(shí)現(xiàn)多個(gè)協(xié)議轉(zhuǎn)換，基于SPI來實(shí)現(xiàn)；
• 4）與業(yè)務(wù)服務(wù)器解耦，集群部署縮容擴(kuò)容以及重啟升級(jí)不相互影響；
• 5）接口錯(cuò)誤信息統(tǒng)計(jì)和RT時(shí)間的監(jiān)控和報(bào)警能力；
• 6）UI界面實(shí)現(xiàn)路由算法，服務(wù)接口版本管理，灰度策略管理以及接口和服務(wù)信息展示能力；
• 7）基于OpenAPI提供接口級(jí)別的自動(dòng)生成文檔的功能。

主要技術(shù)要點(diǎn)：

• 1）Http2.0；
• 2）channel連接池復(fù)用；
• 3）Netty http 服務(wù)端編解碼；
• 4）責(zé)任鏈；
• 5）服務(wù)調(diào)用完全異步；
• 6）全鏈路超時(shí)機(jī)制；
• 7）泛化調(diào)用。

設(shè)計(jì)方案（一個(gè)請(qǐng)求包的數(shù)據(jù)經(jīng)網(wǎng)關(guān)的架構(gòu)圖）：

16、高并發(fā)設(shè)計(jì)

16.1架構(gòu)優(yōu)化

主要從以下幾個(gè)方面入手：

• 1）水平擴(kuò)展：各個(gè)模塊無狀態(tài)部署；
• 2）線程模型：每個(gè)服務(wù)底層線程模型遵從Netty主從reactor模型；
• 3）多層緩存：Gate層二級(jí)緩存，Redis一級(jí)緩存；
• 4）長連接：客戶端長連接保持，避免頻繁創(chuàng)建連接消耗。

16.2萬人群聊優(yōu)化

技術(shù)難點(diǎn)主要是：消息扇出大，比如每秒群聊有50條消息，群聊2000人，那么光一個(gè)群對(duì)系統(tǒng)并發(fā)就有10W的消息扇出。

優(yōu)化思路：

• 1）批量ACK：每條群消息都ACK，會(huì)給服務(wù)器造成巨大的沖擊，為了減少ACK請(qǐng)求量，參考TCP的Delay ACK機(jī)制，在接收方層面進(jìn)行批量ACK；
• 2）群消息和成員批量加載以及懶加載：在真正進(jìn)入一個(gè)群時(shí)才實(shí)時(shí)拉取群友的數(shù)據(jù)；
• 3）群離線消息過多：群消息分頁拉取,第二次拉取請(qǐng)求作為第一次拉取請(qǐng)求的ack；
• 4）對(duì)于消息未讀數(shù)場(chǎng)景，每個(gè)用戶維護(hù)一個(gè)全局的未讀數(shù)和每個(gè)會(huì)話的未讀數(shù)，當(dāng)群聊非常大時(shí)，未讀資源變更的QPS非常大。這個(gè)時(shí)候應(yīng)用層對(duì)未讀數(shù)進(jìn)行緩存，批量寫+定時(shí)寫來保證未讀計(jì)數(shù)的寫入性能；
• 5）路由信息存入redis會(huì)有寫入和讀取的性能瓶頸，每條消息在發(fā)出的時(shí)候會(huì)查路由信息來發(fā)送對(duì)應(yīng)的gate接入層，比如有10個(gè)群，每個(gè)群1W，那么1s100條消息，那么1000W的查詢會(huì)打滿redis，即使redis做了集群。優(yōu)化的思路就是將集中的路由信息分散到msg層 JVM本地內(nèi)存中，然后做Route可用，避免單點(diǎn)故障；
• 6）存儲(chǔ)的優(yōu)化：擴(kuò)散寫寫入并發(fā)量巨大，另一方面也存在存儲(chǔ)浪費(fèi)，一般優(yōu)化成擴(kuò)散讀的方式存儲(chǔ)；
• 7）消息路由到相同接入層機(jī)器進(jìn)行合并請(qǐng)求減少網(wǎng)絡(luò)包傳輸。

相關(guān)資料：

1.《網(wǎng)易云信技術(shù)分享：IM中的萬人群聊技術(shù)方案實(shí)踐總結(jié)》

2.《企業(yè)微信的IM架構(gòu)設(shè)計(jì)揭秘：消息模型、萬人群、已讀回執(zhí)、消息撤回等》

3.《融云IM技術(shù)分享：萬人群聊消息投遞方案的思考和實(shí)踐》

16.3代碼優(yōu)化

具體的代碼優(yōu)化思路就是：本地會(huì)話信息由一個(gè)hashmap保持，導(dǎo)致鎖機(jī)制嚴(yán)重，按照用戶標(biāo)識(shí)進(jìn)行hash,講會(huì)話信息存在多個(gè)map中，減少鎖競(jìng)爭(zhēng)。同時(shí)利用雙buffer機(jī)制，避免未讀計(jì)數(shù)寫入阻塞。

16.4推拉結(jié)合優(yōu)化合并

背景：消息下發(fā)到群聊服務(wù)后，需要發(fā)送拉取通知給接收者，具體邏輯是群聊服務(wù)同步消息到路由層，路由層發(fā)送消息給接收者，接收者再來拉取消息。

問題：如果消息連續(xù)發(fā)送或者對(duì)同一個(gè)接收者連續(xù)發(fā)送消息頻率過高，會(huì)有許多的通知消息發(fā)送給路由層，消息量過大，可能會(huì)導(dǎo)致logic線程堆積，請(qǐng)求路由層阻塞。

解決：發(fā)送者發(fā)送消息到邏輯層持久化后，將通知消息先存放一個(gè)隊(duì)列中，相同的接收者接收消息通知消息后，更新相應(yīng)的最新消息通知時(shí)間，然后輪訓(xùn)線程會(huì)輪訓(xùn)隊(duì)列，將多個(gè)消息會(huì)合并為一個(gè)通知拉取發(fā)送至路由層，降低了客戶端與服務(wù)端的網(wǎng)絡(luò)消耗和服務(wù)器內(nèi)部網(wǎng)絡(luò)消耗。

好處：保證同一時(shí)刻，下發(fā)線程一輪只會(huì)向同一用戶發(fā)送一個(gè)通知拉取，一輪的時(shí)間可以自行控制。

17、高可用設(shè)計(jì)

17.1心跳設(shè)計(jì)

主要是：

• 1）服務(wù)端檢測(cè)到某個(gè)客戶端遲遲沒有心跳過來可以主動(dòng)關(guān)閉通道，讓它下線，并且清除在線信息和路由信息；
• 2）客戶端檢測(cè)到某個(gè)服務(wù)端遲遲沒有響應(yīng)心跳也能重連獲取一個(gè)新的連接。

智能心跳策略：比如正在發(fā)包的時(shí)候，不需要發(fā)送心跳。等待發(fā)包完畢后在開啟心跳。并且自適應(yīng)心跳策略調(diào)整。

相關(guān)資料：

《為何基于TCP協(xié)議的移動(dòng)端IM仍然需要心跳保活機(jī)制？》

《一文讀懂即時(shí)通訊應(yīng)用中的網(wǎng)絡(luò)心跳包機(jī)制：作用、原理、實(shí)現(xiàn)思路等》

《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺(tái)保活實(shí)戰(zhàn)分享(進(jìn)程?；钇?》

《微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺(tái)?；顚?shí)戰(zhàn)分享(網(wǎng)絡(luò)保活篇)》

《融云技術(shù)分享：融云安卓端IM產(chǎn)品的網(wǎng)絡(luò)鏈路?；罴夹g(shù)實(shí)踐》

《移動(dòng)端IM實(shí)踐：實(shí)現(xiàn)Android版微信的智能心跳機(jī)制》

《萬字長文：手把手教你實(shí)現(xiàn)一套高效的IM長連接自適應(yīng)心跳保活機(jī)制》

17.2系統(tǒng)穩(wěn)定性設(shè)計(jì)

背景：高峰期系統(tǒng)壓力大，偶發(fā)的網(wǎng)絡(luò)波動(dòng)或者機(jī)器過載，都有可能導(dǎo)致大量的系統(tǒng)失敗。加上IM系統(tǒng)要求實(shí)時(shí)性，不能用異步處理實(shí)時(shí)發(fā)過來的消息。所以有了柔性保護(hù)機(jī)制防止雪崩。

柔性保護(hù)機(jī)制開啟判斷指標(biāo)，當(dāng)每個(gè)指標(biāo)不在平均范圍內(nèi)的時(shí)候就開啟。

這些判斷指標(biāo)主要是：

• 1）每條消息的ack時(shí)間 RT時(shí)間
• 2）同時(shí)在線人數(shù)以及同時(shí)發(fā)消息的人數(shù)
• 3）每臺(tái)機(jī)器的負(fù)載CPU和內(nèi)存和網(wǎng)絡(luò)IO和磁盤IO以及GC參數(shù)

當(dāng)開啟了柔性保護(hù)機(jī)制，那么會(huì)返回失敗，用戶端體驗(yàn)不友好，如何優(yōu)化？

以下是我的優(yōu)化思路：

• 1）當(dāng)開啟了柔性保護(hù)機(jī)制，邏輯層hold住多余的請(qǐng)求，返回前端成功，不顯示發(fā)送失敗，后端異步重試，直至成功；
• 2）為了避免重試加劇系統(tǒng)過載，指數(shù)時(shí)間延遲重試。

17.3異常場(chǎng)景設(shè)計(jì)

gate層重啟升級(jí)或者意外down機(jī)有以下問題：

• 1）客戶端和gate意外丟失長連接，導(dǎo)致 客戶端在發(fā)送消息的時(shí)候?qū)е孪⒊瑫r(shí)等待以及客戶端重試等無意義操作；
• 2）發(fā)送給客戶端的消息，從Msg消息層轉(zhuǎn)發(fā)給gate的消息丟失，導(dǎo)致消息超時(shí)等待以及重試。

解決方案如下：

• 1）重啟升級(jí)時(shí)候，向客戶端發(fā)送重新連接指令，讓客戶端重新請(qǐng)求LSB獲取IP直連；
• 2）當(dāng)gate層down機(jī)異常停止時(shí)候，增加hook鉤子，向客戶端發(fā)送重新連接指令；
• 3）額外增加hook，向Msg消息層發(fā)送請(qǐng)求清空路由消息和在線狀態(tài)，并且清除redis的路由信息。

17.4Redis宕機(jī)高可用設(shè)計(jì)

Redis的作用背景：

• 1）當(dāng)用戶鏈接上網(wǎng)關(guān)后，網(wǎng)關(guān)會(huì)將用戶的userId和機(jī)器信息存入redis，用作這個(gè)user接收消息時(shí)候，消息的路由；
• 2）消息服務(wù)在發(fā)消息給user時(shí)候，會(huì)查詢Redis的路由信息，用來發(fā)送消息給哪個(gè)一個(gè)網(wǎng)關(guān)。

如果Redis宕機(jī)，會(huì)造成下面結(jié)果：

• 1）消息中轉(zhuǎn)不過去，所有的用戶可以發(fā)送消息，但是都接收不了消息；
• 2）如果有在線機(jī)制，那么系統(tǒng)都認(rèn)為是離線狀態(tài)，會(huì)走手機(jī)消息通道推送。

Redis宕機(jī)兜底處理策略：

• 1）消息服務(wù)定時(shí)任務(wù)同步路由信息到本地緩存，如果redis掛了，從本地緩存拿消息；
• 2）網(wǎng)關(guān)服務(wù)在收到用戶側(cè)的上線和下線后，會(huì)同步廣播本地的路由信息給各個(gè)消息服務(wù)，消息服務(wù)接收后更新本地環(huán)境數(shù)據(jù)；
• 3）網(wǎng)絡(luò)交互次數(shù)多，以及消息服務(wù)多，可以用批量或者定時(shí)的方式同步廣播路由消息給各個(gè)消息服務(wù)。

18、核心表結(jié)構(gòu)設(shè)計(jì)

核心設(shè)計(jì)要點(diǎn)：

• 1）群消息只存儲(chǔ)一份，用戶不需要為每個(gè)消息單獨(dú)存一份。用戶也無需去刪除群消息；
• 2）對(duì)于在線的用戶，收到群消息后，修改這個(gè)last_ack_msg_id；
• 3）對(duì)于離線用戶，用戶上線后，對(duì)比最新的消息ID和last_ack_msg_id，來進(jìn)行拉取(參考Kafka的消費(fèi)者模型)；
• 4）對(duì)應(yīng)單聊，需要記錄消息的送達(dá)狀態(tài)，以便在異常情況下來做重試處理。

群用戶消息表 t_group_user_msg：

群消息表 t_group_msg：

參考資料：

1.《一套海量在線用戶的移動(dòng)端IM架構(gòu)設(shè)計(jì)實(shí)踐分享(含詳細(xì)圖文)》

2.《基于Netty，從零開發(fā)一個(gè)IM服務(wù)端》

19、紅包設(shè)計(jì)

搶紅包的大致核心邏輯如下：

• 1）銀行快捷支付，保證賬戶余額和發(fā)送紅包邏輯的一致性；
• 2）發(fā)送紅包后，首先計(jì)算好紅包的個(gè)數(shù)，個(gè)數(shù)確定好后，確定好每個(gè)紅包的金額，存入存儲(chǔ)層【這里可以是redis的List或者是隊(duì)列】方便后續(xù)每個(gè)人來?。?/li>
• 3）生成一個(gè)24小時(shí)的延遲任務(wù)，檢測(cè)紅包是否還有錢方便退回；
• 4）每個(gè)紅包的金額需要保證每個(gè)紅包的的搶金額概率是一致的，算法需要考量；
• 5）存入數(shù)據(jù)庫表中后，服務(wù)器通過長連接，給群里notify紅包消息,供群成員搶紅包；
• 6）群成員并發(fā)搶紅包，在第二步中會(huì)將每個(gè)紅包的金額放入一個(gè)隊(duì)列或者其他存儲(chǔ)中，群成員實(shí)際是來競(jìng)爭(zhēng)去隊(duì)列中的紅包金額。兜底機(jī)制：如果redis掛了，可以重新生成紅包信息到數(shù)據(jù)庫中；
• 7）取成功后，需要保證紅包剩余金額、新插入的紅包流水?dāng)?shù)據(jù)、隊(duì)列中的紅包數(shù)據(jù)以及群成員的余額賬戶金額一致性；
• 8）這里還需要保證一個(gè)用戶只能領(lǐng)取一次，并且保持冪等。

相關(guān)資料：

《社交軟件紅包技術(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ù)解密(十一)：解密微信紅包隨機(jī)算法(含代碼實(shí)現(xiàn))》

《社交軟件紅包技術(shù)解密(十二)：解密抖音春節(jié)紅包背后的技術(shù)設(shè)計(jì)與實(shí)踐》

20、核心業(yè)務(wù)流程梳理

20.1單聊流程

假設(shè)是用戶A發(fā)消息給用戶B ，以下是完整的業(yè)務(wù)流程。

1）A打包數(shù)據(jù)發(fā)送給服務(wù)端，服務(wù)端接收消息后，根據(jù)接收消息的sequence_id來進(jìn)行客戶端發(fā)送消息的去重，并且生成遞增的消息ID，將發(fā)送的信息和ID打包一塊入庫，入庫成功后返回ACK，ACK包帶上服務(wù)端生成的消息ID。

2）服務(wù)端檢測(cè)接收用戶B是否在線，在線直接推送給用戶B。

3）如果沒有本地消息ID則存入，并且返回接入層ACK信息；如果有則拿本地sequence_id和推送過來的sequence_id大小對(duì)比，并且去重，進(jìn)行展現(xiàn)時(shí)序進(jìn)行排序展示，并且記錄最新一條消息ID。最后返回接入層ack。

4）服務(wù)端接收ACK后，將消息標(biāo)為已送達(dá)。

5）如果用戶B不在線,首先將消息存入庫中，然后直接通過手機(jī)通知來告知客戶新消息到來。

6）用戶B上線后，拿本地最新的消息ID，去服務(wù)端拉取所有好友發(fā)送給B的消息，考慮到一次拉取所有消息數(shù)據(jù)量大，通過channel通道來進(jìn)行分頁拉取，將上一次拉取消息的最大的ID，作為請(qǐng)求參數(shù)，來請(qǐng)求最新一頁的比ID大的數(shù)據(jù)。

20.2群聊流程

假設(shè)是用戶A發(fā)消息給群G，以下是完整的業(yè)務(wù)流程。

1）登錄，TCP連接，token校驗(yàn)，名詞檢查，sequence_id去重，生成遞增的消息ID，群消息入庫成功返回發(fā)送方ACK。

2）查詢?nèi)篏所有的成員，然后去redis中央存儲(chǔ)中找在線狀態(tài)。離線和在線成員分不同的方式處理。

3）在線成員：并行發(fā)送拉取通知，等待在線成員過來拉取，發(fā)送拉取通知包如丟失會(huì)有兜底機(jī)制。

4）在線成員過來拉取，會(huì)帶上這個(gè)群標(biāo)識(shí)和上一次拉取群的最小消息ID，服務(wù)端會(huì)找比這個(gè)消息ID大的所有的數(shù)據(jù)返回給客戶端，等待客戶端ACK。一段時(shí)間沒ack繼續(xù)推送。如果重試幾次后沒有回ack，那么關(guān)閉連接和清除ack等待隊(duì)列消息。

5）客戶端會(huì)更新本地的最新的消息ID，然后進(jìn)行ack回包。服務(wù)端收到ack后會(huì)更新群成員的最新的消息ID。

6）離線成員：發(fā)送手機(jī)通知欄通知。離線成員上線后，拿本地最新的消息ID，去服務(wù)端拉取群G發(fā)送給A的消息，通過channel通道來進(jìn)行分頁拉取，每一次請(qǐng)求，會(huì)將上一次拉取消息的最大的ID，作為請(qǐng)求參數(shù)來拉取消息，這里相當(dāng)于第二次拉取請(qǐng)求包是作為第一次拉取的ack包。

7）分頁的情況下，客戶端在收到上一頁請(qǐng)求的的數(shù)據(jù)后更新本地的最新的消息ID后，再請(qǐng)求下一頁并且?guī)舷D。上一頁請(qǐng)求的的數(shù)據(jù)可以當(dāng)作為ack來返回服務(wù)端，避免網(wǎng)絡(luò)多次交互。服務(wù)端收到ack后會(huì)更新群成員的最新的消息ID。

21、設(shè)計(jì)IM系統(tǒng)時(shí)的常見疑問

21.1相比傳統(tǒng)HTTP請(qǐng)求的業(yè)務(wù)系統(tǒng)，IM業(yè)務(wù)系統(tǒng)的有哪些不一樣的設(shè)計(jì)難點(diǎn)？

主要是在線狀態(tài)維護(hù)。

相比于HTTP請(qǐng)求的業(yè)務(wù)系統(tǒng)，接入層有狀態(tài)，必須維持心跳和會(huì)話狀態(tài)，加大了系統(tǒng)設(shè)計(jì)復(fù)雜度。

請(qǐng)求通信模型不一樣。相比于HTTP請(qǐng)求一個(gè)request等待一個(gè)response通信模型，IM系統(tǒng)則是一個(gè)數(shù)據(jù)包在全雙工長連接通道雙傳輸，客戶端和服務(wù)端消息交互的信令數(shù)據(jù)包設(shè)計(jì)復(fù)雜。

21.2對(duì)于單聊和群聊的實(shí)時(shí)性消息，是否需要MQ來作為通信的中間件來代替rpc？

MQ作為解耦可以有以下好處：

• 1）易擴(kuò)展：gate層到logic層無需路由，logic層多個(gè)有新的業(yè)務(wù)時(shí)候，只需要監(jiān)聽新的topic即可；
• 2）解耦：gate層到logic層解耦，不會(huì)有依賴關(guān)系；
• 3）節(jié)省端口資源：gate層無需再開啟新的端口接收logic的請(qǐng)求，而且直接監(jiān)聽MQ消息即可。

但是缺點(diǎn)也有：

• 1）網(wǎng)絡(luò)通信多一次網(wǎng)絡(luò)通信，增加RT的時(shí)間，消息實(shí)時(shí)性對(duì)于IM即使通信的場(chǎng)景是非常注重的一個(gè)點(diǎn)；
• 2）MQ的穩(wěn)定性，不管任何系統(tǒng)只要引入中間件都會(huì)有穩(wěn)定性問題，需要考慮MQ不可用或者丟失數(shù)據(jù)的情況；
• 3）需要考慮到運(yùn)維的成本；
• 4）當(dāng)用消息中間代替路由層的時(shí)候，gate層需要廣播消費(fèi)消息，這個(gè)時(shí)候gate層會(huì)接收大部分的無效消息，因?yàn)檫@個(gè)消息的接收者channel不在本機(jī)維護(hù)的session中。

綜上：是否考慮使用MQ需要架構(gòu)師去考量，比如考慮業(yè)務(wù)是否允許、或者系統(tǒng)的流量、或者高可用設(shè)計(jì)等等影響因素。本項(xiàng)目基于使用成本、耦合成本和運(yùn)維成本考慮，采用Netty作為底層自定義通信方案來實(shí)現(xiàn)，也能同樣實(shí)現(xiàn)層級(jí)調(diào)用。

參考資料：《阿里IM技術(shù)分享(九)：深度揭密RocketMQ在釘釘IM系統(tǒng)中的應(yīng)用實(shí)踐》。

21.3為什么接入層用LSB返回的IP來做接入呢？

可以有以下好處：

• 1）靈活的負(fù)載均衡策略 可根據(jù)最少連接數(shù)來分配IP；
• 2）做灰度策略來分配IP；
• 3）AppId業(yè)務(wù)隔離策略 不同業(yè)務(wù)連接不同的gate，防止相互影響。

21.4為什么應(yīng)用層心跳對(duì)連接進(jìn)行健康檢查？

因?yàn)門CP Keepalive狀態(tài)無法反應(yīng)應(yīng)用層狀態(tài)問題，如進(jìn)程阻塞、死鎖、TCP緩沖區(qū)滿等情況。

并且要注意心跳的頻率，頻率小則可能及時(shí)感知不到應(yīng)用情況，頻率大可能有一定的性能開銷。

參考資料：《為何基于TCP協(xié)議的移動(dòng)端IM仍然需要心跳?；顧C(jī)制？》、《徹底搞懂TCP協(xié)議層的KeepAlive?；顧C(jī)制》。

21.5MQ的使用場(chǎng)景？

IM消息是非常龐大的，比如說群聊相關(guān)業(yè)務(wù)、推送，對(duì)于一些業(yè)務(wù)上可以忍受的場(chǎng)景，盡量使用MQ來解耦和通信，來降低同步通訊的服務(wù)器壓力。

21.6群消息存一份還是多份，讀擴(kuò)散還是寫擴(kuò)散？

我的設(shè)計(jì)是存1份，讀擴(kuò)散。

存多份的話（也就是寫擴(kuò)散）下同一條消息存儲(chǔ)了很多次，對(duì)磁盤和帶寬造成了很大的浪費(fèi)?？梢栽诩軜?gòu)上和業(yè)務(wù)上進(jìn)行優(yōu)化，來實(shí)現(xiàn)讀擴(kuò)散。

當(dāng)然，對(duì)于IM是使用讀擴(kuò)散還是寫擴(kuò)散來實(shí)現(xiàn)，這需要根據(jù)IM產(chǎn)品的業(yè)務(wù)定位來決定。比如微信就是寫擴(kuò)散（詳見《企業(yè)微信的IM架構(gòu)設(shè)計(jì)揭秘：消息模型、萬人群、已讀回執(zhí)、消息撤回等》），而釘釘卻是讀擴(kuò)散（詳見《深度解密釘釘即時(shí)消息服務(wù)DTIM的技術(shù)設(shè)計(jì)》）。

21.7消息ID為什么是趨勢(shì)遞增就可以，嚴(yán)格遞增的不行嗎？

嚴(yán)格遞增會(huì)有單點(diǎn)性能瓶頸，比如MySQL auto increments。

redis性能好但是沒有業(yè)務(wù)語義，比如缺少時(shí)間因素，還可能會(huì)有數(shù)據(jù)丟失的風(fēng)險(xiǎn)，并且集群環(huán)境下寫入ID也屬于單點(diǎn)，屬于集中式生成服務(wù)。

小型IM可以根據(jù)業(yè)務(wù)場(chǎng)景需求直接使用redis的incr命令來實(shí)現(xiàn)IM消息唯一ID。

本項(xiàng)目采用snowflake算法實(shí)現(xiàn)唯一趨勢(shì)遞增ID，即可實(shí)現(xiàn)IM消息中，時(shí)序性，重復(fù)性以及查找功能。

關(guān)于消息ID的生成，可以參考下面的系列文章：

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

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

《解密融云IM產(chǎn)品的聊天消息ID生成策略》

《深度解密美團(tuán)的分布式ID生成算法》

《開源分布式ID生成器UidGenerator的技術(shù)實(shí)現(xiàn)》

《深度解密滴滴的高性能ID生成器(Tinyid)》

21.8gate層為什么需要開兩個(gè)端口？

gate會(huì)接收客戶端的連接請(qǐng)求（被動(dòng)），需要外網(wǎng)監(jiān)聽端口；entry會(huì)主動(dòng)給logic發(fā)請(qǐng)求（主動(dòng)）；entry會(huì)接收服務(wù)端給它的通知請(qǐng)求（被動(dòng)），需要內(nèi)網(wǎng)監(jiān)聽端口。一個(gè)端口對(duì)內(nèi)，一個(gè)端口對(duì)外。

21.9用戶的路由信息，是維護(hù)在中央存儲(chǔ)的redis中，還是維護(hù)在每個(gè)msg層內(nèi)存中？

維護(hù)在每個(gè)msg層內(nèi)存中有狀態(tài)：多級(jí)緩存避免和中間件多次交互，并發(fā)高。

維護(hù)在中央存儲(chǔ)的redis中，msg層無狀態(tài)，redis壓力大，每次交互IO網(wǎng)絡(luò)請(qǐng)求大。

業(yè)務(wù)初期為了減少復(fù)雜度，可以維護(hù)在Redis中。

21.10網(wǎng)關(guān)層和服務(wù)層以及msg層和網(wǎng)關(guān)層請(qǐng)求模型具體是怎樣的？

網(wǎng)關(guān)層到服務(wù)層，只需要單向傳輸發(fā)請(qǐng)求，網(wǎng)關(guān)層不需要關(guān)心調(diào)用的結(jié)果。

而客戶端想要的ack或者notify請(qǐng)求是由SDK發(fā)送數(shù)據(jù)到網(wǎng)關(guān)層，SDK也不需要關(guān)心調(diào)用的結(jié)果，最后網(wǎng)關(guān)層只轉(zhuǎn)發(fā)數(shù)據(jù)，不做額外的邏輯處理。

SDK和所有的網(wǎng)關(guān)進(jìn)行長連接，當(dāng)發(fā)送信息給客戶端時(shí)，根據(jù)路由尋址信息，即可通過長連接推送信息

21.11本地寫數(shù)據(jù)成功，一定代表對(duì)端應(yīng)用側(cè)接收讀取消息了嗎？

本地TCP寫操作成功，但數(shù)據(jù)可能還在本地寫緩沖區(qū)中、網(wǎng)絡(luò)鏈路設(shè)備中、對(duì)端讀緩沖區(qū)中，并不代表對(duì)端應(yīng)用讀取到了數(shù)據(jù)。

如果你還不理解，可以讀讀這篇文章《從客戶端的角度來談?wù)勔苿?dòng)端IM的消息可靠性和送達(dá)機(jī)制》。

21.12為什么用netty做來做http網(wǎng)關(guān), 而不用tomcat？

主要是從以下方面考慮：

• 1）netty對(duì)象池，內(nèi)存池，高性能線程模型；
• 2）netty堆外內(nèi)存管理，減少GC壓力，jvm管理的只是一個(gè)很小的DirectByteBuffer對(duì)象引用；
• 3）tomcat讀取數(shù)據(jù)和寫入數(shù)據(jù)都需要從內(nèi)核態(tài)緩沖copy到用戶態(tài)的JVM中，多1次或者2次的拷貝會(huì)有性能影響。

21.13為什么消息入庫后，對(duì)于在線狀態(tài)的用戶，單聊直接推送，群聊通知客戶端來拉取，而不是直接推送消息給客戶端（推拉結(jié)合）？

在保證消息實(shí)時(shí)性的前提下，對(duì)于單聊，直接推送。

對(duì)于群聊，由于群聊人數(shù)多，推送的話一份群消息會(huì)對(duì)群內(nèi)所有的用戶都產(chǎn)生一份推送的消息，推送量巨大。

解決辦法是按需拉取，當(dāng)群消息有新消息時(shí)候發(fā)送時(shí)候，服務(wù)端主動(dòng)推送新的消息數(shù)量，然后客戶端分頁按需拉取數(shù)據(jù)。

21.14為什么除了單聊、群聊、推送、離線拉取等實(shí)時(shí)性業(yè)務(wù)，其他的業(yè)務(wù)都走h(yuǎn)ttp協(xié)議？

IM協(xié)議簡單最好，如果讓其他的業(yè)務(wù)請(qǐng)求混進(jìn)IM協(xié)議中，會(huì)讓其IM變的更復(fù)雜，比如查找離線消息記錄拉取走h(yuǎn)ttp通道避免tcp 通道壓力過大，影響即時(shí)消息下發(fā)效率。

在比如上傳圖片和大文件，可以利用HTTP的斷點(diǎn)上傳和分段上傳特性。

21.15機(jī)集群機(jī)器要考慮到哪些優(yōu)化？

主要有：

• 1）網(wǎng)絡(luò)寬帶；
• 2）最大文件句柄；
• 3）每個(gè)tcp的內(nèi)存占用；
• 4）Linux系統(tǒng)內(nèi)核tcp參數(shù)優(yōu)化配置；
• 5）網(wǎng)絡(luò)IO模型；
• 6）網(wǎng)絡(luò)網(wǎng)絡(luò)協(xié)議解析效率；
• 7）心跳頻率；
• 8）會(huì)話數(shù)據(jù)一致性保證；
• 9）服務(wù)集群動(dòng)態(tài)擴(kuò)容縮容。

22、系列文章

《跟著源碼學(xué)IM(一)：手把手教你用Netty實(shí)現(xiàn)心跳機(jī)制、斷線重連機(jī)制》

《跟著源碼學(xué)IM(二)：自已開發(fā)IM很難？手把手教你擼一個(gè)Andriod版IM》

《跟著源碼學(xué)IM(三)：基于Netty，從零開發(fā)一個(gè)IM服務(wù)端》

《跟著源碼學(xué)IM(四)：拿起鍵盤就是干，教你徒手開發(fā)一套分布式IM系統(tǒng)》

《跟著源碼學(xué)IM(五)：正確理解IM長連接、心跳及重連機(jī)制，并動(dòng)手實(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ù)思路+源碼）》

《跟著源碼學(xué)IM(十一)：一套基于Netty的分布式高可用IM詳細(xì)設(shè)計(jì)與實(shí)現(xiàn)(有源碼)》（* 本文）

《SpringBoot集成開源IM框架MobileIMSDK，實(shí)現(xiàn)即時(shí)通訊IM聊天功能》

23、參考資料

[1]史上最通俗Netty框架入門長文：基本介紹、環(huán)境搭建、動(dòng)手實(shí)戰(zhàn)

[2]強(qiáng)列建議將Protobuf作為你的即時(shí)通訊應(yīng)用數(shù)據(jù)傳輸格式

[3]IM通訊協(xié)議專題學(xué)習(xí)(一)：Protobuf從入門到精通，一篇就夠！

[4]微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解

[5]探討組合加密算法在IM中的應(yīng)用

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

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

[8]理解IM消息“可靠性”和“一致性”問題，以及解決方案探討

[9]融云技術(shù)分享：全面揭秘億級(jí)IM消息的可靠投遞機(jī)制

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

[11]零基礎(chǔ)IM開發(fā)入門(四)：什么是IM系統(tǒng)的消息時(shí)序一致性？

[12]一套億級(jí)用戶的IM架構(gòu)技術(shù)干貨(下篇)：可靠性、有序性、弱網(wǎng)優(yōu)化等

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

[14]阿里IM技術(shù)分享(六)：閑魚億級(jí)IM消息系統(tǒng)的離線推送到達(dá)率優(yōu)化

[15]微信的海量IM聊天消息序列號(hào)生成實(shí)踐（算法原理篇）

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

[17]網(wǎng)易云信技術(shù)分享：IM中的萬人群聊技術(shù)方案實(shí)踐總結(jié)

[18]企業(yè)微信的IM架構(gòu)設(shè)計(jì)揭秘：消息模型、萬人群、已讀回執(zhí)、消息撤回等

[19]融云IM技術(shù)分享：萬人群聊消息投遞方案的思考和實(shí)踐

[20]為何基于TCP協(xié)議的移動(dòng)端IM仍然需要心跳?；顧C(jī)制？

[21]一文讀懂即時(shí)通訊應(yīng)用中的網(wǎng)絡(luò)心跳包機(jī)制：作用、原理、實(shí)現(xiàn)思路等

[22]微信團(tuán)隊(duì)原創(chuàng)分享：Android版微信后臺(tái)?；顚?shí)戰(zhàn)分享(網(wǎng)絡(luò)?；钇?

[23]融云技術(shù)分享：融云安卓端IM產(chǎn)品的網(wǎng)絡(luò)鏈路保活技術(shù)實(shí)踐

[24]阿里IM技術(shù)分享(九)：深度揭密RocketMQ在釘釘IM系統(tǒng)中的應(yīng)用實(shí)踐

[25]徹底搞懂TCP協(xié)議層的KeepAlive?；顧C(jī)制

[26]深度解密釘釘即時(shí)消息服務(wù)DTIM的技術(shù)設(shè)計(jì)

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