本文由公眾號(hào)“后臺(tái)技術(shù)匯”分享，原題“基于實(shí)踐，設(shè)計(jì)一個(gè)百萬級別的高可用 & 高可靠的 IM 消息系統(tǒng)”，原文鏈接在文末。由于原文存在較多錯(cuò)誤和不準(zhǔn)確內(nèi)容，有大量修訂和改動(dòng)。

1、引言

大家好，我是公眾號(hào)“后臺(tái)技術(shù)匯”的博主“一枚少年”。

本人從事后臺(tái)開發(fā)工作 3 年有余了，其中讓我感觸最深刻的一個(gè)項(xiàng)目，就是在兩年前從架構(gòu)師手上接過來的 IM 消息系統(tǒng)。

本文內(nèi)容將從開發(fā)者的視角出發(fā)（主要是我自已的開發(fā)體會(huì)），圍繞項(xiàng)目背景、業(yè)務(wù)需求、技術(shù)原理、開發(fā)方案等主題，一步一步的與大家一起剖析：設(shè)計(jì)一套百萬消息量的小規(guī)模IM系統(tǒng)架構(gòu)設(shè)計(jì)上需要注意的技術(shù)要點(diǎn)。

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

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

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

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK?

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

2、項(xiàng)目背景

我們仔細(xì)觀察就能發(fā)現(xiàn)，生活中的任何類型互聯(lián)網(wǎng)服務(wù)都有 IM 系統(tǒng)的存在。

比如：

• 1）基礎(chǔ)性服務(wù)類-騰訊新聞（評論消息）；

• 2）商務(wù)應(yīng)用類-釘釘（審批工作流通知）；

• 3）交流娛樂類-QQ/微信（私聊群聊 &討論組 &朋友圈）；

• 4）互聯(lián)網(wǎng)自媒體-抖音快手（點(diǎn)贊打賞通知）。

在這些林林總總的互聯(lián)網(wǎng)生態(tài)產(chǎn)品里，即時(shí)消息系統(tǒng)作為底層能力，在確保業(yè)務(wù)正常與用戶體驗(yàn)優(yōu)化上，始終扮演了至關(guān)重要的角色。

所以，現(xiàn)如今的互聯(lián)網(wǎng)產(chǎn)品中，即時(shí)通訊技術(shù)已經(jīng)不僅限于傳統(tǒng)IM聊天工具本身，它早已通過有形或無形的方式嵌入到了各種形式的互聯(lián)網(wǎng)應(yīng)用當(dāng)中。IM技術(shù)（或者說即時(shí)通訊技術(shù)）對于很多開發(fā)者來說，確實(shí)是必不好可少的領(lǐng)域知識(shí)，不可或缺。

3、系統(tǒng)能力

典型的IM系統(tǒng)通常需要滿足四點(diǎn)能力：高可靠性、高可用性、實(shí)時(shí)性和有序性。

?

這幾個(gè)概念我就不詳細(xì)展開，如果你是IM開發(fā)入門者，可以詳讀下面這幾篇：

• 《零基礎(chǔ)IM開發(fā)入門(一)：什么是IM系統(tǒng)？》

• 《零基礎(chǔ)IM開發(fā)入門(二)：什么是IM系統(tǒng)的實(shí)時(shí)性？》

• 《零基礎(chǔ)IM開發(fā)入門(三)：什么是IM系統(tǒng)的可靠性？》

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

4、架構(gòu)設(shè)計(jì)

以我的這個(gè)項(xiàng)目來說，架構(gòu)設(shè)設(shè)計(jì)要點(diǎn)主要是：

• 1）微服務(wù)：拆分為用戶微服務(wù) &消息連接服務(wù) &消息業(yè)務(wù)服務(wù)；

• 2）存儲(chǔ)架構(gòu)：兼容性能與資源開銷，選擇 reids&mysql；

• 3）高可用：可以支撐起高并發(fā)場景，選擇 Spring 提供的 websocket；

• 4）支持多端消息同步：app 端、web 端、微信公眾號(hào)、小程序消息；

• 5）支持在線與離線消息場景。

業(yè)務(wù)架構(gòu)圖主要是這樣：

技術(shù)模塊分層架構(gòu)大概是這樣：

5、消息存儲(chǔ)技術(shù)要點(diǎn)

5.1 理解讀擴(kuò)散和寫擴(kuò)散

5.1.1）基本概念：

我們舉個(gè)例子說明什么是讀擴(kuò)散，什么是寫擴(kuò)散：

一個(gè)群聊“相親相愛一家人”，成員：爸爸、媽媽、哥哥、姐姐和我（共 5 人）。

因?yàn)槟阕罱坏脚笥蚜耍园l(fā)了一條消息“我脫單了”到群里面，那么自然希望爸爸媽媽哥哥姐姐四個(gè)親人都能收到了。

正常邏輯下，群聊消息發(fā)送的流程應(yīng)該是這樣：

• 1）遍歷群聊的成員并發(fā)送消息；

• 2）查詢每個(gè)成員的在線狀態(tài)；

• 3）成員不在線的存儲(chǔ)離線；

• 4）成員在線的實(shí)時(shí)推送。

數(shù)據(jù)分發(fā)模型如下：

問題在于：如果第4步發(fā)生異常，群友會(huì)丟失消息，那么會(huì)導(dǎo)致有家人不知道“你脫單了”，造成催婚的嚴(yán)重后果。

所以優(yōu)化的方案是：不管群員是否在線，都要先存儲(chǔ)消息。

按照上面的思路，優(yōu)化后的群消息流程如下：

• 1）遍歷群聊的成員并發(fā)送消息；

• 2）群聊所有人都存一份；

• 3）查詢每個(gè)成員的在線狀態(tài)；

• 4）在線的實(shí)時(shí)推送。

以上優(yōu)化后的方案，便是所謂的“寫擴(kuò)散”了。

問題在于：每個(gè)人都存一份相同的“你脫單了”的消息，對磁盤和帶寬造成了很大的浪費(fèi)（這就是寫擴(kuò)散的最大弊端）。

所以優(yōu)化的方案是：群消息實(shí)體存儲(chǔ)一份，用戶只存消息 ID 索引。

于是再次優(yōu)化后的發(fā)送群消息流程如下：

• 1）遍歷群聊的成員并發(fā)送消息；

• 2）先存一份消息實(shí)體；

• 3）然后群聊所有人都存一份消息實(shí)體的 ID 引用；

• 4）查詢每個(gè)成員的在線狀態(tài)；

• 5）在線的實(shí)時(shí)推送。

二次優(yōu)化后的方案，便是所謂的“讀擴(kuò)散”了。

5.1.2）小結(jié)一下：

• 1）讀擴(kuò)散：讀取操作很重，寫入操作很輕，資源消耗相對小一些；

• 2）寫擴(kuò)散：讀取操作很輕，寫入操作很重，資源消耗相對大一些。

從公開的技術(shù)資料來看，微信和釘釘?shù)娜毫南?yīng)該使用的是寫擴(kuò)散方式，具體可以參看這兩篇：《微信后臺(tái)團(tuán)隊(duì)：微信后臺(tái)異步消息隊(duì)列的優(yōu)化升級實(shí)踐分享》、《阿里IM技術(shù)分享(四)：閑魚億級IM消息系統(tǒng)的可靠投遞優(yōu)化實(shí)踐》（注意“5.5 服務(wù)端存儲(chǔ)模型優(yōu)化”這一節(jié)）。

5.2 “消息”所關(guān)聯(lián)的對象

5.2.1）消息實(shí)體模型：

常見的消息業(yè)務(wù)，可以抽象為幾個(gè)實(shí)體模型概念：用戶/用戶關(guān)系/用戶設(shè)備/用戶連接狀態(tài)/消息/消息隊(duì)列。

在IM系統(tǒng)中的實(shí)體模型關(guān)系大致如下：

5.2.2）實(shí)體模型概念解釋：

用戶實(shí)體：

• 1）用戶->用戶終端設(shè)備：每個(gè)用戶能夠多端登錄并收發(fā)消息；

• 2）用戶->消息：考慮到讀擴(kuò)散，每個(gè)用戶與消息的關(guān)系都是 1：n；

• 3）用戶->消息隊(duì)列：考慮到讀擴(kuò)散，每個(gè)用戶都會(huì)維護(hù)自己的一份“消息列表”（1:1），如果考慮到擴(kuò)容，甚至可以開辟一份消息溢出列表接收超出“消息列表”容量的消息數(shù)據(jù)（此時(shí)是 1：n）；

• 4）用戶->用戶連接狀態(tài)：考慮到用戶能夠多端登錄，那么 app/web 都會(huì)有對應(yīng)的在線狀態(tài)信息（1：n）；

• 5）用戶->聯(lián)系人關(guān)系：考慮到用戶最終以某種業(yè)務(wù)聯(lián)系到一起，組成多份聯(lián)系人關(guān)系，最終形成私聊或者群聊（1：n）；

聯(lián)系人關(guān)系（主要由業(yè)務(wù)決定用戶與用戶之間的關(guān)系），比如說：

• 1）某個(gè)家庭下有多少人，這個(gè)家庭群聊就有多少人；

• 2）在 ToB 場景，在釘釘企業(yè)版里，我們往往有企業(yè)群聊這個(gè)存在。

消息實(shí)體：

消息->消息隊(duì)列：考慮到讀擴(kuò)散，消息最終歸屬于一個(gè)或多個(gè)消息隊(duì)列里，因此群聊場景它會(huì)分布在不同的消息隊(duì)列里。

消息隊(duì)列實(shí)體：

消息隊(duì)列：確切說是消息引用隊(duì)列，它里面的索引元素最終指向具體的消息實(shí)體對象。

用戶連接狀態(tài)：

• 1）對于 app 端：網(wǎng)絡(luò)原因?qū)е聰嗑€，或者用戶手動(dòng) kill 掉應(yīng)用進(jìn)程，都屬于離線；

• 2）對于 web 端：網(wǎng)絡(luò)原因?qū)е聻g覽器斷網(wǎng)，或者用戶手動(dòng)關(guān)閉標(biāo)簽頁，都屬于離線；

• 3）對于公眾號(hào)：無法分別離線在線；

• 4）對于小程序：無法分別離線在線。

用戶終端設(shè)備：

客戶端一般是 Android&IOS，web 端一般是瀏覽器，還有其他靈活的 WebView（公眾號(hào)/小程序）。

5.3 消息的存儲(chǔ)方案

對于消息存儲(chǔ)方案，本質(zhì)上只有三種方案：要么放在內(nèi)存、要么放在磁盤、要么兩者結(jié)合存儲(chǔ)（據(jù)說大公司為了優(yōu)化性能，活躍的消息數(shù)據(jù)都是放在內(nèi)存里面的，畢竟有錢~）。

下面分別解析主要方案的優(yōu)點(diǎn)與弊端：

• 1）方案一：考慮性能，數(shù)據(jù)全部放到 redis 進(jìn)行存儲(chǔ)；

• 2）方案二：考慮資源，數(shù)據(jù)用 redis + mysql 進(jìn)行存儲(chǔ)。

5.3.1）對于方案一：redis

前提：用戶 & 聯(lián)系人關(guān)系，由于是業(yè)務(wù)數(shù)據(jù)，因此統(tǒng)一默認(rèn)使用關(guān)系型數(shù)據(jù)庫存儲(chǔ)。

流程圖：

解釋如下：

• 1）用戶發(fā)消息；

• 2）redis 創(chuàng)建一條實(shí)體數(shù)據(jù) &一個(gè)實(shí)體數(shù)據(jù)計(jì)時(shí)器；

• 3）redis 在 B 用戶的用戶隊(duì)列 添加實(shí)體數(shù)據(jù)引用；

• 4）B 用戶拉取消息（后續(xù) 5.2 會(huì)提及拉模式）。

實(shí)現(xiàn)方案：

• 1）用戶隊(duì)列，zset（score 確保有序性）；

• 2）消息實(shí)體列表，hash（msg_id 確保唯一性）；

• 3）消息實(shí)體計(jì)數(shù)器，hash（支持群聊消息的引用次數(shù)，倒計(jì)時(shí)到零時(shí)則刪除實(shí)體列表的對應(yīng)消息，以節(jié)省資源）。

優(yōu)點(diǎn)是：內(nèi)存操作，響應(yīng)性能好

弊端是：

• 1）內(nèi)存消耗巨大，eg：除非大廠，小公司的服務(wù)器的寶貴內(nèi)存資源是耗不起業(yè)務(wù)的，隨著業(yè)務(wù)增長，不想拓展資源，就需要手動(dòng)清理數(shù)據(jù)了；

• 2）受 redis 容災(zāi)性策略影響較大，如果 redis 宕機(jī)，直接導(dǎo)致數(shù)據(jù)丟失（可以使用 redis 的集群部署/哨兵機(jī)制/主從復(fù)制等手段解決）。

5.3.2）方案二：redis+mysql

前提：用戶 & 聯(lián)系人關(guān)系，由于是業(yè)務(wù)數(shù)據(jù)，因此統(tǒng)一默認(rèn)使用關(guān)系型數(shù)據(jù)庫存儲(chǔ)。

流程圖：

解釋如下：

• 1）用戶發(fā)消息；

• 2）mysql 創(chuàng)建一條實(shí)體數(shù)據(jù)；

• 3）redis 在 B 用戶的用戶隊(duì)列 添加實(shí)體數(shù)據(jù)引用；

• 4）B 用戶拉取消息（下文會(huì)提及拉模式）。

實(shí)現(xiàn)方案：

• 1）用戶隊(duì)列，zset（score 確保有序性）；

• 2）消息實(shí)體列表，轉(zhuǎn)移到 mysql（表主鍵 id 確保唯一性）；

• 3）消息實(shí)體計(jì)數(shù)器，hash（刪除這個(gè)概念，因?yàn)榇疟P可用總資源遠(yuǎn)遠(yuǎn)高于內(nèi)存總資源，哪怕一直存放 mysql 數(shù)據(jù)庫，在業(yè)務(wù)量百萬級別時(shí)也不會(huì)有大問題，如果是巨大體量業(yè)務(wù)就需要考慮分表分庫處理檢索數(shù)據(jù)的性能了）。

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

• 1）抽離了數(shù)據(jù)量最大的消息實(shí)體，大大節(jié)省了內(nèi)存資源；

• 2）磁盤資源易于拓展 ，便宜實(shí)用。

弊端是：磁盤讀取操作，響應(yīng)性能較差（從產(chǎn)品設(shè)計(jì)的角度出發(fā)，你維護(hù)的這套 IM 系統(tǒng)究竟是強(qiáng) IM 還是弱 IM）。

6、消息的消費(fèi)模式

6.1 拉模式

選用消息拉模式的原因：

• 1）由于用戶數(shù)量太多（觀察者），服務(wù)器無法一一監(jiān)控客戶端的狀態(tài)，因此消息模塊的數(shù)據(jù)交互使用拉模式，可以節(jié)約服務(wù)器資源；

• 2）當(dāng)用戶有未讀消息時(shí)，由客戶器主動(dòng)發(fā)起請求的方式，可以及時(shí)刷新客戶端狀態(tài)。

6.2 ack 機(jī)制

技術(shù)原理：

• 1）基于拉模式實(shí)現(xiàn)的數(shù)據(jù)拉取請求（第一次 fetch 接口）與數(shù)據(jù)拉取確認(rèn)請求（第二次 fetch 接口）是成對出現(xiàn)的；

• 2）客戶端二次調(diào)用 fetch 接口，需要將上次消息消費(fèi)的錨點(diǎn)告訴服務(wù)端，服務(wù)器進(jìn)而刪除已讀消息。

請求模型原理圖如下：

實(shí)現(xiàn)方案1：基于每一條消息編號(hào) ACK：

• 1）實(shí)現(xiàn)：客戶端在接收到消息之后，發(fā)送 ACK 消息編號(hào)給服務(wù)端，告知已經(jīng)收到該消息。服務(wù)端在收到 ACK 消息編號(hào)的時(shí)候，標(biāo)記該消息已經(jīng)發(fā)送成功；

• 2）弊端：這種方案，因?yàn)榭蛻舳酥饤l ACK 消息編號(hào)，所以會(huì)導(dǎo)致客戶端和服務(wù)端交互次數(shù)過多。當(dāng)然，客戶端可以異步批量 ACK 多條消息，從而減少次數(shù)。

實(shí)現(xiàn)方案2：基于滑動(dòng)窗口 ACK：

1）客戶端在接收到消息編號(hào)之后，和本地的消息編號(hào)進(jìn)行比對：

?- 如果比本地的小，說明該消息已經(jīng)收到，忽略不處理；

?- 如果比本地的大，使用本地的消息編號(hào)，向服務(wù)端拉取大于本地的消息編號(hào)的消息列表，即增量消息列表。

?- 拉取完成后，更新消息列表中最大的消息編號(hào)為新的本地的消息編號(hào)；

2）服務(wù)端在收到 ack 消息時(shí)，進(jìn)行批量標(biāo)記已讀或者刪除。

這種方式，在業(yè)務(wù)被稱為推拉結(jié)合的方案，在分布式消息隊(duì)列、配置中心、注冊中心實(shí)現(xiàn)實(shí)時(shí)的數(shù)據(jù)同步，經(jīng)常被采用。

6.3 基于ack 機(jī)制的好處

第一次獲取消息完成之后，如果沒有 ack 機(jī)制，流程是：

• 1）服務(wù)器刪除已讀消息數(shù)據(jù)；

• 2）服務(wù)端把數(shù)據(jù)包響應(yīng)給客戶端。

如果由于網(wǎng)絡(luò)延遲，導(dǎo)致客戶端長時(shí)間取不到數(shù)據(jù)，這時(shí)客戶端會(huì)斷開該次 HTTP 請求，進(jìn)而忽略這次響應(yīng)數(shù)據(jù)的處理，最終導(dǎo)致消息數(shù)據(jù)被刪除而后續(xù)無法恢復(fù)。

有了 ack 機(jī)制，哪怕第一次獲取消息失敗，客戶端還是可以繼續(xù)請求消息數(shù)據(jù)，因?yàn)樵?ack 確認(rèn)之前，消息數(shù)據(jù)都不會(huì)刪除掉。

7、微服務(wù)設(shè)計(jì)

一般來說 IM 微服務(wù)，能拆分為基礎(chǔ)的三個(gè)微服務(wù)：

• 1）用戶服務(wù)；

• 2）業(yè)務(wù)服務(wù)；

• 3）連接管理服務(wù)。

參考架構(gòu)圖：

他們分工合作如下。

用戶微服務(wù)（用戶設(shè)備的登錄 & 登出）：

• 1）設(shè)備號(hào)存庫；

• 2）連接狀態(tài)更新；

• 3）其他登錄端用戶踢出等。

連接管理微服務(wù)：

• 1）狀態(tài)保存：保存用戶設(shè)備長連接對象；

• 2）剔除無效連接：輪訓(xùn)已有長連接對象狀態(tài)，超時(shí)刪除對象；

• 3）接受客戶端的心跳包：刷新長連接對象的狀態(tài)。

消息業(yè)務(wù)微服務(wù)：

• 1）消息存儲(chǔ)：進(jìn)行私聊/群聊的消息存儲(chǔ)策略（請參看“消息存儲(chǔ)模型”一節(jié)）；

• 2）消息消費(fèi)：進(jìn)行消息獲取響應(yīng)與 ack 確認(rèn)刪除（請參看“消息消費(fèi)模式”一節(jié)）；

• 3）消息路由：用戶在線時(shí)，路由消息通知包到“消息連接管理微服務(wù)”，以通知用戶客戶端來取消息。

最后提一下消息的路由：

微服務(wù)之間也有通信手段，比如業(yè)務(wù)服務(wù)到連接管理服務(wù)，兩者之間可以通過 RPC 實(shí)現(xiàn)實(shí)時(shí)消息的路由通知。

8、離線消息推送

離線推送方案上，大家一般都會(huì)考慮采用兩種方案：

• 1）企業(yè)自研后臺(tái)離線 PUSH 系統(tǒng)；

• 2）企業(yè)自行對接第三方手機(jī)廠商 PUSH 系統(tǒng)。

8.1 企業(yè)自研后臺(tái)離線 PUSH 系統(tǒng)

技術(shù)原理：

在應(yīng)用級別，客戶端與后臺(tái)離線 PUSH 系統(tǒng)保持長連接，當(dāng)用戶狀態(tài)被檢測為離線時(shí)，通過這個(gè)長連接告知客戶端“有新消息”，進(jìn)而喚醒手機(jī)彈窗標(biāo)題。

弊端就是：

隨著安卓和蘋果系統(tǒng)的限制越來越嚴(yán)格，一般客戶端的活動(dòng)周期被限制的死死的，一旦客戶端進(jìn)程被挪到后臺(tái)就立馬被 kill 掉了，導(dǎo)致客戶端?；钐貏e難做好（這也是很多中小企業(yè)頭疼的地方，畢竟只有微信或者 QQ 這種體量的一級市場 app，手機(jī)系統(tǒng)愿意給他們留后門來做?；睿＞唧w可以讀一下《Android P正式版即將到來：后臺(tái)應(yīng)用?；?、消息推送的真正噩夢》這篇。

8.2 企業(yè)自行對接第三方廠商 PUSH 系統(tǒng)

技術(shù)原理：

在系統(tǒng)級別，每個(gè)硬件系統(tǒng)都會(huì)與對應(yīng)的手機(jī)廠商保持長連接，當(dāng)用戶狀態(tài)被檢測為離線時(shí)，后臺(tái)將推送報(bào)文通過 HTTP 請求，告知第三方手機(jī)廠商服務(wù)器，進(jìn)而通過系統(tǒng)喚醒 app 的彈窗標(biāo)題。

弊端就是：

• 1）作為應(yīng)用端，消息是否確切送達(dá)給用戶側(cè)，是未知的；推送的穩(wěn)定性也取決于第三方手機(jī)廠商的服務(wù)穩(wěn)定性；

• 2）額外進(jìn)行 sdk 的對接工作，增加了工作量；

• 3）第三方廠商隨時(shí)可能升級 sdk 版本，導(dǎo)致沒有升級 sdk 的服務(wù)器出現(xiàn)推送失敗的情況，給 Sass 系統(tǒng)部署帶來困難；

• 4）推送證書配置也要考慮到維護(hù)成本。

總之，IM里離線消息推送是個(gè)很頭疼的問題（當(dāng)然這里主要說是Andriod了，iOS里蘋果官方的APNs就舒服多了），有興趣好一讀一下下面這些文章：

1. 《全面盤點(diǎn)當(dāng)前Android后臺(tái)?；罘桨傅恼鎸?shí)運(yùn)行效果（截止2019年前）》

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

3. 《2020年了，Android后臺(tái)保活還有戲嗎？看我如何優(yōu)雅的實(shí)現(xiàn)！》

4. 《史上最強(qiáng)Android?；钏悸罚荷钊肫饰鲵v訊TIM的進(jìn)程永生技術(shù)》

5. 《Android進(jìn)程永生技術(shù)終極揭密：進(jìn)程被殺底層原理、app應(yīng)對被殺技巧》

6. 《Android?；顝娜腴T到放棄：乖乖引導(dǎo)用戶加白名單吧(附7大機(jī)型加白示例)》

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

9、其它需要考慮的技術(shù)要點(diǎn)

9.1 安全性

關(guān)于IM安全性，我個(gè)人的體會(huì)是這樣：

• 1）業(yè)務(wù)數(shù)據(jù)傳輸安全性使用 https 訪問；

• 2）實(shí)時(shí)消息使用SSL/TLS對長連接進(jìn)行加密；

• 3）使用私有協(xié)議，不容易解析；

• 4）內(nèi)容安全性端到端加密，中間任何環(huán)節(jié)都不能解密（即發(fā)送和接收端交換互相的密鑰來解密，服務(wù)器端解密不了）；

• 5）服務(wù)器端不存儲(chǔ)消息。

以上要點(diǎn)中：IM中的長連接安全性是比較重要且不容易處理的，因?yàn)樗枰诎踩院托阅苌献髌胶夂腿∩幔ú荒芄忸欀踩鴵p失IM長連接的高吞吐性能），這方面可以參考微信團(tuán)隊(duì)分享的這篇《微信新一代通信安全解決方案：基于TLS1.3的MMTLS詳解》。

另外：更高安全性的場景可以考慮組合加密方案，詳情可以參考《探討組合加密算法在IM中的應(yīng)用》。

9.2 一致性

IM消息一致性難題，主要是保證消息不亂序的問題。這個(gè)話題，初學(xué)者可以讀讀這篇《零基礎(chǔ)IM開發(fā)入門(四)：什么是IM系統(tǒng)的消息時(shí)序一致性？》，我就不再贅述了。

解決一致性問題的切入點(diǎn)有很多，最常見的是使用有序的消息唯一id，關(guān)于有序且唯一的ID生成問題，微信團(tuán)隊(duì)的思路就很好，可以借鑒一下《微信技術(shù)分享：微信的海量IM聊天消息序列號(hào)生成實(shí)踐（算法原理篇）》。

另外，以下幾篇關(guān)于消息有序性問題的總結(jié)也非常好，可以進(jìn)行參考：

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

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

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

9.3 可靠性

IM里所謂的可靠性，說直白一點(diǎn)就是保證消息不丟失，這看似理所當(dāng)然、稀松平常的技術(shù)點(diǎn)，在IM系統(tǒng)中又是另一個(gè)很大的話題，鑒于本人水平有限，就不班門弄斧，IM初學(xué)者可以能過《零基礎(chǔ)IM開發(fā)入門(三)：什么是IM系統(tǒng)的可靠性？》這篇來理解可靠性這個(gè)概念。

然后再讀讀《IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(一)：保證在線實(shí)時(shí)消息的可靠投遞》、《IM消息送達(dá)保證機(jī)制實(shí)現(xiàn)(二)：保證離線消息的可靠投遞》這兩篇，基本上就能對IM可靠性這個(gè)技術(shù)要點(diǎn)有了比較深刻的認(rèn)識(shí)了。

下面這幾篇實(shí)戰(zhàn)性的總結(jié)，適合有一定IM經(jīng)驗(yàn)的同行們學(xué)習(xí)，可以借鑒學(xué)習(xí)一下：

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

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

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

4. 《阿里IM技術(shù)分享(四)：閑魚億級IM消息系統(tǒng)的可靠投遞優(yōu)化實(shí)踐》

9.4 實(shí)時(shí)性

IM實(shí)時(shí)性這個(gè)技術(shù)點(diǎn)，就回歸到了“即時(shí)通訊”這個(gè)技術(shù)的立身之本了，可以說，沒有實(shí)時(shí)性，也就不存在“即時(shí)通訊”這個(gè)技術(shù)范疇了，可以見它的重要性。關(guān)于實(shí)時(shí)性這個(gè)概念，初學(xué)者可以通過《零基礎(chǔ)IM開發(fā)入門(二)：什么是IM系統(tǒng)的實(shí)時(shí)性？》這篇去學(xué)習(xí)一下，我就不啰嗦了，人家比我說的好。

筆者公司的項(xiàng)目里實(shí)時(shí)通信用方案都是采用 WebSocket（如果你不了解WebSocket，可以讀一下《WebSocket從入門到精通，半小時(shí)就夠！》，以及《搞懂現(xiàn)代Web端即時(shí)通訊技術(shù)一文就夠：WebSocket、socket.io、SSE》），但是某些低版本的瀏覽器可能不支持 WebSocket，所以實(shí)際開發(fā)時(shí)，要兼容前端所能提供的能力進(jìn)行方案設(shè)計(jì)。

以下兩篇關(guān)于實(shí)時(shí)性的同行實(shí)踐性總結(jié)也不錯(cuò)：

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

2. 《阿里IM技術(shù)分享(五)：閑魚億級IM消息系統(tǒng)的及時(shí)性優(yōu)化實(shí)踐》

10、我在項(xiàng)目實(shí)踐中的體會(huì)

作為研發(fā)者，有兩年多的時(shí)間都在維護(hù)迭代公司的 IM 消息系統(tǒng)，以下是我自已的小小體會(huì)。

我體會(huì)到的重點(diǎn)難點(diǎn)有以下幾方面：

• 1）業(yè)務(wù)閉環(huán)：消息是如何寫入存儲(chǔ)、消息是如何消費(fèi)掉、在線消息是如何實(shí)現(xiàn)、離線消息是如何實(shí)現(xiàn)、群聊/私聊有何不一樣、多端消息如何實(shí)現(xiàn)；

• 2）解 Bug 填坑：在線消息收不到，第三方推送證書如何配置；

• 3）代碼優(yōu)化：單體架構(gòu)拆分微服務(wù)；

• 4）存儲(chǔ)優(yōu)化：1.0 版本的 redis 存儲(chǔ)到 2.0 版本的 redis+mysql；

• 5）性能優(yōu)化：未讀提醒等接口性能優(yōu)化。

項(xiàng)目還存在可優(yōu)化的地方：

• 1）高可用方案之一：是部署多部連接管理服務(wù)器，以支撐更多的用戶連接；

• 2）高可用方案之二：是對單部連接管理服務(wù)，使用 Netty 進(jìn)行框架層優(yōu)化，讓一個(gè)服務(wù)器支撐更多的用戶連接；

• 3）消息量劇增時(shí)：可以考慮對消息存儲(chǔ)作進(jìn)一步優(yōu)化；

• 4）消息冷熱部署：不同的地區(qū)會(huì)存在業(yè)務(wù)量差異，比如在某些經(jīng)濟(jì)發(fā)達(dá)的省份，IM 系統(tǒng)面臨的壓力會(huì)比較大，一些欠發(fā)達(dá)省份，服務(wù)壓力會(huì)低一點(diǎn)，所以這塊可以考慮數(shù)據(jù)的冷熱部署。

11、寫在最后

兩年前從架構(gòu)師手上接過來的 IM 消息系統(tǒng)模塊，讓我逐步培養(yǎng)了架構(gòu)思維，見賢思齊，感謝恩師。

IM技術(shù)是個(gè)經(jīng)久不衰的領(lǐng)域，但同時(shí)可直接使用的技術(shù)資產(chǎn)也非常匱乏，必竟傳統(tǒng)的IM巨頭們的產(chǎn)品通常都是私有化協(xié)議、私有化方案，很難有業(yè)界共同的方案可以直接使用（包括資料或開源代碼），正是這種不通用、不準(zhǔn)，間接導(dǎo)致IM技術(shù)門檻的提高。所以通常公司要搞IM的話，如果沒有技術(shù)積累，就只能從零開始造輪子。

為了改變這種局面，也希望搞IM開發(fā)的同學(xué)不要悶頭造車，應(yīng)該多多借鑒同行的思路，同時(shí)也能積極分享自已的經(jīng)驗(yàn)，讓IM開發(fā)不再痛苦。

以上拋磚引玉，歡迎留言討論，一起進(jìn)步。

12、參考資料

[1]?新手入門一篇就夠：從零開發(fā)移動(dòng)端IM

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

[3]?Android P正式版即將到來：后臺(tái)應(yīng)用?；睢⑾⑼扑偷恼嬲瑝?/p>

[4]?WebSocket從入門到精通，半小時(shí)就夠！

[5]?搞懂現(xiàn)代Web端即時(shí)通訊技術(shù)一文就夠：WebSocket、socket.io、SSE

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

[7]?一套原創(chuàng)分布式即時(shí)通訊(IM)系統(tǒng)理論架構(gòu)方案

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

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

[10]?阿里IM技術(shù)分享(四)：閑魚億級IM消息系統(tǒng)的可靠投遞優(yōu)化實(shí)踐

[11]?阿里IM技術(shù)分享(五)：閑魚億級IM消息系統(tǒng)的及時(shí)性優(yōu)化實(shí)踐

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

[13]?從新手到專家：如何設(shè)計(jì)一套億級消息量的分布式IM系統(tǒng)

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

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

[16]?即時(shí)通訊安全篇（六）：非對稱加密技術(shù)的原理與應(yīng)用實(shí)踐

[17]?通俗易懂：一篇掌握即時(shí)通訊的消息傳輸安全原理

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

[19]?零基礎(chǔ)IM開發(fā)入門(二)：什么是IM系統(tǒng)的實(shí)時(shí)性？

[20]?零基礎(chǔ)IM開發(fā)入門(三)：什么是IM系統(tǒng)的可靠性？

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

本文已同步發(fā)布于“即時(shí)通訊技術(shù)圈”公眾號(hào)。

同步發(fā)布鏈接是：http://www.52im.net/thread-3752-1-1.html