如何设计一个IM单聊架构

create table t_msg_record_list (
`id` bigint not null primary key,
`sessionId` bigint not null comment '会话Id',
`msgId` bigint not null comment '消息Id',
`isRead` tinyint not null default 0 commment '已读状态',
`recordStatus` smallint not null default 0 commment '消息状态',
`createTime` datetime not null,
key `sessionId` (`sessionId`) 
)engine=innodb;

根据会话Id分页查询时，就可以这样查询出所有msgId，再根据msgId去拉取msg的详情，组合成列表返回给客户端

SELECT msgId FROM t_msg_record_list WHERE sessionId = 1 AND recordStatus = 0 AND msgId > 1 ORDER BY id desc LIMIT 10;

3. 离线消息

离线消息可以分为「索引」和「消息id列表」两部分

离线消息索引需要记录的是，哪些用户给当前用户发送了离线消息，所以我们可以使用redis的集合Set来记录这些信息

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

通过scan离线消息索引拿到了sendUid，再去拿这个会话的具体的离线消息id列表

然后，消息id列表使用redis的一个list链表来存储

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

拿到所有msgId以后，去获取msg的实体详情填充即可

4. 未读计数

未读计数= 收到消息总数 - 已读数量

所以我们要存储两个已知数据便于计算出未读数量，即消息总数量和已读数量

由于对话存在双方发消息，所以分别维护对话双方的两个数据项，方便计算各自的未读数

接受消息总数量

key: prefix_session_count:{会话Id}:{uid} value: 总数量

已读数量

key: prefix_session_read_count:{会话Id}:{uid} value: 已读数量

5. 用户资料

使用mysql按需设计即可，变更保存后将数据同步到redis中使用

三. 架构层级拆分

如图所示，我们可以将架构大致分为五层，具体说明如下

1. 客户端层

我们IM服务的client肯定是有多个，web/app等，需要封装多种SDK隐藏底层细节，便于接入方接入。

2. 连接层

即时通讯需要客户端和服务端之间建立一个长链接，一方面维护用户的在线状态，另一方面便于复用连接进行消息的收发。

而维护连接这个动作，它的独立性很强，不需要与业务逻辑耦合，所以我们把链接层单独拆分出来一个。

这样在业务逻辑迭代上线时，业务层进行滚动上线也不会导致用户的链接断开。

连接协议

至于连接协议的选择，有如下几种方式

基于tcp链接，自定义传输协议（开发成本高，需要有一定条件）
websocket
http chunk （不建议使用，http工作在7层上，且只能服务端单向的向客户端传输数据，心跳连接不好维护）

这里推荐优先使用四层的协议来进行长链接的维护。

因为长链接集群的前方要做负载均衡，使用七层的协议，客户端要先和负载均衡机器建立链接，然后负载均衡机器再和业务层集群交互。

这样在连接数很大的时候，负载均衡的机器容易成为瓶颈。四层的负载均衡可以直接通过修改目标机器ip prot的方式来进行转发，不需要client和负载均衡机器建链接

3. 业务层

业务层可以分为「长链接业务层 」和「短链接业务层 」

具体两者的功能拆分，可根据业务实际情况设计

长链接业务层: 负责会话相关的业务逻辑，比如收发消息/拉取会话列表/未读计数push等业务
短链接业务层: 负责一些临时接口请求，比如用户资料拉取/资料变更等类似业务

两种业务层都通过调用服务层来进行数据读取和写入等擦欧总

4. 服务层

这层属于微服务，来为上层业务层提供基础服务能力，例如敏感消息过滤/会话列表数据读写/消息的落地和发送等功能。

5. 数据层

为上层的服务层来提供数据的实际落地写入，可以使用mysql，redis或其他sql/nosql数据库。

四. 推拉模式选择

那么在消息的发送上，我们应该选用推模式，还是拉模式，抑或是推拉结合呢？

1. 纯推模式

首先，我们假设使用纯推模式 ，来看会存在什么样的问题

场景1: 新设备登陆初始化

用户新登陆一台设备的时候，如果消息记录全都是空的，体验会很不好。

那么就需要服务端推送全量的消息记录到客户端，历史消息量大的时候，非常浪费服务端资源和带宽。

场景2: 设备间切换

tips：设备A和B都非第一次登陆

如图所示，流程如下

用户1在设备A上登陆，收到了用户2的消息1和2，push到了设备A上。
用户1退出了设备A，用户2又给他发送了消息3和4
用户1登陆了设备B，服务端push消息3和4到了设备B

但是此时，设备B缺少了消息1和2，用户再登陆回设备A的话又缺少了消息3和4，这也就产生了「消息空洞 」

2. 纯拉模式

然后，我们假设使用纯拉模式 ，来看会存在哪些问题

场景1: 收新消息

纯拉模式下，客户端需要和服务端进行一个长轮询，来定时检查是否存在新消息，并进行消息拉取。

这样轮询的时间间隔需要很难确定合适，间隔大了消息不实时，间隔小了无疑对服务器会产生很大的压力，无法支撑大量的在线用户进行聊天。

总结

由于推拉模式分别适用于业务中的不同场景需要，所以我们要使用推拉结合的方式来做。

拉模式适合的场景如下：

设备初始化时：先拉取会话列表，在根据会话的列表来为每个会话拉取一定的消息记录。可以通过控制拉取的数据量，减轻服务端压力。
历史聊天记录：按需拉取一定条数的记录，用户向上翻取记录再拉取固定条数的记录，直到翻到没有记录（就是翻页）。

推模式适合的场景如下：

用户实时接收消息
用户在线，有未读消息做通知栏push时

五. 消息流转

上面确定好推拉模式后，我们来看发消息和收消息都有哪些业务逻辑执行。

发消息

如上图所示，大致可分为三步

1. 消息过滤

首先用户的消息通过客户端的SDK发送出来，通过长链接到达了「逻辑层」，逻辑层接收到该请求后，可以根据定义的拦截过滤规则调用「服务层」的服务接口，来对消息进行处理；

2. 消息补充

处理通过后，来对消息的发送方资料进行填充，简单来说就是senderId标识，接收方接收消息时能够填充到对应的会话中。

3. 派发任务

消息实体处理完成后，将该消息push到「服务层」的「异步任务队列」服务中。

异步队列任务 主要需要做以下四个方面的操作

更新存储端的「聊天记录」
更新会话的「消息总数量」，用来计算未读计数
根据接收方的在线状态来判断，是直接进行push，还是存入到离线列表中，等待用户上线后再进行消息拉取
更新「会话列表」的score值

具体异步队列还可以细化拆分，例如

实时任务队列
延时任务队列
失败重试队列分别启动不同的线程池来消费任务，按需分配线程数处理

收消息

收消息主要有以下几个场景需要处理

客户端需要将消息append到聊天列表中，并在会话列表中将该会话增加未读消息标识。
如果接收方打开了开聊天窗口，客户端会发送一个消息的ACK给服务端，来标记该消息已读。
服务端收到已读ACK后需要更新「已读计数」相关数据项
如果是拉取离线消息，服务端还需要更新「离线消息」相关数据项

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

项目地址：https://github.com/YunaiV/ruoyi-vue-pro
视频教程：https://doc.iocoder.cn/video/

小结

本文从五个方面来对单聊的IM架构进行了设计分析

业务功能拆分
数据结构设计
系统结构设计
推拉模式选择
消息流转分析讲了基础的结构有哪些，数据结构有哪些要求，以及消息流传的过程是什么样的。

对im单聊场景的开发框架有了大体的一个认识，但是实际落地的时候还有很多细节需要去实现。

欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：

已在知识星球更新源码解析如下：

最近更新《芋道 SpringBoot 2.X 入门》系列，已经 101 余篇，覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。

提供近 3W 行代码的 SpringBoot 示例，以及超 4W 行代码的电商微服务项目。

获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。

文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）