你大概率遇到过这个场景：上游系统返回发送成功，消费者服务也没有任何异常日志，但最终落库的记录就是少了。线上排查半天，最后发现消息在某个环节被悄悄丢了。这类问题在 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 confirm
RabbitMQ 提供了一种机制，让生产者可以确认消息是否被交换机接收，这就是 publisher confirm。
开启后，生产者发送消息时会得到一个回调：ack=true 表示交换机已接收，ack=false 表示交换机拒收或写入失败。要注意，这里确认的只是“到交换机为止”，不包含后续的“路由到队列”。
很多人在这一步产生误解，以为 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 回调：
- 如果收到 ack=false，说明交换机拒收或写入失败，问题在第一跳；
- 如果回调根本没有触发，可能是连接没建立、消息发送前就抛了异常、或者回调设置本身有问题；
- 如果确认 ack=true，继续看第二步。
这里建议在发送时带上 correlationData，把消息唯一 ID 塞进去，方便后续追踪。生产环境最好把确认结果落到日志或表里，否则等出问题了再回看，会发现什么都查不到。
3.2 第二步：检查路由键与绑定关系
确认 ack=true 但消息依然消失，大概率是第二跳出了问题。此时去管理台看三条信息：
- 交换机是否存在；
- 队列是否存在；
- 路由键和绑定关系是否匹配。
特别常见的情况是：生产者和消费者代码里的交换机、路由键、队列名不一致。比如测试环境用着 dev 队列，生产环境配置还是 dev，消息发到交换机后匹配不到队列，又被丢弃，这种问题不靠日志很难发现。
如果 confirm 和 return 都开了，这一步会在 return 回调里留下痕迹。所以排查时一定要确认这两个回调有没有真正触发过。
3.3 第三步：看队列里的消息状态
进入 RabbitMQ 管理台的 Queues 页面，关注两类数字：
- ready：队列中等待被消费的消息数量；
- unacked：已经被消费者拉取、但还没确认的消息数量。
如果 ready 持续增长，说明消费者没在消费或消费速度跟不上；如果 unacked 持续很高，说明消费者拉到了消息但一直没 ack，可能是处理线程卡死，也可能是代码里既没 ack 也没 nack。
如果队列空了，但数据库里还是没有数据，就要回到消费者日志里查。还有一种可能：消息被设置了 TTL，过期后被清掉；或者被 nack 后 requeue=false，进入了死信队列或者被直接丢弃。
3.4 第四步：检查消费者代码的异常处理
走到这一步，基本可以确定消息已经进过队列了。此时要重点查看消费者代码：
- 是用自动 ack 还是手动 ack；
- 业务处理有没有 try-catch；
- catch 之后有没有返回 nack；
- nack 时 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 会把消息重新放回队列，看起来像在自动重试，但实际很危险。如果业务处理一直失败，消息会反复进出队列，形成死循环，把消费者线程和队列打满。
更稳妥的做法是：先记录重试次数，超过阈值后 requeue=false，把消息转入死信队列，由专门的补偿任务来处理。这比无限重试要可控得多。
4.3 最容易踩的三个隐性坑
第一个坑：只开 confirm，没开 mandatory。这种情况下，第一跳失败能看到，第二跳失败依然静默丢弃。面试里可以主动提这一点，会显得你想过边界。
第二个坑：手动 ack 没写全。消息既不 ack 也不 nack，unacked 越积越多，后面所有消息都卡在队列里。这不是投递失联，但比投递失联更隐蔽，因为消息还在队列里，只是没人能消费。
第三个坑：持久化不完整。RabbitMQ 的持久化要三段同时生效：交换机持久化、队列持久化、消息 deliveryMode=PERSISTENT。只设置其中一两个，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 产品上也基本成立。
