有没有经历过这种凌晨三点被电话叫醒的场景线上订单支付成功用户收到了扣款短信但业务订单状态一直停在待支付。查到最后发现一条关键的消息在链路里消失了。消息不丢失是使用消息队列之后最容易被低估的问题很多人一开始只关心吞吐量和延迟真正上线跑着跑着才开始面对从生产者到 Broker 再到消费者的一场又一场丢消息事故。经典的生产者消费者问题教科书里讨论的是多线程下的同步与协作等落到工程上问题要复杂得多——不光要解耦还要保证消息不丢、不重、不乱序。今天这篇文章就把消息从产生到消费的整条链路拆开逐层布防整理成一套可以直接落地的 7 层防线。无论你是后端开发、中间件运维还是正在做系统架构都应该把这七层防线装进自己的技术清单里。1. 丢消息的真相先弄懂一条消息的完整旅程1.1 一条消息从诞生到被消费经过了多少个关卡一条消息不是从代码里 new 出来就直接进了消费者业务代码的。它至少要经过一段很长的旅程业务系统在本地组装消息体、序列化通过网络客户端发送给消息中间件Broker 收到网络包后把数据写进内存和 PageCache再异步或同步刷到磁盘为了让数据在单机故障时不丢Broker 还要把数据复制到其他节点消费者通过拉取或推送拿到消息先反序列化再执行业务逻辑最后向 Broker 汇报“这条消息我处理完了”。到这里一条消息才算真正完成使命。这段旅程里的每一段都可能出问题。网络抖动可能让生产端发送超时Broker 刷盘前宕机可能让内存里的消息蒸发主从复制滞后可能让切换时丢数据消费者处理完了但没有正确提交位移可能在重平衡之后又被重复消费或者在处理失败后直接被跳过。消息丢失从来不是“某个环节做错了”这么简单它往往是几个环节的小概率事件叠加在一起才爆发的。1.2 最容易丢消息的三个地段发送、存储、消费我把丢消息的高发地段分成三大类后文所有防线都围绕这三类展开。第一类发送段。生产者把消息发给 Broker网络闪断、发送超时、Broker 临时拒绝服务任何一种情况都可能让消息没有被 Broker 确认。这里最难受的是“超时到底算成功还是失败”客户端发出去了Broker 也收到了但应答在网络里丢了客户端以为失败而重试就会重复客户端没发出去Broker 当然也没收到如果不处理消息就丢了。第二类存储段。消息到达 Broker 不代表就安全了。如果消息只停留在内存或 PageCacheBroker 进程崩溃或者机器断电这部分数据就没了。即使已经落盘单机硬盘坏了也会丢。所以存储段的核心问题是数据要同时在持久化设备和第二个节点上各留一份并且要在确认“留成功”之后才向客户端报成功。第三类消费段。消费者拿到消息业务逻辑还没跑完进程挂了、抛异常了、消费者组发生重平衡了都有可能把这条消息漏掉。最经典的场景就是用自动提交 offset消息一拉下来就提交位移结果业务处理失败消息再也不会被投递。消费段有一条铁律Broker 不关心你的业务是否成功它只关心你什么时候说成功。理解这一点后面第六、第七层防线就有了根基。2. 源头布防生产者端的前两层防线2.1 第一层防线发送确认机制别把“发出去”当成“送达”很多丢消息事故的起点是对“发送”这件事的理解太乐观。消息发出去了TCP 连接断没断、对端收到没收到、数据写成功没有这些都需要靠发送确认机制来回答。不同中间件机制叫法不一样但思路一致生产者要能拿到一个“送达回执”并根据回执决定下一步动作。以 Kafka 为例生产端有一个 acks 参数取值范围是 0、1、all也就是 -1。acks0 表示发送出去就不管了只要 TCP 能写就认为成功Broker 是否收到无从得知。acks1 表示 leader 写入本地就当成功但 leader 挂了并且副本没跟上时会丢。acksall 表示要等所有 ISR 副本都写入后才算成功这是业务消息可靠性的基本要求。RocketMQ 的同步发送会返回一个 SendResult里面有发送状态常见的有 SEND_OK、FLUSH_DISK_TIMEOUT、FLUSH_REMOTE_TIMEOUT、SLAVE_NOT_AVAILABLE。很多人只看 SEND_OK其他状态要么没判断要么当成成功处理这种习惯同样会漏消息。FLUSH_DISK_TIMEOUT 和 FLUSH_REMOTE_TIMEOUT 都意味着 Broker 没有完成保存性质上不应该当作成功。实际操作里我最推荐“同步发送 明确的状态检查”作为默认方案。同步发送虽然多等一个网络往返但逻辑最简单直接返回成功就是消息到达并保存了返回失败就进重试。如果追求吞吐可以换异步发送但一定要在回调里认真处理失败分支并且把异常埋点、告警全部接上不能打完一行日志就完事。2.2 第二层防线重试兜底宁可重复也别静默消失第一层防线只能解决“能识别出失败”接下来还要解决“失败了怎么办”。最常见的手段是重试发送失败后隔一段时间再发。但重试不是无脑重发要设计好重试次数、退避策略和上限。比如网络故障一般几秒内恢复可以用指数退避1 秒、2 秒、4 秒最多重试 3 到 5 次如果 Broker 长时间不可用重试再多也是浪费资源应该把消息保存起来等待后台补偿任务处理。工程上比较实用的一套方案是本地消息表也叫 outbox 模式。做法是在业务数据库里建一张 outbox 消息表业务操作和消息表写入放在同一个数据库事务里。事务提交后由定时任务扫描那些还没成功发送的消息调用 MQ 客户端发送发送成功再把消息状态更新为已发送。RocketMQ 的事务消息也是类似思路通过 half message 和本地事务状态提交做最终一致性。表结构大概长这样CREATE TABLE outbox_message ( id BIGINT PRIMARY KEY AUTO_INCREMENT, msg_id VARCHAR(64) NOT NULL UNIQUE, topic VARCHAR(128) NOT NULL, payload TEXT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待发送 1已发送, retry_count INT NOT NULL DEFAULT 0, next_retry_time DATETIME NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP );为什么要搞这么重因为单纯依赖 MQ 客户端的重试有个盲区进程可能在发送之前就崩了或者业务代码里忘了调用发送 API这些问题客户端重试解决不了。本地消息表相当于给“发送动作”加了一个持久化级别的状态机不管进程怎么重启只要数据库里还有未发送的记录补偿任务就能把消息捞回来。这一层最容易忽略的问题是重复。生产者重试发送Broker 很可能已经收到了只是应答丢了于是同一条业务消息会被发送两次。所以从第二层防线开始我们必须接受一个事实消息可能是重复的。解决方案是给每条消息生成全局唯一 ID在消费端做幂等处理。这个设计不是锦上添花而是消息可靠性的地基后面第七层防线会专门应对。3. 中间堡垒Broker 的三层防御最硬核但也最容易出错3.1 第三层防线消息落盘内存里的数据不是你的数据到了 Broker 这一层很多人觉得消息已经安全了其实未必。消息到达 Broker 后首先进入内存和操作系统的 PageCache。PageCache 写入速度很快但它是易失的进程崩溃或者断电里面的数据直接消失。要让消息从瞬时数据变成持久数据必须把它写到磁盘上。不同中间件的存储结构不一样Kafka 把每个分区的消息顺序写到 log segment 文件RocketMQ 把所有主题的消息顺序写进 CommitLog再通过异步构建 ConsumeQueue 方便消费查找。虽然细节不同但核心都是顺序写磁盘利用磁盘顺序 IO 的高吞吐能力来兼顾性能和持久性。这里有个很关键的认知写进 PageCache 并不等于写进磁盘。Kafka 的默认刷盘策略依赖操作系统简单说就是数据先落在 PageCache由操作系统在合适的时机刷到磁盘RocketMQ 提供同步刷盘和异步刷盘两种模式。如果 Broker 进程在这期间崩溃PageCache 里没刷到磁盘的消息就会丢。对于“绝对不丢”的业务刷盘策略不能只依赖系统默认。3.2 第四层防线刷盘策略在性能和安全之间做选择刷盘策略是 Broker 层最常见的权衡点。同步刷盘指的是每条消息写入后等消息真正落盘、磁盘返回写入成功才向生产者确认“我收到了”。异步刷盘则是先返回成功攒一批数据后在后台批量刷盘。同步刷盘最稳最多丢正在刷盘的那一小条但性能受磁盘 IO 瓶颈限制异步刷盘吞吐高但宕机窗口内可能丢一批消息。我见过的稳妥做法是分级对待核心交易链路用同步刷盘日志、埋点一类可以容忍极少量丢失的数据用异步刷盘靠多副本兜底。另外如果用了 RAID 卡要确认写缓存有没有电池保护。很多磁盘阵列默认开了写缓存断电时如果没有 BBU 电池缓存里的数据照样保不住。这块属于基础设施层面一般不容易查但对“不丢”的最终效果影响非常大。还要提醒一个容易踩的坑刷盘配置不是全局统一的。Kafka 里有log.flush.interval.messages和log.flush.interval.ms显式设置成同步刷盘会带来严重的性能问题所以大多数人还是让操作系统自己刷RocketMQ 的flushDiskType配置成SYNC_FLUSH才表示同步刷盘。你最好在压测环境里实测一下同步刷盘对吞吐的影响再决定哪些 topic 用哪种方式而不是所有业务一把梭。3.3 第五层防线主从复制单机故障时保住最后一口气只落盘还不够单机磁盘会坏机器也可能直接挂掉。要保证消息不丢必须把数据复制到多个节点。Kafka 里是分区多副本RocketMQ 里是 Master/Slave。复制方式一般分同步复制和异步复制。异步复制下如果 Master 写成功并向生产者返回成功但还没来得及把消息同步给 SlaveMaster 就挂了新选出的节点里缺了这条消息等于丢失。同步复制会等所有副本都成功写入后再给生产者确认但写入延迟会显著增加还会因为一个慢副本拖累整个集群。工程上最常用的平衡点是 Kafka 的 ISR 机制生产者设置 acksall同时设置min.insync.replicas2表示 ISR 中至少两个副本写完才返回成功。这样只要 ISR 里还有至少一个副本存活数据就还在。另外unclean.leader.election一定要设成 false否则当 leader 副本不在线时Kafka 会选一个没跟上数据的副本当 leader这可能丢掉所有未同步的消息。这是很多“消息明明丢了但找不到原因”的幕后真凶。RocketMQ 也有类似取舍。同步复制配合同步刷盘能在单 Master 挂掉时不丢消息但性能折损明显如果承受不了就异步复制配合多副本和监控至少把丢失概率降到很低然后用消费端幂等和业务对账兜底。到这一步Broker 侧的三道防线就齐了落盘防进程崩溃刷盘策略防断电多副本防单点故障。但这三层都是存储视角的防御真正决定消息最后能不能被业务正确消费还要看消费者这一头。4. 终点收口消费者端的最后两层防线4.1 第六层防线手动提交偏移量处理成功才算“已消费”消费者端的丢消息绝大多数和 offset 的提交时机有关。Broker 不会主动知道你的业务有没有处理成功它只根据消费者提交的 offset 决定下次从哪里继续投递。如果你用自动提交 offset客户端会在拉取到消息后很快提交业务的处理结果它根本不关心。这个时候你的消费代码抛异常、进程崩溃、超时消息都不会再投递过来从业务视角看就是丢了。所以第六层防线的做法很直接关闭自动提交在业务处理成功之后再手动提交偏移量。以 Kafka 为例把enable.auto.commit设为 false在确认业务逻辑成功之后调用commitSync。RocketMQ 的消费者默认是消费成功后向 Broker 返回 CONSUME_SUCCESS处理失败可以返回 RECONSUME_LATER让消息延迟重试。这里有几个细节值得注意。第一尽量不要让消息处理跨越太多异步边界在线程池里处理完然后在另一个线程里提交 offset 特别容易出问题最好是在同一个线程内处理完并提交。第二要区分可重试失败和不可重试失败。比如下游系统暂时返回 503属于可重试消息反序列化异常、业务参数非法属于不可重试重试多少次结果都一样应该直接记录并投递到死信队列或者交给告警人工介入避免无限重试占住队列。还有一个容易踩的坑是消费者组重平衡。消费者实例增减、心跳超时都会触发 rebalance如果位移还没提交rebalance 后新的消费者可能重复消费或者从头消费。手动提交 offset 只能解决提交时机解决不了“处理到一半被踢出组”的问题所以还要关注消费线程和 poll 循环的配合避免某个分区长时间没有 poll 导致被判定为故障而移出消费者组。4.2 第七层防线幂等消费与重试兜底让重复消息无痛化前面已经铺垫过了生产者重试、Broker 主从切换、消费者处理失败后重新投递都可能导致同一条消息被消费多次。如果你不接受“消息可能重复”这个事实第七层防线就无从谈起。这一层的目标不是消灭重复而是让重复变得无害不管消息来几次业务最终状态都是一致的。最常用的幂等方案有三类。第一数据库唯一约束。比如处理支付回调时在支付流水表上建立消息唯一键或者业务订单号的唯一索引插入冲突就说明已经处理过直接忽略。第二Redis 去重或者业务状态位校验。用 SETNX 占位或者检查订单状态是不是已经变成“已支付”如果已经处理过就跳过。第三把幂等键设计成业务维度而不仅是消息 ID因为不同消息可能操作同一条业务记录只要最终状态一致消息重复就不算问题。在重试和兜底上建议给每条消息设置最大重试次数。RocketMQ 默认重试 16 次后进入死信队列Kafka 需要自己做延迟重试和死信 topic。死信队列不是给消息判死刑而是把长时间处理不了的消息隔离出来配上告警、加一个人工处理工具。这样系统既不会因为无限重试阻塞也不会让问题消息无声消失。第七层防线补上之后整条链路的 7 层防线才算完整。5. 7 层防线落地方案配置清单与踩坑实录5.1 可抄作业的可靠性配置清单前面的原理讲再多最后还是要落到配置和实施上。我把这 7 层防线整理成了一张表方便你按图索骥防线所处环节核心机制推荐配置主要代价第一层生产者发送确认Kafka 用 acksallRocketMQ 同步发送并检查 SendResult 状态每次发送多一个网络往返第二层生产者重试 本地消息表/事务消息重试 3~5 次指数退避发前落库状态机消息携带全局唯一 ID额外存储与代码复杂度第三层Broker持久化落盘正常日志/CommitLog 存储禁止纯内存模式磁盘空间与 IO 成本第四层Broker刷盘策略关键业务同步刷盘高吞吐业务异步刷盘 副本兜底RAID 带 BBU同步刷盘降低写入吞吐第五层Broker多副本同步副本数 ≥ 3min.insync.replicas ≥ 2禁用 unclean 选主写入延迟明显上涨第六层消费者手动提交偏移量enable.auto.commitfalse业务处理成功后 commitSync代码必须显式处理提交第七层消费者幂等 死信幂等表重试次数上限DLQ 告警额外存储与开发成本这份清单看起来东西很多但真正实施时不用一股脑全上。你要做的第一步是先梳理出核心链路把必须不丢的消息单独拎出来按上面表格逐层配置非核心业务可以降低刷盘和副本等级。关键是每一层都要有对应的监控指标否则防线只是纸上谈兵。如果你用 Kafka一个比较可靠的起点配置大概是这样的# 生产者可靠性关键配置 acksall retries5 enable.idempotencetrue max.in.flight.requests.per.connection1 # 消费者可靠性关键配置 enable.auto.commitfalse auto.offset.resetearliestenable.idempotence让生产者在 Broker 侧自动去重max.in.flight.requests.per.connection限制乱序这些和生产者的重试机制配合起来能避免“重试导致顺序错乱”的问题。5.2 三次真实丢消息事故的排查复盘第一个案例生产端用了异步发送回调里只打了日志没有接告警。某天 Broker 磁盘写满大量发送失败日志文件躺在服务器上没人看。等发现时业务数据已经缺了一批。排查后发现异步回调里确实有 log.error但生产环境日志级别是 WARN错误被淹没了都没人注意到。从那次以后团队所有消息发送失败都强制接监控指标和告警而不只是一行日志。第二个案例消费端启用了自动提交。数据库偶发死锁处理超时异常被外层捕获后吞掉消息没被正确处理但 offset 已经自动提交。重启消费者后那批消息再也没有出现。排查时看消费组 lag 是 0数据在业务库里却查不到。这个案例说明自动提交本质上把“消费成功”和“处理成功”混为一谈业务消息里必须关闭。第三个案例Kafka 两个副本某一分区 leader 所在节点磁盘故障。集群里 unclean.leader.election 被之前的配置改成了允许于是选了一个落后很多的 follower 当 leadertopic 里最近几千条消息全丢了。排查时客户端没有任何异常因为生产者只设置了 acks1。后来把关键 topic 的 acks 改成 allmin.insync.replicas 调到 2把 unclean 选主关掉才算真正稳住。排查路径一般是这个顺序先看生产端有没有发送失败和重试记录再看 Broker 日志有没有磁盘、复制相关异常消息轨迹有没有记录最后看消费者组 lag 和 commit 情况。建议在生产环境开启 MQ 的消息轨迹能力不然事后排查全靠猜效率很低。5.3 常见问题速查表现象可能原因排查方向建议生产者显示成功消费者始终没收到Broker 写盘/复制失败但发回成功查看发送结果状态、Broker 磁盘和副本健康检查 acks、同步刷盘、复制配置重启 Broker 后丢消息PageCache 未刷盘查看 Broker 启动时间和最后一次刷盘点关键业务开同步刷盘主从切换后消费重复或丢失异步复制、unclean 选主查看 ISR、复制滞后、选主记录设置 min.insync.replicas禁用 unclean同一业务消息被处理多次生产者重试/重平衡/重投递查看消息 ID 与消费日志建立幂等表或状态机消费组 lag 为 0但业务缺数据自动提交 offset处理失败被跳过查看消费者配置与处理异常日志改手动提交处理成功再 commit无限重试把消费者打挂未区分可重试异常查看消费者日志中的异常类型分类处理超限进死信队列6. 关于 7 层防线的一点题外话成本与取舍6.1 每加一层防线都在用成本换安全感有人可能会问既然有这么多防线是不是全都打开就万事大吉不是的。同步刷盘加同步复制加 acksall会把写入延迟从几毫秒拉到几十毫秒对高吞吐的日志系统来说是灾难。可靠性的本质不是“技术能不能实现”而是“业务愿意为不丢付出多大代价”。我习惯把 topic 分成三类P0 核心交易、P1 普通业务、P2 数据埋点。P0 直接跑满七层哪怕延迟从 3ms 涨到 30ms 也接受P1 开生产者重试、手动 ACK、异步刷盘加多副本允许极低概率丢失但用对账来补P2 走最轻配置甚至允许丢一部分。分类之后你会发现真正需要满配的 topic 其实没多少成本和收益完全可以平衡。6.2 消息不丢失的终极兜底藏在业务侧对账里最后说一个很多人忽略的点技术上的 7 层防线即便全部到位也只能把丢失概率降到极低不能保证绝对为零。真正能挽回损失的是在业务侧建立对账机制。比如每天定时统计“业务表里应该出现的消息数量”和“消息队列里实际处理的数量”对不上就告警或者消费端每处理一条消息写一条落地记录定期和上游业务系统对账单。这套兜底不依赖中间件哪怕真有一层防线失效也能通过补单任务把消息找回来。我自己在团队里推动的底线是技术方案把丢消息从“常态”变成“罕见”对账体系负责把“罕见”变成“可控”。如果你正在被消息丢失的问题折磨先不要急着抄更多配置而是想清楚核心链路到底能不能承受一条消息消失的后果然后在 7 层防线里选择那几层必须用的同时把业务对账补上。这样即便运气不好也能在最短时间内发现问题并恢复。
消息不丢失的7层防线：生产到消费全链路可靠性实践
有没有经历过这种凌晨三点被电话叫醒的场景线上订单支付成功用户收到了扣款短信但业务订单状态一直停在待支付。查到最后发现一条关键的消息在链路里消失了。消息不丢失是使用消息队列之后最容易被低估的问题很多人一开始只关心吞吐量和延迟真正上线跑着跑着才开始面对从生产者到 Broker 再到消费者的一场又一场丢消息事故。经典的生产者消费者问题教科书里讨论的是多线程下的同步与协作等落到工程上问题要复杂得多——不光要解耦还要保证消息不丢、不重、不乱序。今天这篇文章就把消息从产生到消费的整条链路拆开逐层布防整理成一套可以直接落地的 7 层防线。无论你是后端开发、中间件运维还是正在做系统架构都应该把这七层防线装进自己的技术清单里。1. 丢消息的真相先弄懂一条消息的完整旅程1.1 一条消息从诞生到被消费经过了多少个关卡一条消息不是从代码里 new 出来就直接进了消费者业务代码的。它至少要经过一段很长的旅程业务系统在本地组装消息体、序列化通过网络客户端发送给消息中间件Broker 收到网络包后把数据写进内存和 PageCache再异步或同步刷到磁盘为了让数据在单机故障时不丢Broker 还要把数据复制到其他节点消费者通过拉取或推送拿到消息先反序列化再执行业务逻辑最后向 Broker 汇报“这条消息我处理完了”。到这里一条消息才算真正完成使命。这段旅程里的每一段都可能出问题。网络抖动可能让生产端发送超时Broker 刷盘前宕机可能让内存里的消息蒸发主从复制滞后可能让切换时丢数据消费者处理完了但没有正确提交位移可能在重平衡之后又被重复消费或者在处理失败后直接被跳过。消息丢失从来不是“某个环节做错了”这么简单它往往是几个环节的小概率事件叠加在一起才爆发的。1.2 最容易丢消息的三个地段发送、存储、消费我把丢消息的高发地段分成三大类后文所有防线都围绕这三类展开。第一类发送段。生产者把消息发给 Broker网络闪断、发送超时、Broker 临时拒绝服务任何一种情况都可能让消息没有被 Broker 确认。这里最难受的是“超时到底算成功还是失败”客户端发出去了Broker 也收到了但应答在网络里丢了客户端以为失败而重试就会重复客户端没发出去Broker 当然也没收到如果不处理消息就丢了。第二类存储段。消息到达 Broker 不代表就安全了。如果消息只停留在内存或 PageCacheBroker 进程崩溃或者机器断电这部分数据就没了。即使已经落盘单机硬盘坏了也会丢。所以存储段的核心问题是数据要同时在持久化设备和第二个节点上各留一份并且要在确认“留成功”之后才向客户端报成功。第三类消费段。消费者拿到消息业务逻辑还没跑完进程挂了、抛异常了、消费者组发生重平衡了都有可能把这条消息漏掉。最经典的场景就是用自动提交 offset消息一拉下来就提交位移结果业务处理失败消息再也不会被投递。消费段有一条铁律Broker 不关心你的业务是否成功它只关心你什么时候说成功。理解这一点后面第六、第七层防线就有了根基。2. 源头布防生产者端的前两层防线2.1 第一层防线发送确认机制别把“发出去”当成“送达”很多丢消息事故的起点是对“发送”这件事的理解太乐观。消息发出去了TCP 连接断没断、对端收到没收到、数据写成功没有这些都需要靠发送确认机制来回答。不同中间件机制叫法不一样但思路一致生产者要能拿到一个“送达回执”并根据回执决定下一步动作。以 Kafka 为例生产端有一个 acks 参数取值范围是 0、1、all也就是 -1。acks0 表示发送出去就不管了只要 TCP 能写就认为成功Broker 是否收到无从得知。acks1 表示 leader 写入本地就当成功但 leader 挂了并且副本没跟上时会丢。acksall 表示要等所有 ISR 副本都写入后才算成功这是业务消息可靠性的基本要求。RocketMQ 的同步发送会返回一个 SendResult里面有发送状态常见的有 SEND_OK、FLUSH_DISK_TIMEOUT、FLUSH_REMOTE_TIMEOUT、SLAVE_NOT_AVAILABLE。很多人只看 SEND_OK其他状态要么没判断要么当成成功处理这种习惯同样会漏消息。FLUSH_DISK_TIMEOUT 和 FLUSH_REMOTE_TIMEOUT 都意味着 Broker 没有完成保存性质上不应该当作成功。实际操作里我最推荐“同步发送 明确的状态检查”作为默认方案。同步发送虽然多等一个网络往返但逻辑最简单直接返回成功就是消息到达并保存了返回失败就进重试。如果追求吞吐可以换异步发送但一定要在回调里认真处理失败分支并且把异常埋点、告警全部接上不能打完一行日志就完事。2.2 第二层防线重试兜底宁可重复也别静默消失第一层防线只能解决“能识别出失败”接下来还要解决“失败了怎么办”。最常见的手段是重试发送失败后隔一段时间再发。但重试不是无脑重发要设计好重试次数、退避策略和上限。比如网络故障一般几秒内恢复可以用指数退避1 秒、2 秒、4 秒最多重试 3 到 5 次如果 Broker 长时间不可用重试再多也是浪费资源应该把消息保存起来等待后台补偿任务处理。工程上比较实用的一套方案是本地消息表也叫 outbox 模式。做法是在业务数据库里建一张 outbox 消息表业务操作和消息表写入放在同一个数据库事务里。事务提交后由定时任务扫描那些还没成功发送的消息调用 MQ 客户端发送发送成功再把消息状态更新为已发送。RocketMQ 的事务消息也是类似思路通过 half message 和本地事务状态提交做最终一致性。表结构大概长这样CREATE TABLE outbox_message ( id BIGINT PRIMARY KEY AUTO_INCREMENT, msg_id VARCHAR(64) NOT NULL UNIQUE, topic VARCHAR(128) NOT NULL, payload TEXT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待发送 1已发送, retry_count INT NOT NULL DEFAULT 0, next_retry_time DATETIME NOT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP );为什么要搞这么重因为单纯依赖 MQ 客户端的重试有个盲区进程可能在发送之前就崩了或者业务代码里忘了调用发送 API这些问题客户端重试解决不了。本地消息表相当于给“发送动作”加了一个持久化级别的状态机不管进程怎么重启只要数据库里还有未发送的记录补偿任务就能把消息捞回来。这一层最容易忽略的问题是重复。生产者重试发送Broker 很可能已经收到了只是应答丢了于是同一条业务消息会被发送两次。所以从第二层防线开始我们必须接受一个事实消息可能是重复的。解决方案是给每条消息生成全局唯一 ID在消费端做幂等处理。这个设计不是锦上添花而是消息可靠性的地基后面第七层防线会专门应对。3. 中间堡垒Broker 的三层防御最硬核但也最容易出错3.1 第三层防线消息落盘内存里的数据不是你的数据到了 Broker 这一层很多人觉得消息已经安全了其实未必。消息到达 Broker 后首先进入内存和操作系统的 PageCache。PageCache 写入速度很快但它是易失的进程崩溃或者断电里面的数据直接消失。要让消息从瞬时数据变成持久数据必须把它写到磁盘上。不同中间件的存储结构不一样Kafka 把每个分区的消息顺序写到 log segment 文件RocketMQ 把所有主题的消息顺序写进 CommitLog再通过异步构建 ConsumeQueue 方便消费查找。虽然细节不同但核心都是顺序写磁盘利用磁盘顺序 IO 的高吞吐能力来兼顾性能和持久性。这里有个很关键的认知写进 PageCache 并不等于写进磁盘。Kafka 的默认刷盘策略依赖操作系统简单说就是数据先落在 PageCache由操作系统在合适的时机刷到磁盘RocketMQ 提供同步刷盘和异步刷盘两种模式。如果 Broker 进程在这期间崩溃PageCache 里没刷到磁盘的消息就会丢。对于“绝对不丢”的业务刷盘策略不能只依赖系统默认。3.2 第四层防线刷盘策略在性能和安全之间做选择刷盘策略是 Broker 层最常见的权衡点。同步刷盘指的是每条消息写入后等消息真正落盘、磁盘返回写入成功才向生产者确认“我收到了”。异步刷盘则是先返回成功攒一批数据后在后台批量刷盘。同步刷盘最稳最多丢正在刷盘的那一小条但性能受磁盘 IO 瓶颈限制异步刷盘吞吐高但宕机窗口内可能丢一批消息。我见过的稳妥做法是分级对待核心交易链路用同步刷盘日志、埋点一类可以容忍极少量丢失的数据用异步刷盘靠多副本兜底。另外如果用了 RAID 卡要确认写缓存有没有电池保护。很多磁盘阵列默认开了写缓存断电时如果没有 BBU 电池缓存里的数据照样保不住。这块属于基础设施层面一般不容易查但对“不丢”的最终效果影响非常大。还要提醒一个容易踩的坑刷盘配置不是全局统一的。Kafka 里有log.flush.interval.messages和log.flush.interval.ms显式设置成同步刷盘会带来严重的性能问题所以大多数人还是让操作系统自己刷RocketMQ 的flushDiskType配置成SYNC_FLUSH才表示同步刷盘。你最好在压测环境里实测一下同步刷盘对吞吐的影响再决定哪些 topic 用哪种方式而不是所有业务一把梭。3.3 第五层防线主从复制单机故障时保住最后一口气只落盘还不够单机磁盘会坏机器也可能直接挂掉。要保证消息不丢必须把数据复制到多个节点。Kafka 里是分区多副本RocketMQ 里是 Master/Slave。复制方式一般分同步复制和异步复制。异步复制下如果 Master 写成功并向生产者返回成功但还没来得及把消息同步给 SlaveMaster 就挂了新选出的节点里缺了这条消息等于丢失。同步复制会等所有副本都成功写入后再给生产者确认但写入延迟会显著增加还会因为一个慢副本拖累整个集群。工程上最常用的平衡点是 Kafka 的 ISR 机制生产者设置 acksall同时设置min.insync.replicas2表示 ISR 中至少两个副本写完才返回成功。这样只要 ISR 里还有至少一个副本存活数据就还在。另外unclean.leader.election一定要设成 false否则当 leader 副本不在线时Kafka 会选一个没跟上数据的副本当 leader这可能丢掉所有未同步的消息。这是很多“消息明明丢了但找不到原因”的幕后真凶。RocketMQ 也有类似取舍。同步复制配合同步刷盘能在单 Master 挂掉时不丢消息但性能折损明显如果承受不了就异步复制配合多副本和监控至少把丢失概率降到很低然后用消费端幂等和业务对账兜底。到这一步Broker 侧的三道防线就齐了落盘防进程崩溃刷盘策略防断电多副本防单点故障。但这三层都是存储视角的防御真正决定消息最后能不能被业务正确消费还要看消费者这一头。4. 终点收口消费者端的最后两层防线4.1 第六层防线手动提交偏移量处理成功才算“已消费”消费者端的丢消息绝大多数和 offset 的提交时机有关。Broker 不会主动知道你的业务有没有处理成功它只根据消费者提交的 offset 决定下次从哪里继续投递。如果你用自动提交 offset客户端会在拉取到消息后很快提交业务的处理结果它根本不关心。这个时候你的消费代码抛异常、进程崩溃、超时消息都不会再投递过来从业务视角看就是丢了。所以第六层防线的做法很直接关闭自动提交在业务处理成功之后再手动提交偏移量。以 Kafka 为例把enable.auto.commit设为 false在确认业务逻辑成功之后调用commitSync。RocketMQ 的消费者默认是消费成功后向 Broker 返回 CONSUME_SUCCESS处理失败可以返回 RECONSUME_LATER让消息延迟重试。这里有几个细节值得注意。第一尽量不要让消息处理跨越太多异步边界在线程池里处理完然后在另一个线程里提交 offset 特别容易出问题最好是在同一个线程内处理完并提交。第二要区分可重试失败和不可重试失败。比如下游系统暂时返回 503属于可重试消息反序列化异常、业务参数非法属于不可重试重试多少次结果都一样应该直接记录并投递到死信队列或者交给告警人工介入避免无限重试占住队列。还有一个容易踩的坑是消费者组重平衡。消费者实例增减、心跳超时都会触发 rebalance如果位移还没提交rebalance 后新的消费者可能重复消费或者从头消费。手动提交 offset 只能解决提交时机解决不了“处理到一半被踢出组”的问题所以还要关注消费线程和 poll 循环的配合避免某个分区长时间没有 poll 导致被判定为故障而移出消费者组。4.2 第七层防线幂等消费与重试兜底让重复消息无痛化前面已经铺垫过了生产者重试、Broker 主从切换、消费者处理失败后重新投递都可能导致同一条消息被消费多次。如果你不接受“消息可能重复”这个事实第七层防线就无从谈起。这一层的目标不是消灭重复而是让重复变得无害不管消息来几次业务最终状态都是一致的。最常用的幂等方案有三类。第一数据库唯一约束。比如处理支付回调时在支付流水表上建立消息唯一键或者业务订单号的唯一索引插入冲突就说明已经处理过直接忽略。第二Redis 去重或者业务状态位校验。用 SETNX 占位或者检查订单状态是不是已经变成“已支付”如果已经处理过就跳过。第三把幂等键设计成业务维度而不仅是消息 ID因为不同消息可能操作同一条业务记录只要最终状态一致消息重复就不算问题。在重试和兜底上建议给每条消息设置最大重试次数。RocketMQ 默认重试 16 次后进入死信队列Kafka 需要自己做延迟重试和死信 topic。死信队列不是给消息判死刑而是把长时间处理不了的消息隔离出来配上告警、加一个人工处理工具。这样系统既不会因为无限重试阻塞也不会让问题消息无声消失。第七层防线补上之后整条链路的 7 层防线才算完整。5. 7 层防线落地方案配置清单与踩坑实录5.1 可抄作业的可靠性配置清单前面的原理讲再多最后还是要落到配置和实施上。我把这 7 层防线整理成了一张表方便你按图索骥防线所处环节核心机制推荐配置主要代价第一层生产者发送确认Kafka 用 acksallRocketMQ 同步发送并检查 SendResult 状态每次发送多一个网络往返第二层生产者重试 本地消息表/事务消息重试 3~5 次指数退避发前落库状态机消息携带全局唯一 ID额外存储与代码复杂度第三层Broker持久化落盘正常日志/CommitLog 存储禁止纯内存模式磁盘空间与 IO 成本第四层Broker刷盘策略关键业务同步刷盘高吞吐业务异步刷盘 副本兜底RAID 带 BBU同步刷盘降低写入吞吐第五层Broker多副本同步副本数 ≥ 3min.insync.replicas ≥ 2禁用 unclean 选主写入延迟明显上涨第六层消费者手动提交偏移量enable.auto.commitfalse业务处理成功后 commitSync代码必须显式处理提交第七层消费者幂等 死信幂等表重试次数上限DLQ 告警额外存储与开发成本这份清单看起来东西很多但真正实施时不用一股脑全上。你要做的第一步是先梳理出核心链路把必须不丢的消息单独拎出来按上面表格逐层配置非核心业务可以降低刷盘和副本等级。关键是每一层都要有对应的监控指标否则防线只是纸上谈兵。如果你用 Kafka一个比较可靠的起点配置大概是这样的# 生产者可靠性关键配置 acksall retries5 enable.idempotencetrue max.in.flight.requests.per.connection1 # 消费者可靠性关键配置 enable.auto.commitfalse auto.offset.resetearliestenable.idempotence让生产者在 Broker 侧自动去重max.in.flight.requests.per.connection限制乱序这些和生产者的重试机制配合起来能避免“重试导致顺序错乱”的问题。5.2 三次真实丢消息事故的排查复盘第一个案例生产端用了异步发送回调里只打了日志没有接告警。某天 Broker 磁盘写满大量发送失败日志文件躺在服务器上没人看。等发现时业务数据已经缺了一批。排查后发现异步回调里确实有 log.error但生产环境日志级别是 WARN错误被淹没了都没人注意到。从那次以后团队所有消息发送失败都强制接监控指标和告警而不只是一行日志。第二个案例消费端启用了自动提交。数据库偶发死锁处理超时异常被外层捕获后吞掉消息没被正确处理但 offset 已经自动提交。重启消费者后那批消息再也没有出现。排查时看消费组 lag 是 0数据在业务库里却查不到。这个案例说明自动提交本质上把“消费成功”和“处理成功”混为一谈业务消息里必须关闭。第三个案例Kafka 两个副本某一分区 leader 所在节点磁盘故障。集群里 unclean.leader.election 被之前的配置改成了允许于是选了一个落后很多的 follower 当 leadertopic 里最近几千条消息全丢了。排查时客户端没有任何异常因为生产者只设置了 acks1。后来把关键 topic 的 acks 改成 allmin.insync.replicas 调到 2把 unclean 选主关掉才算真正稳住。排查路径一般是这个顺序先看生产端有没有发送失败和重试记录再看 Broker 日志有没有磁盘、复制相关异常消息轨迹有没有记录最后看消费者组 lag 和 commit 情况。建议在生产环境开启 MQ 的消息轨迹能力不然事后排查全靠猜效率很低。5.3 常见问题速查表现象可能原因排查方向建议生产者显示成功消费者始终没收到Broker 写盘/复制失败但发回成功查看发送结果状态、Broker 磁盘和副本健康检查 acks、同步刷盘、复制配置重启 Broker 后丢消息PageCache 未刷盘查看 Broker 启动时间和最后一次刷盘点关键业务开同步刷盘主从切换后消费重复或丢失异步复制、unclean 选主查看 ISR、复制滞后、选主记录设置 min.insync.replicas禁用 unclean同一业务消息被处理多次生产者重试/重平衡/重投递查看消息 ID 与消费日志建立幂等表或状态机消费组 lag 为 0但业务缺数据自动提交 offset处理失败被跳过查看消费者配置与处理异常日志改手动提交处理成功再 commit无限重试把消费者打挂未区分可重试异常查看消费者日志中的异常类型分类处理超限进死信队列6. 关于 7 层防线的一点题外话成本与取舍6.1 每加一层防线都在用成本换安全感有人可能会问既然有这么多防线是不是全都打开就万事大吉不是的。同步刷盘加同步复制加 acksall会把写入延迟从几毫秒拉到几十毫秒对高吞吐的日志系统来说是灾难。可靠性的本质不是“技术能不能实现”而是“业务愿意为不丢付出多大代价”。我习惯把 topic 分成三类P0 核心交易、P1 普通业务、P2 数据埋点。P0 直接跑满七层哪怕延迟从 3ms 涨到 30ms 也接受P1 开生产者重试、手动 ACK、异步刷盘加多副本允许极低概率丢失但用对账来补P2 走最轻配置甚至允许丢一部分。分类之后你会发现真正需要满配的 topic 其实没多少成本和收益完全可以平衡。6.2 消息不丢失的终极兜底藏在业务侧对账里最后说一个很多人忽略的点技术上的 7 层防线即便全部到位也只能把丢失概率降到极低不能保证绝对为零。真正能挽回损失的是在业务侧建立对账机制。比如每天定时统计“业务表里应该出现的消息数量”和“消息队列里实际处理的数量”对不上就告警或者消费端每处理一条消息写一条落地记录定期和上游业务系统对账单。这套兜底不依赖中间件哪怕真有一层防线失效也能通过补单任务把消息找回来。我自己在团队里推动的底线是技术方案把丢消息从“常态”变成“罕见”对账体系负责把“罕见”变成“可控”。如果你正在被消息丢失的问题折磨先不要急着抄更多配置而是想清楚核心链路到底能不能承受一条消息消失的后果然后在 7 层防线里选择那几层必须用的同时把业务对账补上。这样即便运气不好也能在最短时间内发现问题并恢复。
