你大概率遇到过这个场景上游系统返回发送成功消费者服务也没有任何异常日志但最终落库的记录就是少了。线上排查半天最后发现消息在某个环节被悄悄丢了。这类问题在 Java 面试里被包装成一个固定题目——“RabbitMQ 消息投递失联”属于场景题里的重灾区。很多候选人能背出 confirm、ack、持久化这些关键词但真被问到“现在消息丢了你怎么定位”就会卡住。原因很简单他背的是配置而面试官问的是消息投递整条链路的可观测性。配置是静态的链路排查才是动态的。能把这二者打通才是这道题真正想考察的东西。这篇文章就从面试角度入手把“投递失联”拆开讲清楚消息会丢在哪一段每一段靠什么机制兜底出了问题按什么顺序排查以及面试时怎么回答才不像背八股。1. 先搞懂“投递失联”到底丢在哪一段1.1 消息从生产到消费其实隔着三段路由RabbitMQ 不是生产者直接把消息塞给消费者。一条消息从产生到被业务处理中间要经过三段第一段生产者把消息发送到交换机exchange。第二段交换机根据路由键把消息路由到绑定的队列queue。第三段消费者从队列拉取消息完成业务处理再确认消息。前两段属于“投递”第三段属于“消费”。很多人排查消息丢失只盯着第一段有没有发送成功忽略了后面还有两段。实际上任何一段出问题都会表现为“消息不见了”但不一定会有报错。这条链路有一个非常容易被忽略的特点默认状态下每一步都可能静默丢弃。生产者 send 成功只表示数据写到了 TCP 连接的缓冲区不表示交换机已经接收交换机收到消息但路由键匹配不到任何队列消息默认会被直接丢弃消费者拉取到消息后如果开启自动 ack哪怕业务逻辑抛异常消息也会被标记为已完成。所以“投递失联”这个说法本质上是在描述一种不可见的状态消息没有出现在它该出现的位置但也没有任何环节明确告诉你“它失败了”。1.2 失联有两种长相排查思路完全不同第一种长相消息从头到尾就没有到达消费者。它可能根本没发到交换机也可能到了交换机但路由失败被丢弃。这种失联消费者端的日志永远是干净的数据库里也永远不会有这条记录。第二种长相消息已经进入了队列消费者也拉取到了但业务处理失败。如果代码没有正确返回 ack/nack或者用了自动 ack 又把异常吞掉了消息就会从队列里消失而业务结果并没有落库。这两类问题在表现上非常像没有报错数据缺失。但排查方向完全不同。第一类要查生产者、交换机、路由键、绑定关系第二类要查消费者代码、异常处理、ack 逻辑。很多人一上来就翻 RabbitMQ 日志翻半天也找不到原因就是因为没有先判断“消息到底有没有进队列”。1.3 面试官出这道题不想听你背配置这道题之所以成为面试重灾区是因为它表面考配置实际考排查链路。面试官想看到的是你知道一条消息要经过哪几段你知道每一段默认有什么风险你知道靠什么机制把风险暴露出来你知道问题出来后按什么顺序定位。如果只回答“开启生产者确认开启手动 ack开启持久化”这只能算及格。真正能拉开的差距是你能不能把每一段的风险、机制、边界串成一条完整的排查链路。2. 把每一跳都改造成“有回执”的投递2.1 第一跳生产者到交换机必须开 publisher confirmRabbitMQ 提供了一种机制让生产者可以确认消息是否被交换机接收这就是 publisher confirm。开启后生产者发送消息时会得到一个回调acktrue 表示交换机已接收ackfalse 表示交换机拒收或写入失败。要注意这里确认的只是“到交换机为止”不包含后续的“路由到队列”。很多人在这一步产生误解以为 confirm ack 就代表消息安全落地了。实际上confirm 只覆盖了第一跳它无法感知第二跳的路由结果。如果消息路由不到任何队列confirm 依然会返回 ack因为交换机确实收到了消息。所以confirm 是必要的但不是充分的。它只是把第一跳从“不可见”变成“可见”后面还有第二跳需要单独处理。2.2 第二跳交换机到队列靠 mandatory 和 return 回调抢救消息到了交换机之后交换机要根据路由键把消息投递到绑定的队列。如果找不到匹配的队列有两种处理方式默认行为把消息直接丢弃。开启 mandatory把消息退回给生产者通过 return 回调通知。return 回调是判断“路由失败”的唯一出口。如果没开 mandatory你永远不会知道消息在第二跳被丢了开了之后至少能收到一个明确的失败信号。用一个快递类比confirm 相当于快递公司告诉你“包裹已经收件了”return 相当于发件途中发现地址无效把包裹退回给了发件人。只有收件确认没有退件提醒很多丢件你是永远发现不了的。2.3 第三跳队列到消费者手动 ack 才能知道业务结果前两跳解决的是“消息有没有进队列”第三跳解决的是“消息被消费后到底处理成功没有”。默认情况下消费者收到消息后会自动 ack消息立刻从队列里移除。如果这时候业务代码抛异常又没做捕获处理消息就没了业务也没成功。生产环境普遍改成手动 ack业务处理成功调用 basicAck业务处理失败调用 basicNack 或 basicReject既不 ack 也不 nack消息会停留在 unacked 状态不会被其他消费者拉取。手动 ack 真正解决的问题是把“消费结果”交给业务代码来判断而不是让 MQ 默认认为“拉取成功就是处理成功”。顺便要注意 prefetch 参数。它决定消费者一次性预取多少条消息。设置太大会导致消息堆积在本地设置太小又会让消费者频繁往返请求。一般先按单条消息的处理耗时来调而不是盲目设一个大值。三层链路、默认行为、风险、兜底机制可以整理成下表投递段链路范围默认风险确认/兜底机制第一跳生产者 → 交换机发送失败、交换机不存在publisher confirm第二跳交换机 → 队列路由键不匹配、无绑定队列mandatory return 回调第三跳队列 → 消费者业务异常、ack 失败、重复消费手动 ack 死信队列 幂等3. 五步排查法从“找不到原因”到“秒定位代码”面试时如果只给结论容易被追问到细节。真正实用的方法是给一套排查顺序让面试官看到你解决问题的路径。下面这套“五步排查法”同样适用于线上真实故障。3.1 第一步确认生产者有没有把消息真正发出去先看生产者的 confirm 回调如果收到 ackfalse说明交换机拒收或写入失败问题在第一跳如果回调根本没有触发可能是连接没建立、消息发送前就抛了异常、或者回调设置本身有问题如果确认 acktrue继续看第二步。这里建议在发送时带上 correlationData把消息唯一 ID 塞进去方便后续追踪。生产环境最好把确认结果落到日志或表里否则等出问题了再回看会发现什么都查不到。3.2 第二步检查路由键与绑定关系确认 acktrue 但消息依然消失大概率是第二跳出了问题。此时去管理台看三条信息交换机是否存在队列是否存在路由键和绑定关系是否匹配。特别常见的情况是生产者和消费者代码里的交换机、路由键、队列名不一致。比如测试环境用着 dev 队列生产环境配置还是 dev消息发到交换机后匹配不到队列又被丢弃这种问题不靠日志很难发现。如果 confirm 和 return 都开了这一步会在 return 回调里留下痕迹。所以排查时一定要确认这两个回调有没有真正触发过。3.3 第三步看队列里的消息状态进入 RabbitMQ 管理台的 Queues 页面关注两类数字ready队列中等待被消费的消息数量unacked已经被消费者拉取、但还没确认的消息数量。如果 ready 持续增长说明消费者没在消费或消费速度跟不上如果 unacked 持续很高说明消费者拉到了消息但一直没 ack可能是处理线程卡死也可能是代码里既没 ack 也没 nack。如果队列空了但数据库里还是没有数据就要回到消费者日志里查。还有一种可能消息被设置了 TTL过期后被清掉或者被 nack 后 requeuefalse进入了死信队列或者被直接丢弃。3.4 第四步检查消费者代码的异常处理走到这一步基本可以确定消息已经进过队列了。此时要重点查看消费者代码是用自动 ack 还是手动 ack业务处理有没有 try-catchcatch 之后有没有返回 nacknack 时 requeue 设置的是 true 还是 false。最常见的错误写法是手动 ack 开了但代码里 catch 住异常后什么都没做导致消息既不 ack 也不 nack最终 unacked 一直堆积队列被卡死。还有一种写法更隐蔽捕获异常后打印日志然后继续执行 ack等于告诉 MQ“这条消息处理成功了”。排查时先看日志印了没再看代码走了哪个分支基本能定位到具体行。3.5 第五步用监控曲线验证断点如果项目里接入了监控这一步会更高效。对比几个指标生产者 publish 速率交换机/队列的 incoming 速率消费者 deliver 速率消费者 ack 速率。publish 很高但 deliver 为零说明消息断在前两跳大概率路由没成功deliver 很高但 ack 为零说明消费者拉取后在处理阶段卡住或异常不断如果某一时刻 deliver 曲线突然跌到零同时队列 ready 也清零可能是消息被批量拒绝并且没有重投。注意不要一上来就翻代码或改配置。先看管理台和监控数据会告诉你断在哪一层。很多失联问题看曲线比看代码更直观。4. 关键代码与避坑清单面试和实际开发都有一个共识只讲机制不够还是要落到代码上。不需要复杂的例子但要把关键点写对。4.1 生产者侧confirm mandatory 缺一不可假设用的是 Spring Boot Spring AMQP常见写法是这样的结构rabbitTemplate.setMandatory(true); rabbitTemplate.setConfirmCallback((correlationData, ack, cause) - { if (!ack) { // 第一跳失败交换机没有接收记录待重发 log.error(消息发送失败correlationId{}, cause{}, correlationData.getId(), cause); } }); rabbitTemplate.setReturnsCallback(returned - { // 第二跳失败交换机路由不到队列 log.error(消息路由失败exchange{}, routingKey{}, body{}, returned.getExchange(), returned.getRoutingKey(), returned.getMessage()); });这里两个回调分别对应两个断点。confirm 接管第一跳return 接管第二跳。只配 confirm 不配 mandatory第二跳失败依然会丢只配 mandatory 不配 confirm第一跳失败你不知道。correlationData 里建议放业务唯一 ID比如订单号或消息表主键方便失败后按 ID 精确补偿。4.2 消费者侧别让业务异常变成“假成功”手动 ack 的消费者代码结构应该是这样的RabbitListener(queues order.queue) public void onMessage(Message message, Channel channel) throws Exception { long deliveryTag message.getMessageProperties().getDeliveryTag(); try { handleBusiness(message); channel.basicAck(deliveryTag, false); } catch (Exception e) { log.error(消费消息失败deliveryTag{}, deliveryTag, e); channel.basicNack(deliveryTag, false, true); } }需要特别解释的是 basicNack 的第三个参数 requeue。设为 true 会把消息重新放回队列看起来像在自动重试但实际很危险。如果业务处理一直失败消息会反复进出队列形成死循环把消费者线程和队列打满。更稳妥的做法是先记录重试次数超过阈值后 requeuefalse把消息转入死信队列由专门的补偿任务来处理。这比无限重试要可控得多。4.3 最容易踩的三个隐性坑第一个坑只开 confirm没开 mandatory。这种情况下第一跳失败能看到第二跳失败依然静默丢弃。面试里可以主动提这一点会显得你想过边界。第二个坑手动 ack 没写全。消息既不 ack 也不 nackunacked 越积越多后面所有消息都卡在队列里。这不是投递失联但比投递失联更隐蔽因为消息还在队列里只是没人能消费。第三个坑持久化不完整。RabbitMQ 的持久化要三段同时生效交换机持久化、队列持久化、消息 deliveryModePERSISTENT。只设置其中一两个MQ 一旦重启该丢的消息照样丢。提醒不要把“消息写入队列”和“消息落盘持久化”画等号。队列非持久化时消息只是暂时存在内存里重启即失联。5. 面试这样答才不像背八股5.1 推荐回答顺序现象 → 链路 → 机制 → 边界面试官问“RabbitMQ 消息投递失联你怎么排查”不建议上来就背 confirm、ack、持久化。可以按下面这个顺序回答先确认现象。消息是从未到达还是到达了但没处理成功。这一步决定了后续方向。再画链路。把消息投递拆成三段生产者到交换机、交换机到队列、队列到消费者。每一段都有各自的失败模式。再给出机制。第一段用 publisher confirm第二段用 mandatory return 回调第三段用手动 ack 和死信队列。最后补边界。confirm 只覆盖第一跳ack 只覆盖消费结果持久化只防 MQ 重启丢消息它们各自管一段组合起来才构成完整可靠性。这个回答顺序的价值在于先给路径再给方案。面试官跟着你的链路走能看出你是在想问题不是背口诀。5.2 一个能加分的判断可靠性必须成环如果只是把失败暴露出来问题还没有被解决。正确认识是confirm、return、ack 只是让失败可见真正的可靠性要靠补偿机制成环。所谓成环就是一条消息从发送到消费每个关键节点都有记录失败时有兜底最终能通过人工或定时任务对账。常见落地方案是加一张消息日志表发送前记录一条confirm 成功后更新状态消费成功后更新状态定时任务扫描长期处于中间状态的消息做补偿。面试时如果能说出这一步等于把问题从“消息队列怎么配置”拉升到了“分布式链路数据一致性怎么保证”这是很明显的认知增量。5.3 面试官可能会追问的四个方向追问一如果 confirm 回调一直没有返回该怎么办这时不能无限制等需要设置超时重试。重试达到阈值后把消息状态标记为发送失败由定时任务扫描补偿。追问二消费端处理很慢unacked 堆积严重。先判断是单个消息处理慢还是整体消费能力不足。单条消息慢检查是不是有外部调用超时没有设 timeout整体消费能力不足考虑调整 prefetch、增加并发消费者或者拆分队列。追问三消息重复消费怎么办RabbitMQ 的语义是至少一次正常情况下就可能出现重复投递。解决方案是消费端做幂等用业务唯一键防重、数据库唯一索引、状态机判断而不是依赖消息队列保证不重复。追问四数据库和 MQ 的一致性问题怎么解决常见方案是本地消息表加定时任务先写业务数据和消息表再异步发送 MQ发送成功后标记。更极端的做法是事务消息但要对具体 MQ 产品的能力做评估不是所有实现都支持。6. 从一道场景题到消息可靠性的四层模型6.1 面试题和生产环境的真实差距面试题通常只考单条链路、单个断点、单个配置项。但生产环境是复合问题服务会重启、网络会抖动、消费者会被限流、消息可能会重复投递甚至 MQ 本身可能会发生故障切换。所以能做对面试题不等于能做好生产。真正有工程价值的是把“投递失联”推广成一套消息可靠性模型。面试时能意识到这一点会让你的回答从“解决问题”上升到“设计方案”。6.2 四层可靠性模型结合上面所有内容可以沉淀一个四层模型层级解决的问题核心机制发送确认层消息有没有到交换机、有没有路由到队列publisher confirm mandatory return 回调存储可靠性层MQ 重启后消息还在不在交换机/队列/消息三者都持久化消费确认层业务处理成功后才算消费成功手动 ack 异常分支 死信队列对账补偿层极端情况下确认信号丢失后怎么办消息日志表 定时任务 人工补偿每一层管一个边界组合起来才是一个完整的可靠性闭环。很多项目只做了前两层所以消息丢了根本发现不了还有项目前三层都做了但没有对账补偿最后少数消息卡在中间状态依然要人工捞。6.3 落到实践的最小动作如果你正在准备面试或者想给项目补一下消息可靠性可以从三个最划算的动作开始。第一给生产者的发送逻辑补一个 correlationData把消息 ID 和回调结果打日志。这一步几乎零成本但能让你在出问题时知道“消息到底发没发出去”。第二把消费者的自动 ack 改成手动 ack并在 catch 分支里明确写 nack 还是转死信。这一步工作量不大但能解决大量“看起来成功实际失败”的问题。第三在 RabbitMQ 管理台建一个死信队列并给业务队列配上 deadLetterExchange。一旦有消息被拒绝或过期至少有个地方能观察而不是直接消失。做完这三件事你就不只是在背一道面试题而是已经开始靠近消息可靠性的工程实践了。面试题会换问法但这套排查链路和分层模型换到别的 MQ 产品上也基本成立。 
长河君 · 2026/8/30 18:39:54 · 阅读 1.2k RabbitMQ消息投递失联排查：confirm、ack与持久化如何成环
你大概率遇到过这个场景上游系统返回发送成功消费者服务也没有任何异常日志但最终落库的记录就是少了。线上排查半天最后发现消息在某个环节被悄悄丢了。这类问题在 Java 面试里被包装成一个固定题目——“RabbitMQ 消息投递失联”属于场景题里的重灾区。很多候选人能背出 confirm、ack、持久化这些关键词但真被问到“现在消息丢了你怎么定位”就会卡住。原因很简单他背的是配置而面试官问的是消息投递整条链路的可观测性。配置是静态的链路排查才是动态的。能把这二者打通才是这道题真正想考察的东西。这篇文章就从面试角度入手把“投递失联”拆开讲清楚消息会丢在哪一段每一段靠什么机制兜底出了问题按什么顺序排查以及面试时怎么回答才不像背八股。1. 先搞懂“投递失联”到底丢在哪一段1.1 消息从生产到消费其实隔着三段路由RabbitMQ 不是生产者直接把消息塞给消费者。一条消息从产生到被业务处理中间要经过三段第一段生产者把消息发送到交换机exchange。第二段交换机根据路由键把消息路由到绑定的队列queue。第三段消费者从队列拉取消息完成业务处理再确认消息。前两段属于“投递”第三段属于“消费”。很多人排查消息丢失只盯着第一段有没有发送成功忽略了后面还有两段。实际上任何一段出问题都会表现为“消息不见了”但不一定会有报错。这条链路有一个非常容易被忽略的特点默认状态下每一步都可能静默丢弃。生产者 send 成功只表示数据写到了 TCP 连接的缓冲区不表示交换机已经接收交换机收到消息但路由键匹配不到任何队列消息默认会被直接丢弃消费者拉取到消息后如果开启自动 ack哪怕业务逻辑抛异常消息也会被标记为已完成。所以“投递失联”这个说法本质上是在描述一种不可见的状态消息没有出现在它该出现的位置但也没有任何环节明确告诉你“它失败了”。1.2 失联有两种长相排查思路完全不同第一种长相消息从头到尾就没有到达消费者。它可能根本没发到交换机也可能到了交换机但路由失败被丢弃。这种失联消费者端的日志永远是干净的数据库里也永远不会有这条记录。第二种长相消息已经进入了队列消费者也拉取到了但业务处理失败。如果代码没有正确返回 ack/nack或者用了自动 ack 又把异常吞掉了消息就会从队列里消失而业务结果并没有落库。这两类问题在表现上非常像没有报错数据缺失。但排查方向完全不同。第一类要查生产者、交换机、路由键、绑定关系第二类要查消费者代码、异常处理、ack 逻辑。很多人一上来就翻 RabbitMQ 日志翻半天也找不到原因就是因为没有先判断“消息到底有没有进队列”。1.3 面试官出这道题不想听你背配置这道题之所以成为面试重灾区是因为它表面考配置实际考排查链路。面试官想看到的是你知道一条消息要经过哪几段你知道每一段默认有什么风险你知道靠什么机制把风险暴露出来你知道问题出来后按什么顺序定位。如果只回答“开启生产者确认开启手动 ack开启持久化”这只能算及格。真正能拉开的差距是你能不能把每一段的风险、机制、边界串成一条完整的排查链路。2. 把每一跳都改造成“有回执”的投递2.1 第一跳生产者到交换机必须开 publisher confirmRabbitMQ 提供了一种机制让生产者可以确认消息是否被交换机接收这就是 publisher confirm。开启后生产者发送消息时会得到一个回调acktrue 表示交换机已接收ackfalse 表示交换机拒收或写入失败。要注意这里确认的只是“到交换机为止”不包含后续的“路由到队列”。很多人在这一步产生误解以为 confirm ack 就代表消息安全落地了。实际上confirm 只覆盖了第一跳它无法感知第二跳的路由结果。如果消息路由不到任何队列confirm 依然会返回 ack因为交换机确实收到了消息。所以confirm 是必要的但不是充分的。它只是把第一跳从“不可见”变成“可见”后面还有第二跳需要单独处理。2.2 第二跳交换机到队列靠 mandatory 和 return 回调抢救消息到了交换机之后交换机要根据路由键把消息投递到绑定的队列。如果找不到匹配的队列有两种处理方式默认行为把消息直接丢弃。开启 mandatory把消息退回给生产者通过 return 回调通知。return 回调是判断“路由失败”的唯一出口。如果没开 mandatory你永远不会知道消息在第二跳被丢了开了之后至少能收到一个明确的失败信号。用一个快递类比confirm 相当于快递公司告诉你“包裹已经收件了”return 相当于发件途中发现地址无效把包裹退回给了发件人。只有收件确认没有退件提醒很多丢件你是永远发现不了的。2.3 第三跳队列到消费者手动 ack 才能知道业务结果前两跳解决的是“消息有没有进队列”第三跳解决的是“消息被消费后到底处理成功没有”。默认情况下消费者收到消息后会自动 ack消息立刻从队列里移除。如果这时候业务代码抛异常又没做捕获处理消息就没了业务也没成功。生产环境普遍改成手动 ack业务处理成功调用 basicAck业务处理失败调用 basicNack 或 basicReject既不 ack 也不 nack消息会停留在 unacked 状态不会被其他消费者拉取。手动 ack 真正解决的问题是把“消费结果”交给业务代码来判断而不是让 MQ 默认认为“拉取成功就是处理成功”。顺便要注意 prefetch 参数。它决定消费者一次性预取多少条消息。设置太大会导致消息堆积在本地设置太小又会让消费者频繁往返请求。一般先按单条消息的处理耗时来调而不是盲目设一个大值。三层链路、默认行为、风险、兜底机制可以整理成下表投递段链路范围默认风险确认/兜底机制第一跳生产者 → 交换机发送失败、交换机不存在publisher confirm第二跳交换机 → 队列路由键不匹配、无绑定队列mandatory return 回调第三跳队列 → 消费者业务异常、ack 失败、重复消费手动 ack 死信队列 幂等3. 五步排查法从“找不到原因”到“秒定位代码”面试时如果只给结论容易被追问到细节。真正实用的方法是给一套排查顺序让面试官看到你解决问题的路径。下面这套“五步排查法”同样适用于线上真实故障。3.1 第一步确认生产者有没有把消息真正发出去先看生产者的 confirm 回调如果收到 ackfalse说明交换机拒收或写入失败问题在第一跳如果回调根本没有触发可能是连接没建立、消息发送前就抛了异常、或者回调设置本身有问题如果确认 acktrue继续看第二步。这里建议在发送时带上 correlationData把消息唯一 ID 塞进去方便后续追踪。生产环境最好把确认结果落到日志或表里否则等出问题了再回看会发现什么都查不到。3.2 第二步检查路由键与绑定关系确认 acktrue 但消息依然消失大概率是第二跳出了问题。此时去管理台看三条信息交换机是否存在队列是否存在路由键和绑定关系是否匹配。特别常见的情况是生产者和消费者代码里的交换机、路由键、队列名不一致。比如测试环境用着 dev 队列生产环境配置还是 dev消息发到交换机后匹配不到队列又被丢弃这种问题不靠日志很难发现。如果 confirm 和 return 都开了这一步会在 return 回调里留下痕迹。所以排查时一定要确认这两个回调有没有真正触发过。3.3 第三步看队列里的消息状态进入 RabbitMQ 管理台的 Queues 页面关注两类数字ready队列中等待被消费的消息数量unacked已经被消费者拉取、但还没确认的消息数量。如果 ready 持续增长说明消费者没在消费或消费速度跟不上如果 unacked 持续很高说明消费者拉到了消息但一直没 ack可能是处理线程卡死也可能是代码里既没 ack 也没 nack。如果队列空了但数据库里还是没有数据就要回到消费者日志里查。还有一种可能消息被设置了 TTL过期后被清掉或者被 nack 后 requeuefalse进入了死信队列或者被直接丢弃。3.4 第四步检查消费者代码的异常处理走到这一步基本可以确定消息已经进过队列了。此时要重点查看消费者代码是用自动 ack 还是手动 ack业务处理有没有 try-catchcatch 之后有没有返回 nacknack 时 requeue 设置的是 true 还是 false。最常见的错误写法是手动 ack 开了但代码里 catch 住异常后什么都没做导致消息既不 ack 也不 nack最终 unacked 一直堆积队列被卡死。还有一种写法更隐蔽捕获异常后打印日志然后继续执行 ack等于告诉 MQ“这条消息处理成功了”。排查时先看日志印了没再看代码走了哪个分支基本能定位到具体行。3.5 第五步用监控曲线验证断点如果项目里接入了监控这一步会更高效。对比几个指标生产者 publish 速率交换机/队列的 incoming 速率消费者 deliver 速率消费者 ack 速率。publish 很高但 deliver 为零说明消息断在前两跳大概率路由没成功deliver 很高但 ack 为零说明消费者拉取后在处理阶段卡住或异常不断如果某一时刻 deliver 曲线突然跌到零同时队列 ready 也清零可能是消息被批量拒绝并且没有重投。注意不要一上来就翻代码或改配置。先看管理台和监控数据会告诉你断在哪一层。很多失联问题看曲线比看代码更直观。4. 关键代码与避坑清单面试和实际开发都有一个共识只讲机制不够还是要落到代码上。不需要复杂的例子但要把关键点写对。4.1 生产者侧confirm mandatory 缺一不可假设用的是 Spring Boot Spring AMQP常见写法是这样的结构rabbitTemplate.setMandatory(true); rabbitTemplate.setConfirmCallback((correlationData, ack, cause) - { if (!ack) { // 第一跳失败交换机没有接收记录待重发 log.error(消息发送失败correlationId{}, cause{}, correlationData.getId(), cause); } }); rabbitTemplate.setReturnsCallback(returned - { // 第二跳失败交换机路由不到队列 log.error(消息路由失败exchange{}, routingKey{}, body{}, returned.getExchange(), returned.getRoutingKey(), returned.getMessage()); });这里两个回调分别对应两个断点。confirm 接管第一跳return 接管第二跳。只配 confirm 不配 mandatory第二跳失败依然会丢只配 mandatory 不配 confirm第一跳失败你不知道。correlationData 里建议放业务唯一 ID比如订单号或消息表主键方便失败后按 ID 精确补偿。4.2 消费者侧别让业务异常变成“假成功”手动 ack 的消费者代码结构应该是这样的RabbitListener(queues order.queue) public void onMessage(Message message, Channel channel) throws Exception { long deliveryTag message.getMessageProperties().getDeliveryTag(); try { handleBusiness(message); channel.basicAck(deliveryTag, false); } catch (Exception e) { log.error(消费消息失败deliveryTag{}, deliveryTag, e); channel.basicNack(deliveryTag, false, true); } }需要特别解释的是 basicNack 的第三个参数 requeue。设为 true 会把消息重新放回队列看起来像在自动重试但实际很危险。如果业务处理一直失败消息会反复进出队列形成死循环把消费者线程和队列打满。更稳妥的做法是先记录重试次数超过阈值后 requeuefalse把消息转入死信队列由专门的补偿任务来处理。这比无限重试要可控得多。4.3 最容易踩的三个隐性坑第一个坑只开 confirm没开 mandatory。这种情况下第一跳失败能看到第二跳失败依然静默丢弃。面试里可以主动提这一点会显得你想过边界。第二个坑手动 ack 没写全。消息既不 ack 也不 nackunacked 越积越多后面所有消息都卡在队列里。这不是投递失联但比投递失联更隐蔽因为消息还在队列里只是没人能消费。第三个坑持久化不完整。RabbitMQ 的持久化要三段同时生效交换机持久化、队列持久化、消息 deliveryModePERSISTENT。只设置其中一两个MQ 一旦重启该丢的消息照样丢。提醒不要把“消息写入队列”和“消息落盘持久化”画等号。队列非持久化时消息只是暂时存在内存里重启即失联。5. 面试这样答才不像背八股5.1 推荐回答顺序现象 → 链路 → 机制 → 边界面试官问“RabbitMQ 消息投递失联你怎么排查”不建议上来就背 confirm、ack、持久化。可以按下面这个顺序回答先确认现象。消息是从未到达还是到达了但没处理成功。这一步决定了后续方向。再画链路。把消息投递拆成三段生产者到交换机、交换机到队列、队列到消费者。每一段都有各自的失败模式。再给出机制。第一段用 publisher confirm第二段用 mandatory return 回调第三段用手动 ack 和死信队列。最后补边界。confirm 只覆盖第一跳ack 只覆盖消费结果持久化只防 MQ 重启丢消息它们各自管一段组合起来才构成完整可靠性。这个回答顺序的价值在于先给路径再给方案。面试官跟着你的链路走能看出你是在想问题不是背口诀。5.2 一个能加分的判断可靠性必须成环如果只是把失败暴露出来问题还没有被解决。正确认识是confirm、return、ack 只是让失败可见真正的可靠性要靠补偿机制成环。所谓成环就是一条消息从发送到消费每个关键节点都有记录失败时有兜底最终能通过人工或定时任务对账。常见落地方案是加一张消息日志表发送前记录一条confirm 成功后更新状态消费成功后更新状态定时任务扫描长期处于中间状态的消息做补偿。面试时如果能说出这一步等于把问题从“消息队列怎么配置”拉升到了“分布式链路数据一致性怎么保证”这是很明显的认知增量。5.3 面试官可能会追问的四个方向追问一如果 confirm 回调一直没有返回该怎么办这时不能无限制等需要设置超时重试。重试达到阈值后把消息状态标记为发送失败由定时任务扫描补偿。追问二消费端处理很慢unacked 堆积严重。先判断是单个消息处理慢还是整体消费能力不足。单条消息慢检查是不是有外部调用超时没有设 timeout整体消费能力不足考虑调整 prefetch、增加并发消费者或者拆分队列。追问三消息重复消费怎么办RabbitMQ 的语义是至少一次正常情况下就可能出现重复投递。解决方案是消费端做幂等用业务唯一键防重、数据库唯一索引、状态机判断而不是依赖消息队列保证不重复。追问四数据库和 MQ 的一致性问题怎么解决常见方案是本地消息表加定时任务先写业务数据和消息表再异步发送 MQ发送成功后标记。更极端的做法是事务消息但要对具体 MQ 产品的能力做评估不是所有实现都支持。6. 从一道场景题到消息可靠性的四层模型6.1 面试题和生产环境的真实差距面试题通常只考单条链路、单个断点、单个配置项。但生产环境是复合问题服务会重启、网络会抖动、消费者会被限流、消息可能会重复投递甚至 MQ 本身可能会发生故障切换。所以能做对面试题不等于能做好生产。真正有工程价值的是把“投递失联”推广成一套消息可靠性模型。面试时能意识到这一点会让你的回答从“解决问题”上升到“设计方案”。6.2 四层可靠性模型结合上面所有内容可以沉淀一个四层模型层级解决的问题核心机制发送确认层消息有没有到交换机、有没有路由到队列publisher confirm mandatory return 回调存储可靠性层MQ 重启后消息还在不在交换机/队列/消息三者都持久化消费确认层业务处理成功后才算消费成功手动 ack 异常分支 死信队列对账补偿层极端情况下确认信号丢失后怎么办消息日志表 定时任务 人工补偿每一层管一个边界组合起来才是一个完整的可靠性闭环。很多项目只做了前两层所以消息丢了根本发现不了还有项目前三层都做了但没有对账补偿最后少数消息卡在中间状态依然要人工捞。6.3 落到实践的最小动作如果你正在准备面试或者想给项目补一下消息可靠性可以从三个最划算的动作开始。第一给生产者的发送逻辑补一个 correlationData把消息 ID 和回调结果打日志。这一步几乎零成本但能让你在出问题时知道“消息到底发没发出去”。第二把消费者的自动 ack 改成手动 ack并在 catch 分支里明确写 nack 还是转死信。这一步工作量不大但能解决大量“看起来成功实际失败”的问题。第三在 RabbitMQ 管理台建一个死信队列并给业务队列配上 deadLetterExchange。一旦有消息被拒绝或过期至少有个地方能观察而不是直接消失。做完这三件事你就不只是在背一道面试题而是已经开始靠近消息可靠性的工程实践了。面试题会换问法但这套排查链路和分层模型换到别的 MQ 产品上也基本成立。