單聊

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

那么一個IM（InstantMessaging）的1對1聊天系統(tǒng)架構和存儲應該如何設計呢。

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

一. 功能點拆分

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

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

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

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

二. 數(shù)據(jù)結構

實際進行下面幾種數(shù)據(jù)結構存儲時，可使用適合自己的場景的組件，例如公司自研的，或熟悉并滿足場景要求的。

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

1. 會話列表

首先，需要為每一個會話創(chuàng)建一個會話Id進行標識。

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

結構如下：

key: prefix_xxx:{uid}value: {會話Id}score: {msgId}

key使用當前用戶的uid來標識，集合中的每個item則是會話的Id，item的score為會話的最后一條消息的Id，這樣根據(jù)score自動形成一個有序集合后，就能夠滿足我們的應用場景了。

2. 單聊消息列表

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

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

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

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

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

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

SELECTmsgIdFROMt_msg_record_listWHEREsessionId=1ANDrecordStatus=0ANDmsgId>1ORDERBYiddescLIMIT10;

3. 離線消息

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

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

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

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

然后，消息id列表使用redis的一個list鏈表來存儲

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

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

4. 未讀計數(shù)

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

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

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

接受消息總數(shù)量

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

已讀數(shù)量

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

5. 用戶資料

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

三. 架構層級拆分

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

1. 客戶端層

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

2. 連接層

即時通訊需要客戶端和服務端之間建立一個長鏈接，一方面維護用戶的在線狀態(tài)，另一方面便于復用連接進行消息的收發(fā)。

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

這樣在業(yè)務邏輯迭代上線時，業(yè)務層進行滾動上線也不會導致用戶的鏈接斷開。

連接協(xié)議

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

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

這里推薦優(yōu)先使用四層的協(xié)議來進行長鏈接的維護。

因為長鏈接集群的前方要做負載均衡，使用七層的協(xié)議，客戶端要先和負載均衡機器建立鏈接，然后負載均衡機器再和業(yè)務層集群交互。

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

3. 業(yè)務層

業(yè)務層可以分為「長鏈接業(yè)務層 」和「短鏈接業(yè)務層 」

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

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

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

4. 服務層

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

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

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

四. 推拉模式選擇

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

1. 純推模式

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

場景1: 新設備登陸初始化

用戶新登陸一臺設備的時候，如果消息記錄全都是空的，體驗會很不好。

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

場景2: 設備間切換

tips：設備A和B都非第一次登陸

如圖所示，流程如下

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

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

2. 純拉模式

然后，我們假設使用純拉模式 ，來看會存在哪些問題

場景1: 收新消息

純拉模式下，客戶端需要和服務端進行一個長輪詢，來定時檢查是否存在新消息，并進行消息拉取。

這樣輪詢的時間間隔需要很難確定合適，間隔大了消息不實時，間隔小了無疑對服務器會產生很大的壓力，無法支撐大量的在線用戶進行聊天。

總結

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

拉模式適合的場景如下：

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

推模式適合的場景如下：

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

五. 消息流轉

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

發(fā)消息

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

1. 消息過濾

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

2. 消息補充

處理通過后，來對消息的發(fā)送方資料進行填充，簡單來說就是senderId標識，接收方接收消息時能夠填充到對應的會話中。

3. 派發(fā)任務

消息實體處理完成后，將該消息push到「服務層」的「異步任務隊列」服務中。

異步隊列任務 主要需要做以下四個方面的操作

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

具體異步隊列還可以細化拆分，例如

1. 實時任務隊列
2. 延時任務隊列
3. 失敗重試隊列 分別啟動不同的線程池來消費任務，按需分配線程數(shù)處理

收消息

收消息主要有以下幾個場景需要處理

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

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

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

小結

本文從五個方面來對單聊的IM架構進行了設計分析

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

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