即时通讯消息不丢失，不是靠单一重试，而是靠发送端确认、服务端先落盘、接收端补拉三步协同。链路中任何一个节点只做“发出去”，不确认、不持久化、不补拉，消息就会在断线或进程重启时消失。
先回答什么是IM即时通讯：它是支持文本、图片、音视频等消息实时双向传输的系统。即时通讯软件有哪些类型？按使用场景，主流即时通讯软件可分为个人社交、远程办公和客户沟通三类。本文讨论的“不丢失”具体指三种情形：发送端显示成功但接收方未收到、接收方离线后消息漏掉、同一消息在多端重复或缺失。
即时通讯系统架构中，决定消息可靠性的四个节点
即时通讯系统架构设计要点可以收敛到四个节点：客户端、长连接接入层、消息队列、持久化存储。每个节点都有对应的丢失风险，可靠性设计必须明确每一层“谁负责确认、谁负责重试”。
- 客户端：负责本地未确认队列和超时重试。发送后未收到服务端ACK前，消息必须留在本地。
- 长连接接入层：维护TCP/WebSocket连接状态，承担心跳与断线检测。连接假死而客户端未感知，会导致消息卡在发送队列。
- 消息队列：在流量高峰削峰，同时提供异步重试。队列不做持久化时，进程崩溃就会丢消息。
- 持久化存储：先写消息再回ACK，按会话或消息ID顺序落盘。这层是离线消息和多端同步的基础。
排查消息丢失时也按同样分层推进，从网络、服务端到客户端逐层定位能避免误判。
发送端到服务端：ACK、重试与幂等是必达的第一道闸
客户端发出消息后，只有在收到服务端明确ACK后才能从本地未确认队列删除。未确认前，客户端应把消息持久化在本地数据库；断线或应用被杀后重启，队列中的消息继续按同一消息ID重发。服务端收到重复ID时直接去重并返回ACK，这就是幂等。
如果客户端“发送成功”只是写入操作系统层就删除副本，服务端在真正持久化前崩溃，消息就会丢失。需要排查时，消息发不出去或发出后未见达，可按端侧、连接层、服务端三层检查确认与重试日志。
服务端到接收端：持久化、离线队列与多端同步
服务端收到消息后必须先落盘，再向发送端回ACK，同时转发给接收端在线会话。接收方离线时，消息写入该用户专属离线队列；上线后客户端补拉队列中的消息，服务端按游标或消息ID返回未同步部分。
多端场景不能简单广播。每个设备应各自拥有同步游标，服务端按设备记录已确认消息ID。一端拉到消息不代表其他端已同步，否则切换设备就会出现漏消息。离线消息收不到通常不是网络差，而是服务端未存储、客户端未补拉或多端同步覆盖。
可靠性边界：什么情况下仍可能丢，如何取舍
没有任何IM能在所有极端条件下做到绝对不丢。弱网中客户端重试次数耗尽、本地缓存被用户手动清理、存储节点发生不可恢复故障，都可能造成消息丢失。设计时需要在“至少一次投递（At least once）”和“恰好一次投递（Exactly once）”之间做取舍：At least once会引入重复，需要客户端按消息ID去重；Exactly once则要额外协调状态，延迟和复杂度更高。
个人社交可以接受偶发重复，企业协作和客服沟通则通常要求至少一次且可对账。如果预算有限，中小企业IM选型应重点核对离线消息、多端同步和服务端持久化能力，上线后再补可靠性成本更高。
常见问题
多端同时在线时，为什么有的设备会漏消息？
服务端没有为每个设备维护独立同步游标，或者一端拉取后直接清除了全局未读标记。多端同步必须按设备记录已确认的消息ID范围。
采用至少一次投递后，客户端收到重复消息怎么办？
按消息ID去重。客户端本地保存最近若干条已接收ID，服务端在短时间内对同一ID只返回一次业务消息，重复到达直接丢弃。
离线消息应该保存多久？
个人社交通常7至30天，企业协作和客服沟通建议至少30天。超过保存窗口仍未拉取的消息进入归档，重新上线只同步有效窗口。
自建与SaaS在消息可靠性上主要差在哪？
SaaS默认提供ACK、持久化和离线补拉，但保存时长、QoS等级和排查深度受限；自建可调整阈值与存储策略，但必须自己承担多端同步设计和运维可靠性。
