1. 先定边界企业IM里的“可靠”到底由谁来定义做企业IM那会儿我最怕收到的告警不是服务端503而是用户截图问这条消息明明收到了怎么过一会儿又变成“未送达”再一刷新消息直接没了。这个场景几乎把消息可靠性这四个字彻底戳穿发送端不确定消息算不算成功接收端的状态随时会回退两端谁都不敢拿它当依据。今天这篇内容就围绕企业即时通讯里的消息可靠性把整条链路上能踩的坑重新捋一遍包括回执与重试、幂等去重、离线拉取、多端同步、服务端存储以及一次实际排查的线上问题。适合正在做IM、协同办公、客服系统或任何带私聊和群聊功能的后端同学参考也适合刚接触系统设计、想看可靠性怎么落地的人。先说一个反直觉的事实很多人把消息可靠性等同于消息队列的QoS觉得只要用了Kafka、开启了确认机制、写入了副本消息就一定不会丢。但企业IM的可靠性从来不是单一组件的可靠性而是从用户点击发送、客户端本地存储、服务端落库、消息队列分发、接收端渲染、再到已读回执这一整条链路的状态一致性。任何一个环节提前把“成功”状态返回了后面都会是隐患。我对产品团队最开始说的是别把“可靠”当一个玄学词。要落地就先把它翻译成用户可以验收的三件事实——不能少收不能重复看到不能无故乱序。至于达成途径业内基本不会去追求理想化的“恰好一次”而是用“至少一次 幂等去重 服务端作为唯一事实来源”让用户体验趋近于不多不少。1.1 用户能感知的可靠性不重、不漏、不错乱“不漏”很好理解一条消息发出去接收方在任意时间点登录都应该能拿到完整内容。“不重”则经常被忽略因为很多人以为消息重复只是客户端展示层的修修补补。实际上重复消息一旦进入数据库轻则聊天记录里出现两条一模一样的内容重则触发对账、审批、工单等业务动作重复执行。“不错乱”在单聊里可能影响不大但在群聊里非常明显A说“我明天请假”B说“那我来主持”如果消息乱序B的消息先展示用户就会看到一个完全莫名其妙的对话。1.2 为什么“至少一次 幂等去重”才是IM的现实答案消息中间件里经常看到三种投递语义at-most-once、at-least-once、exactly-once。很多人一开始都会说“我们要exactly-once”但在企业IM这种高并发、多端、弱网环境下真正的exactly-once代价极高而且没有一个全局事务能覆盖“用户点击”到“对端渲染”这整条链路。投递语义表现适合场景at-most-once可能丢消息日志采集、非关键统计at-least-once不丢但可能重复企业IM实际采用的底座exactly-once不丢不重但协调成本高支付、账户类强一致场景IM的做法是底层接受at-least-once允许因为网络超时、服务端重启、消费重试产生重复但在应用层通过唯一约束和幂等消费把重复剔除掉。用户侧感知到的结果才接近exactly-once。这个思路贯穿后面要讲的每一个环节。1.3 四个阶段四个确认不能混淆为了后面讨论先把一条消息的生命周期拆成四个阶段阶段谁确认用户看到的状态发送成功发送端本地已暂存发送中 / 发送失败服务端已接收业务服务端落库成功已发送已送达接收端接收端客户端回执已送达已读接收端用户打开会话已读最容易被忽略的是阶段之间的缝隙。“服务端已接收”不等于“接收端已送达”如果服务端落库成功但下发失败消息只是躺在服务器的历史表里接收端完全没感知。又比如“已送达”确认如果记录错位就会出现类似开头那种“已读”后来又回退的事故。后面所有设计本质上都是在填这四个阶段之间的缝隙。2. 发送链路设计从按下发送到对方渲染中间是一条有状态的状态机2.1 先画出消息发送的全链路一条消息从发送端出发理想路径是这个状态机客户端把消息先写进本地存储状态置为“发送中”通过长连接或HTTP接口提交给服务端服务端校验、路由生成服务端消息ID和会话内seq服务端写入消息内容表同时写入接收方的时间线索引服务端回执给发送方发送方把本地状态更新为“已发送”服务端通过推送或长连接下发接收端接收端渲染消息并回报“已送达”接收端用户阅读后回报“已读”。我见过不少团队在第2步和第5步上很随意客户端只要发出了请求就先在界面上把气泡显示成“已发送”。这种做法等于把成功状态的判断权交给了客户端自己的本地行为一旦网络超时或服务端返回失败界面上的状态就会出现自相矛盾。所以第一条经验是**“发送成功”如果由客户端一发请求就决定后面所有可靠性设计都是空谈。**企业IM里宁可让“发送中”状态多持续几百毫秒也要等服务端明确回执。用户对轻微延迟的容忍度远高于对错误状态的不信任感。2.2 消息ID必须“客户端生成 服务端兜底”消息ID到底由谁生成是设计IM时最先被讨论的问题。完全由服务端生成客户端在超时重试时无法知道第一次请求是否已经成功可能重复发送完全由客户端生成则要面对多端同时发消息、客户端生成规则被绕过等风险。实际项目里最稳的组合是客户端生成一个全局唯一的clientMsgId建议用“客户端实例ID 本地自增序号”或UUID服务端接收后生成自己的serverMsgId两者都保留。客户端生成的clientMsgId是用来给服务端去重的服务端对“同一发送方 同一clientMsgId”建唯一约束。这样客户端无论重试多少次服务端都返回第一次写入的那条消息不会因为重试产生垃圾数据。服务端生成serverMsgId还有一个额外作用它和会话内seq天然绑定可以用于排序、分页、离线拉取游标。客户端拿到的clientMsgId不能作为排序依据因为并发请求到达服务端的顺序可能和客户端发起顺序不一致。2.3 三类Ack要分开设计需要认真对待三类确认发送方到服务端的ack服务端落库成功后响应响应内容应该包含serverMsgId和会话seq。服务端到接收端的下行ack接收端收到完整消息并成功写入本地后回执给服务端。接收端业务已读的ack用户真正打开会话后触发是异步且与消息时序弱相关的。这三类ack一旦混用就会出现“已读”回执被当作“已送达”回执消费的情况。实际排查事故时我发现很多状态错乱就是把这三条通道合并成了一张表、一个字段。长连接场景下尤其要注意下行的ack粒度。接收端不能只回执最新一条消息的ID而应该带上本次收到的消息范围。比如服务端下发1到10客户端只成功收到2到9就回执一个连续的区间或具体ID列表服务端才能准确知道哪些需要补发。2.4 重传、幂等与本地临时排序发消息的超时重传是刚需。超时并不代表服务端一定没成功也可能只是回包在网络里丢了。如果客户端每次重试都生成一条新消息那才是灾难。正确的做法是重试携带原始clientMsgId服务端通过该ID去重返回第一次写入的结果。重传还会带来消息顺序问题。比如先发A后发BA的请求超时重试后才被服务端处理此时B已经写入服务端会看到B的seq比A小但内容时间线已经乱了。解决思路是如果客户端检测到更早的消息还没确认先阻塞同一会话内后续消息的发送或把未确认消息作为本地“发送中状态”序列保留等A确认后再发B保证进入服务端的顺序和用户输入顺序一致。这个设计对普通聊天来说优先级不用太高但做审批、工单、客服转接这类强流程场景时它是不可让步的底线。顺序的最终裁判是服务端分配的seq不是客户端本地时间戳。客户端本地可以先临时展示“发送中”气泡但等服务端回包或增量同步到达时一定要按seq重新排序否则就容易出现后发先至的诡异界面。3. 离线消息、多端同步与撤回场景最容易让消息“消失”的三块暗礁3.1 离线不是终点拉取游标才是保证企业IM用户不可能永远在线。如果离线消息靠“一次性推给客户端”来保证那基本等于靠运气。我倾向把离线消息的可靠性建立在服务端全量保存 客户端增量拉取模型上。用户维度维护一个会话索引每个用户在每个会话中已经拉取到哪个seq。用户重新连接时先拉取未读会话列表再根据每个会话的游标增量拉取。客户端每次收到消息除了渲染还要在本地持久化更新游标。服务端只要保证每条消息在索引中有一条完整记录离线阶段就不会丢。3.2 增量游标与断点续传的细节增量拉取最常见的坑是游标没有持久化。App被杀掉、磁盘空间满、迁移数据库都可能让游标回到旧位置导致重复拉取如果游标跳到未来位置则会发生“漏拉”。我习惯在客户端存两个游标last_pulled_seq和last_rendered_seq。前者表示已经从服务端拉到哪条后者表示真正显示到界面上的是哪条。两者之间就是“已拉取但还没处理完”的缓冲重启后从last_rendered_seq继续确保不会因为渲染中断而丢消息。服务端那边则不要只依赖客户端上报的游标还要自己记录一份每个用户在每个会话的“已下发seq”。如果检测到客户端上报的游标比服务端记录的小说明客户端可能回退了这时候需要重新下发增量如果客户端上报的游标比服务端记录的大说明有消息状态丢失需要触发修复任务。3.3 多端已读状态用版本号别用布尔值多端同步最麻烦的不是消息内容而是状态。手机端读到过不代表PC端也读了。如果不区分“已送达”和“已读”用一个全局布尔值覆盖就会出现手机上显示已读打开PC端时却因为某种同步覆盖被改成未读的情况。这也是“已读变未读”类问题的很大来源。正确的做法是状态更新使用单调递增的版本号。比如read_version每次用户已读时版本号加一。多端上报已读后服务端只接受比当前版本更新的状态。SQL更新加一个条件where read_version new_version。这样无论哪一端的状态后到都不可能把新状态回退成旧状态。3.4 撤回、删除也要走消息链路撤回在企业IM里是必做的。很多人把撤回设计成直接修改数据库原始消息的content字段加上撤回标记结果就出问题客户端如果已经拉到原始内容撤回事件却走另一套通道可能比原消息先到也可能在离线拉取时被漏掉。更严重的如果消息列表的分页依赖“content非空”过滤撤回的消息直接在历史记录里消失用户连“这条消息被撤回了”的痕迹都看不到。我建议把撤回、删除、提醒这些操作统一当成一种“系统消息”写进时间线分配服务端seq像普通消息一样被可靠地下发和离线拉取。接收端收到后再对本地原来那条消息做状态变更。这样撤回事件丢失的概率和普通消息丢失的概率就一样了而不是额外多出一个脆弱通道。3.5 排序哲学服务端seq说了算多端聊天里最经典的现场是手机发了一条消息手机本地时间是13:00但因为网络排队服务端把它的seq分配在13:02的消息后面。如果客户端拿本地时间来排序UI上就会出现后发先至。企业IM里消息的最终顺序统一以服务端分配的seq为准。客户端本地时间只用于展示“几点几分”不参与排序。如果UI上要做“发送中”的临时排位等服务端回包后也要按seq重新排一次否则用户会看到消息位置跳来跳去。别看这个点小它直接影响用户对“乱序”的直接感知。4. 服务端内部的可靠性数据库、消息队列与幂等消费4.1 先写库还是先发MQ老生常谈但确实容易翻车服务端收到消息后需要做两件事把消息内容落库然后通知通道服务或推送服务把消息下发出去。这两步如果做成“先发MQ再落库”MQ消费者启动时会发现消息内容还没写进去要么等一会儿重查要么直接丢如果做成“先落库再发MQ”又存在落库成功但MQ发送失败的间隙消息在库里但实时通知没出去。比较靠谱的做法是本地消息表。因为消息内容表本身就在库里可以很自然地把“待投递”作为消息表的一个状态字段statuspending表示落库成功但还没进入投递队列。后台补偿任务定时扫描没有成功投递的记录重发MQ投递成功后改为delivered。这个方案虽然多消耗一点数据库查询但实现简单、逻辑清晰故障恢复时也能直接从库里找到依据。4.2 事务消息的取舍如果没有自研中间件可以借助支持事务消息的MQ或者用本地消息表和MQ Producer在同一个本地事务里写入。核心思路都是保证“业务表写入”和“消息可被投递”要么同时成功要么同时有兜底。我并不是很推荐在IM场景下一上来就上分布式事务。IM消息绝大多数是非交易类数据丢一条或重一条虽然体验差但后果不致命完全可以用“本地消息表 定时补偿”解决。分布式事务的成本和故障面反而会让一个本可以简单的链路变得复杂。4.3 消费端幂等唯一约束是最终的防火墙消息队列为了可用性通常默认at-least-once。消费者如果在处理完成后、提交offset前宕机同一条消息就会被消费两遍。如果消费者把“收到消息”当成不可辩驳的事实直接insert重复消息就会在时间线里多出一条。我的做法是给消息时间线表加联合唯一索引(conversation_id, message_id)或(receiver_id, server_msg_id)。消费逻辑做成upsert如果主键冲突就说明这条已经处理过直接返回成功。不要依赖“先select再insert”并发场景下两个消费者可能同时查不到记录然后同时插入。数据库唯一约束才是最后的防火墙。4.4 分区路由与顺序性会话内有序就够了实时消息确实讲究顺序但企业IM里不需要全局有序只需要同一个会话内的有序。Kafka之类的MQ里同一个分区的消息是有序的把消息按conversation_id做hash路由到同一个分区就能保证同一个会话内的消息按写入顺序被消费。有一个常见的坑如果服务端消息在写库后、发MQ前经过批量聚合或重新排序即使分区路由对了顺序也可能被搞乱。发送侧的重试要做到“同一条消息的失败重试不改变原始写入顺序”避免A、B两条消息A第一次发失败重试时反而排到了B后面。4.5 死信与重试风暴无限重试才是最大的不可靠一个常见反面设计是回调失败后不设上限地无限重试结果造成消息队列积压、下游被拖垮。更合理的分层是第一次失败延迟重试指数退避最多5到10次超过重试次数进死信队列或标记为待人工处理补偿任务定期扫描死信在业务低峰期自动补发同时写清楚重试次数和失败原因。“人工可干预”本身也是可靠性的能力之一。没有补偿和人工介入通道的消息系统出问题时只能靠改数据库风险非常高。5. 一次线上“已读变未读”事故复盘从告警到根因那年我们接了一个新的企业侧消息网关产品反馈说偶尔出现用户手机端收到一条消息显示已读后过一阵子再打开这条消息又变回未读后台里连送达记录都查不到。这不是偶发消息量一大时概率更高。5.1 第一步确认不是多端状态互相覆盖一开始怀疑是多端同步的布尔值互相覆盖。把Redis和DB里的读取状态拉出来发现确实存在会话维度的更新竞争同一个用户的手机端和PC端同时上报已读状态后到的覆盖先到的。但我让测试把PC端退出登录只保留一台手机问题依旧。这说明问题不只是多端覆盖这么简单。5.2 第二步从message_id全链路拉日志发现重复下发在消息网关里加了trace_id和message_id的联动日志找到一条丢失消息结果发现它的下发事件被消费了两次。两次消费都进入“更新送达状态”的逻辑但由于第一次更新和第二次更新之间隔着一个异步任务第一次任务把状态置为已送达异步任务又根据某个时间戳条件把状态回退成未送达。问题出在消费者没有针对这次回执做幂等也没有判断当前状态是否比新状态更新。5.3 第三步定位到两个服务同时操作同一个状态字段继续往下挖根因是链路上有两个写入点消息接入服务负责写入消息回执网关负责更新送达和已读状态。双方都基于updated_at判断“谁新谁生效”但数据库在压测环境中updated_at的精度设置是秒级同一秒内的两次更新后一次可能拿到的还是旧值于是发生逻辑上的“时间倒流”明明已经已读却被同步任务按一个更晚的时间戳覆盖成了未读。修复其实不复杂把状态改成单调递增的版本号客户端回执带上版本SQL更新加一个where status_version new_version条件旧版本永远覆盖不了新版本。同时给回执处理加上幂等键同一个message_id read_version只允许成功一次。上线后已读变未读的比例直接归零。5.4 这次事故给我们的额外教训排查完发现一个很扎心的事实**可靠性事故很少是“消息没收到”而是“消息的状态在链路里被改错了”。**丢失一条消息往往能从发送日志里看个大概而状态回退问题却藏得很深因为数据记录还在只是那一刻的值是错的。后来我特别强调状态机日志的采集每条消息的送达、已读、撤回操作都要记录状态迁移轨迹方便出事时能沿着版本回放。6. 落地阶段直接能用的监控指标与上线检查清单6.1 五类核心监控指标可靠性不是上线那一刻决定的而是发布后持续监控出来的。我建议至少盯住这五类指标指标说明可能反映的问题消息发送成功率服务端落库成功的消息数 / 客户端发起数发送网关异常、幂等键冲突、客户端重传异常接收端回执率收到已送达回执的消息数 / 服务端下发数长连接断开、推送通道失效、回执解析失败回执翻转率状态从已读回退到未读或未送达的比例状态版本冲突、多端覆盖、幂等不完整拉取游标断裂量离线增量拉取时出现seq空洞或游标倒退的次数游标持久化失败、历史数据被清理死信队列积压量超过重试上限的消息数下游系统故障、业务处理bug有了这些指标新版本发布后就不是凭感觉说“挺稳的”而是拿回执率和翻转率说话。6.2 上线前可靠性验收清单每一次新模块或大版本上线前我会让团队逐条过一遍检查消息时间线表是否建了唯一索引消费者是否做了幂等upsert客户端重试时是否携带原始clientMsgId服务端能否据此去重服务端落库和投递之间是否有补偿任务兜底而不是只靠一次发MQ成功多端同步的已读状态是否使用版本号递增而不是布尔值互相覆盖撤回、删除等操作是否作为系统消息写入时间线并且可被离线拉取监控面板是否能看到回执率、翻转率、游标断裂量三张图压测里是否模拟过网络超时重传、服务端进程重启、MQ积压三种故障这七条如果都能在发布前过掉大部分常见事故基本可以提前避免。6.3 最后说点个人经验我现在看一份IM设计文档第一眼往往不看它用了多先进的消息队列而是只看三个问题服务端落库到底发生在哪个步骤状态更新是不是幂等用户在界面上看到的状态会不会因为某个异步任务而倒退这三个问题回答清楚了再细化协议、存储、分片才有意义。否则用再强的MQ也只是把不可靠从一个环节挪到另一个环节。记得还得单独准备一份“故障演练脚本”至少每季度模拟一次长连接服务器整体重启、消息队列集群抖动、数据库主从切换。这些场景下真正检验可靠性的不是文档写得有多漂亮而是恢复链路能不能在几分钟内自动把积压补齐、把游标修复、把状态版本拉平。企业IM的可靠性最终是演练出来的不是评审出来的。