好消息:IM1.0.0版本已經上線啦,支持特性:
- 私聊發送文本/文件
- 已發送/已送達/已讀回執
- 支持使用ldap登錄
- 支持接入外部的登錄認證系統
- 提供客戶端jar包,方便客戶端開發
github鏈接: https://github.com/yuanrw/IM
前言
首先講講IM(即時通訊)技術可以用來做什么:
聊天:qq、微信
直播:斗魚直播、抖音
實時位置共享、游戲多人互動等等
可以說幾乎所有高實時性的應用場景都需要用到IM技術。
本篇將帶大家從零開始搭建一個輕量級的IM服務端,麻雀雖小,五臟俱全,我們搭建的IM服務端實現以下功能:
- 一對一的文本消息、文件消息通信
- 每個消息有“已發送”/“已送達”/“已讀”回執
- 存儲離線消息
- 支持用戶登錄,好友關系等基本功能。
- 能夠方便地水平擴展
通過這個項目能學到什么?
這個項目涵蓋了很多后端必備知識:
- rpc通信
- 數據庫
- 緩存
- 消息隊列
- 分布式、高並發的架構設計
- docker部署
消息通信
文本消息
我們先從最簡單的特性開始實現:一個普通消息的發送
消息格式如下:
message ChatMsg{
id = 1;
//消息id
fromId = Alice
//發送者userId
destId = Bob
//接收者userId
msgBody = hello
//消息體
}
如上圖,我們現在有兩個用戶:Alice和Bob連接到了服務器,當Alice發送消息message(hello)給Bob,服務端接收到消息,根據消息的destId進行轉發,轉發給Bob。
發送回執
那我們要怎么來實現回執的發送呢?
我們定義一種回執數據格式ACK,MsgType有三種,分別是sent(已發送), delivered(已送達), read(已讀):
message AckMsg {
id;
//消息id
fromId;
//發送者id
destId;
//接收者id
msgType;
//消息類型
ackMsgId;
//確認的消息id
}
enum MsgType {
DELIVERED;
READ;
}
當服務端接受到Alice發來的消息時:
- 向Alice發送一個
sent(hello)表示消息已經被發送到服務器。
message AckMsg {
id = 2;
fromId = Bob;
destId = Alice;
msgType = SENT;
ackMsgId = 1;
}
2. 服務器把hello轉發給Bob后,立刻向Alice發送delivered(hello)表示消息已經發送給Bob。
message AckMsg {
id = 3;
fromId = Bob;
destId = Alice;
msgType = DELIVERED;
ackMsgId = 1;
}
3. Bob閱讀消息后,客戶端向服務器發送read(hello)表示消息已讀
message AckMsg {
id = 4;
fromId = Bob;
destId = Alice;
msgType = READ;
ackMsgId = 1;
}
這個消息會像一個普通聊天消息一樣被服務器處理,最終發送給Alice。 
在服務器這里不區分ChatMsg和AckMsg,處理過程都是一樣的:解析消息的destId並進行轉發。
水平擴展
當用戶量越來越大,必然需要增加服務器的數量,用戶的連接被分散在不同的機器上。此時,就需要存儲用戶連接在哪台機器上。
我們引入一個新的模塊來管理用戶的連接信息。
管理用戶狀態

模塊叫做user status,共有三個接口:
public interface UserStatusService {
/**
* 用戶上線,存儲userId與機器id的關系
*
* @param userId
* @param connectorId
* @return 如果當前用戶在線,則返回他連接的機器id,否則返回null
*/
String online(String userId, String connectorId);
/**
* 用戶下線
*
* @param userId
*/
void offline(String userId);
/**
* 通過用戶id查找他當前連接的機器id
*
* @param userId
* @return
*/
String getConnectorId(String userId);
}
這樣我們就能夠對用戶連接狀態進行管理了,具體的實現應考慮服務的用戶量、期望性能等進行實現。
此處我們使用redis來實現,將userId和connectorId的關系以key-value的形式存儲。
消息轉發
除此之外,還需要一個模塊在不同的機器上轉發消息,如下結構: 
此時我們的服務被拆分成了connector和transfer兩個模塊,connector模塊用於維持用戶的長鏈接,而transfer的作用是將消息在多個connector之間轉發。
現在Alice和Bob連接到了兩台connector上,那么消息要如何傳遞呢?
- Alice上線,連接到
機器[1]上時- 將Alice和它的連接存入內存中。
- 調用
user status的online方法記錄Alice上線。
- Alice發送了一條消息給Bob
機器[1]收到消息后,解析destId,在內存中查找是否有Bob。- 如果沒有,代表Bob未連接到這台機器,則轉發給
transfer。
transfer調用user status的getConnectorId(Bob)方法找到Bob所連接的connector,返回機器[2],則轉發給機器[2]。
流程圖: 
總結:
- 引入
user status模塊管理用戶連接,transfer模塊在不同的機器之間轉發,使服務可以水平擴展。 - 為了滿足實時轉發,
transfer需要和每台connector機器都保持長鏈接。
離線消息
如果用戶當前不在線,就必須把消息持久化下來,等待用戶下次上線再推送,這里使用mysql存儲離線消息。
為了方便地水平擴展,我們使用消息隊列進行解耦。
transfer接收到消息后如果發現用戶不在線,就發送給消息隊列入庫。- 用戶登錄時,服務器從庫里拉取離線消息進行推送。
用戶登錄、好友關系
用戶的注冊登錄、賬戶管理、好友關系鏈等功能更適合使用http協議,因此我們將這個模塊做成一個restful服務,對外暴露http接口供客戶端調用。
至此服務端的基本架構就完成了: 
總結
以上就是這篇博客的所有內容,本篇幫大家構建了IM服務端的架構,但還有很多細節需要我們去思考,例如:
- 如何保證消息的順序和唯一
- 多個設備在線如何保證消息一致性
- 如何處理消息發送失敗
- 消息的安全性
- 如果要存儲聊天記錄要怎么做
- 數據庫分表分庫
- 服務高可用
……
更多細節實現就留到下一篇啦~
IM1.0.0版本已上線,github鏈接: https://github.com/yuanrw/IM
覺得對你有幫助請點個star吧~!

