即时通讯系统怎么设计？消息顺序、离线消息和多端同步怎么处理？

知识点详解：一条消息怎样从发送，走到断线后的恢复

先定义确认，避免用户不知道该不该重试

咱们假设做一个一对一与小群聊天系统，暂不讨论所有社交平台功能。

客户端生成稳定的发送请求 ID。重试同一条消息时继续使用这个 ID，服务端按用户与请求标识去重，避免断线重发产生多份业务消息。

服务端确认应有清楚语义：只是收到请求，还是已经可靠记录？如果要让客户端据此停止重试，确认通常需要建立在相应持久化条件之上。

这是一份教学设计，不是某个平台真实生产架构。可以参考Slack 公开的实时消息架构理解连接层和消息分发的职责，但不能把公开文章等同于今天全部产品实现。

存储成功和在线送达，是两个状态

消息通过验证后进入持久记录，再向在线终端投递。如果终端刚好掉线，在线投递可能失败，但消息不应该因此消失。

因此，需要区分已接收、已保存、已投递和已阅读。产品可以选择展示其中哪些状态，但内部语义要一致。

客户端 socket 写入成功，也不能证明对方已经显示或阅读。若需要送达确认，应有终端协议；阅读状态则需要用户行为或相应业务事件。

高可靠需求还要解决存储与事件发布的协调，例如通过受控事务与可靠事件机制，避免“消息保存了，但没有通知”或“通知发出，消息却没保存”。具体方案取决于存储和消息系统，不随意宣称全局原子。

顺序通常按会话定义，而不是全站一条序列

对聊天来说，同一会话的顺序比所有用户消息的全局顺序更重要。可以在会话内建立服务端顺序号，并用消息 ID 去重。

客户端收到重复事件，不应重复显示；发现序号缺口，可以补拉缺失范围。服务端分片时，又需要确保会话内的排序责任明确。

顺序号不能简单使用客户端时间。手机时间可能不一致，离线发送和网络延迟也会影响到达顺序。产品还要定义“发送时间”“服务端接收顺序”和“显示顺序”之间的关系。

图中的 10、11、12 表示当前会话的顺序号；消息还需要稳定身份，用于识别重试和重复投递。

离线恢复，依靠持久记录和同步游标

手机已经同步到会话序号 120，断线期间出现 121～125。恢复后，手机从自己的进度补拉，而不是等待服务器重新随机推送。

电脑可能已经同步到 125，但这不应该让手机跳过缺失消息。所以每个终端的同步进度需要独立管理，或者采用能够正确表达多端状态的协议。

已读进度又可能按用户在多端共享。同步到达和用户已读，不是同一个游标。 一个终端下载了消息，不代表用户看过。

游标还要配合消息保留、删除和权限变化。不能因为过去加入过群，就永远允许补拉后来无权查看的消息。

拆开连接归属和会话处理，才能讨论扩容

接入层维护连接以及用户在线位置，会话处理负责校验、排序和记录。路由把事件送到拥有对应连接的节点。

这使得增加连接节点和扩展消息处理可以分别评估。但连接迁移、订阅恢复、热点大群和故障重试，仍需要设计。

验收时至少模拟：发送后确认丢失、事件重复、序号乱序、终端离线、多端进度不同，以及节点退出。检查消息是否丢失、重复、越权，和最终能否恢复到正确状态。

单纯测每秒发送量，不能覆盖这些正确性条件。吞吐和可靠性都要按目标定义。

面试官继续追问

长连接就能保证消息不丢吗？

不能。连接可能中断，写入也不等于对方确认。需要持久记录、消息身份与恢复机制。

全局有序是不是最安全？

未必。它可能增加协调成本，而且业务通常只需要会话内顺序。先定义真正必要的范围。

已读状态和多端同步能用同一字段吗？

不能直接混用。一个表示数据已到终端，一个表示用户阅读行为，合并会造成错误含义。

面试速记卡

• 发送身份：稳定请求 ID，重试仍然对应同一条消息。
• 确认语义：收到、保存、投递、阅读分开。
• 顺序范围：会话内顺序，消息身份负责去重。
• 离线恢复：从持久记录按终端游标补拉。
• 多端边界：同步进度与用户已读分别设计。