單聊

在眾多的軟件中，聊天功能是不可或缺的一個(gè)功能模塊，或是用戶和用戶，或是用戶和客服，都需要一個(gè)能夠即時(shí)溝通的功能。

那么一個(gè)IM（InstantMessaging）的1對(duì)1聊天系統(tǒng)架構(gòu)和存儲(chǔ)應(yīng)該如何設(shè)計(jì)呢。

下面來一步步的分析規(guī)劃。

一. 功能點(diǎn)拆分

首先來看一個(gè)IM軟件模塊包括哪些基本功能

• 會(huì)話列表（需要按照最后一條消息時(shí)間的倒序，將會(huì)話進(jìn)行排列）
• 聊天內(nèi)容頁（單聊雙方的消息按時(shí)間順序依次排列）
• 未讀消息計(jì)數(shù)（發(fā)送了但是沒有讀取的對(duì)話，需要在頭像旁顯示未讀數(shù)字）
• 用戶頭像，昵稱（對(duì)話的用戶資料）

根據(jù)上述功能點(diǎn)拆分后，可以確定下來需要哪些數(shù)據(jù)存儲(chǔ)

• 會(huì)話列表
• 聊天的消息記錄
• 離線消息列表
• 未讀消息數(shù)據(jù)數(shù)量
• 用戶資料

二. 數(shù)據(jù)結(jié)構(gòu)

實(shí)際進(jìn)行下面幾種數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)時(shí)，可使用適合自己的場(chǎng)景的組件，例如公司自研的，或熟悉并滿足場(chǎng)景要求的。

以下我拿redis或mysql來舉例子，提供一個(gè)思路，實(shí)際生產(chǎn)環(huán)境還需要具體設(shè)計(jì)和選型

1. 會(huì)話列表

首先，需要為每一個(gè)會(huì)話創(chuàng)建一個(gè)會(huì)話Id進(jìn)行標(biāo)識(shí)。

再來看，會(huì)話列表的特性是新來消息的會(huì)話需要排在列表的上面，那么就可以使用一個(gè)有序集合SortedSet來存儲(chǔ)。

結(jié)構(gòu)如下：

key: prefix_xxx:{uid}value: {會(huì)話Id}score: {msgId}

key使用當(dāng)前用戶的uid來標(biāo)識(shí)，集合中的每個(gè)item則是會(huì)話的Id，item的score為會(huì)話的最后一條消息的Id，這樣根據(jù)score自動(dòng)形成一個(gè)有序集合后，就能夠滿足我們的應(yīng)用場(chǎng)景了。

2. 單聊消息列表

場(chǎng)景：聊天的消息列表，是一個(gè)按照時(shí)間順序來排列的消息記錄，并且需要可以根據(jù)offset來進(jìn)行數(shù)據(jù)拉取。

同樣可以使用redis的有序集合SortedSet來存儲(chǔ)會(huì)話的消息列表，通過scan拉取消息

key: prefix_session_list:{sessionId}value: {msgId}score: {msgId}

也可以創(chuàng)建一個(gè)Mysql數(shù)據(jù)表來持久化存儲(chǔ)消息記錄

createtablet_msg_record_list(
`id`bigintnotnullprimarykey,
`sessionId`bigintnotnullcomment'會(huì)話Id',
`msgId`bigintnotnullcomment'消息Id',
`isRead`tinyintnotnulldefault0commment'已讀狀態(tài)',
`recordStatus`smallintnotnulldefault0commment'消息狀態(tài)',
`createTime`datetimenotnull,
key`sessionId`(`sessionId`)
)engine=innodb;

根據(jù)會(huì)話Id分頁查詢時(shí)，就可以這樣查詢出所有msgId，再根據(jù)msgId去拉取msg的詳情，組合成列表返回給客戶端

SELECTmsgIdFROMt_msg_record_listWHEREsessionId=1ANDrecordStatus=0ANDmsgId>1ORDERBYiddescLIMIT10;

3. 離線消息

離線消息可以分為「索引」和「消息id列表」兩部分

離線消息索引需要記錄的是，哪些用戶給當(dāng)前用戶發(fā)送了離線消息，所以我們可以使用redis的集合Set來記錄這些信息

key: prefix_xxx:{uid}value: {senderUid}

通過scan離線消息索引拿到了sendUid，再去拿這個(gè)會(huì)話的具體的離線消息id列表

然后，消息id列表使用redis的一個(gè)list鏈表來存儲(chǔ)

key{uid}:{senderUid}value:{msgId}

拿到所有msgId以后，去獲取msg的實(shí)體詳情填充即可

4. 未讀計(jì)數(shù)

未讀計(jì)數(shù)= 收到消息總數(shù) - 已讀數(shù)量

所以我們要存儲(chǔ)兩個(gè)已知數(shù)據(jù)便于計(jì)算出未讀數(shù)量，即消息總數(shù)量和已讀數(shù)量

由于對(duì)話存在雙方發(fā)消息，所以分別維護(hù)對(duì)話雙方的兩個(gè)數(shù)據(jù)項(xiàng)，方便計(jì)算各自的未讀數(shù)

接受消息總數(shù)量

key: prefix_session_count:{會(huì)話Id}:{uid}value: 總數(shù)量

已讀數(shù)量

key: prefix_session_read_count:{會(huì)話Id}:{uid}value: 已讀數(shù)量

5. 用戶資料

使用mysql按需設(shè)計(jì)即可，變更保存后將數(shù)據(jù)同步到redis中使用

三. 架構(gòu)層級(jí)拆分

如圖所示，我們可以將架構(gòu)大致分為五層，具體說明如下

1. 客戶端層

我們IM服務(wù)的client肯定是有多個(gè)，web/app等，需要封裝多種SDK隱藏底層細(xì)節(jié)，便于接入方接入。

2. 連接層

即時(shí)通訊需要客戶端和服務(wù)端之間建立一個(gè)長(zhǎng)鏈接，一方面維護(hù)用戶的在線狀態(tài)，另一方面便于復(fù)用連接進(jìn)行消息的收發(fā)。

而維護(hù)連接這個(gè)動(dòng)作，它的獨(dú)立性很強(qiáng)，不需要與業(yè)務(wù)邏輯耦合，所以我們把鏈接層單獨(dú)拆分出來一個(gè)。

這樣在業(yè)務(wù)邏輯迭代上線時(shí)，業(yè)務(wù)層進(jìn)行滾動(dòng)上線也不會(huì)導(dǎo)致用戶的鏈接斷開。

連接協(xié)議

至于連接協(xié)議的選擇，有如下幾種方式

1. 基于tcp鏈接，自定義傳輸協(xié)議（開發(fā)成本高，需要有一定條件）
2. websocket
3. http chunk （不建議使用，http工作在7層上，且只能服務(wù)端單向的向客戶端傳輸數(shù)據(jù)，心跳連接不好維護(hù)）

這里推薦優(yōu)先使用四層的協(xié)議來進(jìn)行長(zhǎng)鏈接的維護(hù)。

因?yàn)殚L(zhǎng)鏈接集群的前方要做負(fù)載均衡，使用七層的協(xié)議，客戶端要先和負(fù)載均衡機(jī)器建立鏈接，然后負(fù)載均衡機(jī)器再和業(yè)務(wù)層集群交互。

這樣在連接數(shù)很大的時(shí)候，負(fù)載均衡的機(jī)器容易成為瓶頸。四層的負(fù)載均衡可以直接通過修改目標(biāo)機(jī)器ip prot的方式來進(jìn)行轉(zhuǎn)發(fā)，不需要client和負(fù)載均衡機(jī)器建鏈接

3. 業(yè)務(wù)層

業(yè)務(wù)層可以分為「長(zhǎng)鏈接業(yè)務(wù)層 」和「短鏈接業(yè)務(wù)層 」

具體兩者的功能拆分，可根據(jù)業(yè)務(wù)實(shí)際情況設(shè)計(jì)

• 長(zhǎng)鏈接業(yè)務(wù)層: 負(fù)責(zé)會(huì)話相關(guān)的業(yè)務(wù)邏輯，比如收發(fā)消息/拉取會(huì)話列表/未讀計(jì)數(shù)push等業(yè)務(wù)
• 短鏈接業(yè)務(wù)層: 負(fù)責(zé)一些臨時(shí)接口請(qǐng)求，比如用戶資料拉取/資料變更等類似業(yè)務(wù)

兩種業(yè)務(wù)層都通過調(diào)用服務(wù)層來進(jìn)行數(shù)據(jù)讀取和寫入等擦歐總

4. 服務(wù)層

這層屬于微服務(wù)，來為上層業(yè)務(wù)層提供基礎(chǔ)服務(wù)能力，例如敏感消息過濾/會(huì)話列表數(shù)據(jù)讀寫/消息的落地和發(fā)送等功能。

5. 數(shù)據(jù)層

為上層的服務(wù)層來提供數(shù)據(jù)的實(shí)際落地寫入，可以使用mysql，redis或其他sql/nosql數(shù)據(jù)庫。

四. 推拉模式選擇

那么在消息的發(fā)送上，我們應(yīng)該選用推模式，還是拉模式，抑或是推拉結(jié)合呢？

1. 純推模式

首先，我們假設(shè)使用純推模式 ，來看會(huì)存在什么樣的問題

場(chǎng)景1: 新設(shè)備登陸初始化

用戶新登陸一臺(tái)設(shè)備的時(shí)候，如果消息記錄全都是空的，體驗(yàn)會(huì)很不好。

那么就需要服務(wù)端推送全量 的消息記錄到客戶端，歷史消息量大的時(shí)候，非常浪費(fèi)服務(wù)端資源和帶寬。

場(chǎng)景2: 設(shè)備間切換

tips：設(shè)備A和B都非第一次登陸

如圖所示，流程如下

1. 用戶1在設(shè)備A上登陸，收到了用戶2的消息1和2，push到了設(shè)備A上。
2. 用戶1退出了設(shè)備A，用戶2又給他發(fā)送了消息3和4
3. 用戶1登陸了設(shè)備B，服務(wù)端push消息3和4到了設(shè)備B

但是此時(shí)，設(shè)備B缺少了消息1和2，用戶再登陸回設(shè)備A的話又缺少了消息3和4，這也就產(chǎn)生了「消息空洞 」

2. 純拉模式

然后，我們假設(shè)使用純拉模式 ，來看會(huì)存在哪些問題

場(chǎng)景1: 收新消息

純拉模式下，客戶端需要和服務(wù)端進(jìn)行一個(gè)長(zhǎng)輪詢，來定時(shí)檢查是否存在新消息，并進(jìn)行消息拉取。

這樣輪詢的時(shí)間間隔需要很難確定合適，間隔大了消息不實(shí)時(shí)，間隔小了無疑對(duì)服務(wù)器會(huì)產(chǎn)生很大的壓力，無法支撐大量的在線用戶進(jìn)行聊天。

總結(jié)

由于推拉模式分別適用于業(yè)務(wù)中的不同場(chǎng)景需要，所以我們要使用推拉結(jié)合的方式來做。

拉模式適合的場(chǎng)景如下：

1. 設(shè)備初始化時(shí)：先拉取會(huì)話列表，在根據(jù)會(huì)話的列表來為每個(gè)會(huì)話拉取一定的消息記錄。可以通過控制拉取的數(shù)據(jù)量，減輕服務(wù)端壓力。
2. 歷史聊天記錄：按需拉取一定條數(shù)的記錄，用戶向上翻取記錄再拉取固定條數(shù)的記錄，直到翻到?jīng)]有記錄（就是翻頁）。

推模式適合的場(chǎng)景如下：

1. 用戶實(shí)時(shí)接收消息
2. 用戶在線，有未讀消息做通知欄push時(shí)

五. 消息流轉(zhuǎn)

上面確定好推拉模式后，我們來看發(fā)消息和收消息都有哪些業(yè)務(wù)邏輯執(zhí)行。

發(fā)消息

如上圖所示，大致可分為三步

1. 消息過濾

首先用戶的消息通過客戶端的SDK發(fā)送出來，通過長(zhǎng)鏈接到達(dá)了「邏輯層」，邏輯層接收到該請(qǐng)求后，可以根據(jù)定義的攔截過濾規(guī)則調(diào)用「服務(wù)層」的服務(wù)接口，來對(duì)消息進(jìn)行處理；

2. 消息補(bǔ)充

處理通過后，來對(duì)消息的發(fā)送方資料進(jìn)行填充，簡(jiǎn)單來說就是senderId標(biāo)識(shí)，接收方接收消息時(shí)能夠填充到對(duì)應(yīng)的會(huì)話中。

3. 派發(fā)任務(wù)

消息實(shí)體處理完成后，將該消息push到「服務(wù)層」的「異步任務(wù)隊(duì)列」服務(wù)中。

異步隊(duì)列任務(wù) 主要需要做以下四個(gè)方面的操作

1. 更新存儲(chǔ)端的「聊天記錄」
2. 更新會(huì)話的「消息總數(shù)量」，用來計(jì)算未讀計(jì)數(shù)
3. 根據(jù)接收方的在線狀態(tài)來判斷，是直接進(jìn)行push，還是存入到離線列表中，等待用戶上線后再進(jìn)行消息拉取
4. 更新「會(huì)話列表」的score值

具體異步隊(duì)列還可以細(xì)化拆分，例如

1. 實(shí)時(shí)任務(wù)隊(duì)列
2. 延時(shí)任務(wù)隊(duì)列
3. 失敗重試隊(duì)列 分別啟動(dòng)不同的線程池來消費(fèi)任務(wù)，按需分配線程數(shù)處理

收消息

收消息主要有以下幾個(gè)場(chǎng)景需要處理

1. 客戶端需要將消息append到聊天列表中，并在會(huì)話列表中將該會(huì)話增加未讀消息標(biāo)識(shí)。
2. 如果接收方打開了開聊天窗口，客戶端會(huì)發(fā)送一個(gè)消息的ACK給服務(wù)端，來標(biāo)記該消息已讀。
3. 服務(wù)端收到已讀ACK后需要更新「已讀計(jì)數(shù)」相關(guān)數(shù)據(jù)項(xiàng)
4. 如果是拉取離線消息，服務(wù)端還需要更新「離線消息」相關(guān)數(shù)據(jù)項(xiàng)

基于 Spring Boot + MyBatis Plus + Vue & Element 實(shí)現(xiàn)的后臺(tái)管理系統(tǒng) + 用戶小程序，支持 RBAC 動(dòng)態(tài)權(quán)限、多租戶、數(shù)據(jù)權(quán)限、工作流、三方登錄、支付、短信、商城等功能

• 項(xiàng)目地址：https://github.com/YunaiV/ruoyi-vue-pro
• 視頻教程：https://doc.iocoder.cn/video/

小結(jié)

本文從五個(gè)方面來對(duì)單聊的IM架構(gòu)進(jìn)行了設(shè)計(jì)分析

1. 業(yè)務(wù)功能拆分
2. 數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)
3. 系統(tǒng)結(jié)構(gòu)設(shè)計(jì)
4. 推拉模式選擇
5. 消息流轉(zhuǎn)分析 講了基礎(chǔ)的結(jié)構(gòu)有哪些，數(shù)據(jù)結(jié)構(gòu)有哪些要求，以及消息流傳的過程是什么樣的。

對(duì)im單聊場(chǎng)景的開發(fā)框架有了大體的一個(gè)認(rèn)識(shí)，但是實(shí)際落地的時(shí)候還有很多細(xì)節(jié)需要去實(shí)現(xiàn)。