如何保障分布式IM聊天系统的消息有序性（即消息不乱）

jackjiang2025

墨衍会员 · AI 创作全网分发码龄8年

关注

原创 2026-01-19 22:13:20 835 阅读 AI 写同款· GEO 优化 ›

本文引用了45岁老架构师尼恩的技术分享，有修订和重新排版。

1、引言

分布式IM聊天系统中，IM消息怎么做到不丢、不重、还按顺序到达？

这个问题，涉及到IM系统的两个核心：

1）消息不能丢（可靠性）：比如用户点了发送，不能因为服务宕机或网络抖动，消息石沉大海。比如地铁隧道、电梯间，网络断了又连，消息不能卡住不动（要确保弱网也能用）。

2）顺序不能乱（有序性）：比如“在吗？” 回成 “吗在？”，群聊时间线错乱，体验直接崩盘。

这二大痛点，是IM聊天系统架构的命门所在。

下面是一张IM消息从发出到接收的关键路径：

2、系列文章

为了更好以进行内容呈现，本文拆分两了上下两篇。

本文是2篇文章中的第 1 篇：

《如何保障分布式IM聊天系统的消息有序性（即消息不乱）》（☜ 本文）
《如何保障分布式IM聊天系统的消息可靠性（即消息不丢）》（稍后发布..）

本篇主要总结和分享分布式IM聊天系统架构中关于消息有序性的设计和实践。

3、传统技术方案的瓶颈，怎么破？

早期做消息有序，很多人第一反应是搞个“全局发号器”——所有消息排一队，挨个编号再发。

理想很丰满，现实很骨感：高并发下一拥而上抢号，发号器直接被打满；更致命的是，它一旦宕机，全链路雪崩。

这就像春运火车站只开一个售票窗——再快也撑不过三分钟。

所以，我们必须换思路：不搞大一统，而是分片独立发号，让每个“窗口”自给自足，互不干扰。

4、痛点拆解：为什么消息会乱？

我们先还原一个真实场景：想象一下你和朋友聊天：

你说：“1 吃饭了吗？”

他回：“2 刚吃完。”

你又说：“3 吃啥呢？”

结果对方手机上显示成：

“3 吃啥呢？” → “1 吃饭了吗？” → “2 刚吃完。”

这不是 bug，是分布式系统的常态。

三条消息走不同服务节点、经不同网络路径，到达时间完全不可控，最终呈现顺序错乱。

会乱问题本质是什么？一个要“串行等”，一个想“并发冲”，天然冲突。

这时候有人会说：那我加个全局排序服务不就行了？

可以，但代价太大——一个中心节点最多撑几万 QPS，面对百万群聊、亿级用户，还没上线就已过载。

所以，全局有序不是解，而是枷锁。我们要的不是“天下大同”，而是“各聊各的别乱就行”。

5、最终方案：分而治之 + 局部有序

真正的突破口在于：我们根本不需要全局有序，只需要“会话内有序”。

你和张三的聊天记录不能乱，但你和李四的聊天跟王五的完全无关——何必放一起排序？

这就引出了经典策略：分而治之 + 局部有序。

具体怎么做？两步走稳：

* 第一步 - 业务分区：哈希分片，锁定归属

用 sessionId 做一致性哈希，确保同一个会话的所有消息始终路由到同一个处理节点。按“会话ID”做哈希，算出该消息该由哪个节点处理。同一会话 → 哈希值一样 → 路由到同一台机器 → 所有消息串行处理，天然避免跨节点乱序。

这样一来，单个会话内的消息在服务端就是串行处理的，天然不会乱。

* 第二步 - 局部序号：独立发号，局部递增

每个会话独立维护一个计数器，每来一条消息就+1，作为它的“官方序号”。每个会话,可以配一个独立计数器（比如 Redis 的 INCR），每来一条消息就+1，生成唯一 SEQ。客户端不管什么时候收到消息，只认这个序号，按序号从小到大排列展示。

这个 SEQ 就是这条消息的“官方身份证号”，客户端只认这个，不看接收时间。这就像电影院检票——你可以早到晚到，但座位按票号定。哪怕后排观众先进场，也不会坐到前排去。

PS：IM消息ID生成相关的文章可详细阅读以下资料：

6、实践落地（核心片段伪代码）

1）服务端分片路由逻辑：

来看关键实现：如何把消息精准投递给“对的人”。

String sessionId = msg.getSessionId();

//这里是伪代码，实际代码以mq 的负载均衡机制为准

int nodeIndex = Math.abs(sessionId.hashCode()) % clusterNodeCount;

//这里写个伪代码，代表mq 主从复制

ClusterNode targetNode = clusterNodes.get(nodeIndex);

targetNode.sendMsg(msg);

核心就一句：基于会话 ID 哈希取模，固定路由。

从此，每个会话都有了自己的“专属服务通道”，不再受其他会话影响。

2）服务端序号分配逻辑：

接下来，给每条消息发“通行证”：

long msgSeq = redis.incr("msg_seq_" + sessionId);

msg.setSeq(msgSeq);

msg.setUniqueKey(sessionId + "_" + msgSeq);

这里用了 Redis 的 INCR，保证同一个会话下的 SEQ 绝对递增，且线程安全。同时用 sessionId_seq 作为唯一键，既能幂等去重，也能防止重试导致消息重复入库。

实战提示：

如果你的 Redis 是集群模式，记得确保同一个会话的 key 落在同一 slot，否则 INCR 可能跨节点失效。

3）客户端排序逻辑：

最后一步，客户端收尾：别急着渲染，先排好队。

//这里是伪代码，先排序

List<Msg> sortedMsgs = msgList.stream()

.sorted(Comparator.comparingLong(Msg::getSeq))

.collect(Collectors.toList());

//这里是伪代码，再渲染

renderMsgList(sortedMsgs);

无论消息以什么顺序到达，统统按 seq 升序排列后再上屏。哪怕第100条先到，第1条后到，也能正确归位。这也是为什么我们强调“客户端必须信任服务端 SEQ”——它是唯一真相源。