消息可靠性保证

校招考察频度：★ 高频（核心必背·高频生死线） 一句话速记：全链路防丢靠“三端联防”：生产端开启 Confirm + Return 确保安全进 Broker；Broker 端设 Exchange/Queue/Message 三级持久化 + Quorum 队列多数派落盘；消费端关 autoAck 业务落库后手动 basicAck；防重复靠全局唯一 MessageId + 数据库唯一索引/Redis 幂等表。

在支付结算、订单状态流转、核心账务通知等核心业务中，“丢一条消息就是一次重大生产事故”。面试官高频连环发问：“如果我们要保证 100% 消息不丢失，RabbitMQ 从发到收全链路应该怎么配置？如果消息重复投递了，怎么保证幂等？”

一、消息丢失三阶段排查模型

任何消息中间件的数据丢失，绝对逃不出以下三个阶段之一：

[阶段一: 生产端丢]              [阶段二: Broker 端丢]              [阶段三: 消费端丢]
  Producer                     RabbitMQ Broker                    Consumer
     |                                |                               |
     |---- 1. 网络闪断没送到 Broker --->|                               |
     |---- 2. 路由键写错被 Exchange 丢弃->|                               |
     |                                |-- 3. 未持久化，Broker 重启蒸发 ->|
     |                                |-- 4. 磁盘刚写满写入失败 -------->|
     |                                |                               |
     |                                |---- 5. 开启自动 ACK，刚拿出来还没处理就宕机崩溃 ->|
     |                                |                               |

二、第一道防线：生产端防丢

必须确保消息不仅飞进了 Broker，而且被正确路由到了目标持久化队列：

1. 开启 Publisher Confirm（异步确认模式）：
   • 将信道设为 channel.confirmSelect()，注册 addConfirmListener。
   • 只有收到 Broker 明确返回的 ACK，才能判定消息已经被持久化写入队列。
   • 若收到 NACK 或等待超时，生产端立即触发告警或重发重试机制。
2. 开启 Return 监听 / 配置备用交换机（Alternate Exchange）：
   • 发送时设置 mandatory = true，当 Exchange 无法依据 RoutingKey 找到任何匹配的 Queue 时，触发 basic.return 将消息原路退回，杜绝消息落入黑洞。
   • 或者在主 Exchange 声明时绑定 alternate-exchange，让未路由的孤儿消息自动保存在预警队列中。

三、第二道防线：Broker 端持久化与 Quorum 队列

即便消息到了 Broker，如果仅仅保存在内存中，一旦宿主机断电或 Erlang 进程崩溃，内存数据荡然无存。

1. 经典三级持久化（缺失任一都会丢数据）

• ① 交换机持久化： channel.exchangeDeclare(exchangeName, "topic", true);（durable = true）。
• ② 队列持久化： channel.queueDeclare(queueName, true, false, false, null);（durable = true）。
• ③ 消息持久化： 发送消息时，必须在 BasicProperties 中设置 delivery_mode = 2（持久化落盘）。

2. 集群级别高可用：现代 Quorum 队列（基于 Raft 协议）

• 单节点磁盘坏死的痛点：单机持久化在物理硬盘损坏、宿主机报废时依然会丢数据。
• 老旧镜像队列（Mirrored Queue）的弊端：传统镜像队列采用主从全量同步，网络抖动时容易触发网络分区与脑裂（Split-Brain），且性能损耗大（RabbitMQ 官方宣布在 4.0 彻底废弃）。
• 现代黄金解法：Quorum 队列：
  • 声明队列类型为 x-queue-type: "quorum"。
  • 底层基于工业级 Raft 共识算法，只有当消息被集群中多数派（$N/2 + 1$）节点成功写入磁盘 WAL 日志后，Broker 才会向生产端返回 Confirm ACK。
  • 彻底杜绝脑裂与数据丢失风险，金融级高可用标配。

四、第三道防线：消费端防丢

1. 严禁使用自动确认（autoAck = false）：
   • 自动确认机制下，Broker 刚把报文推送到网络缓冲区就立即删除队内数据。一旦消费者处理过程中发生空指针异常、数据库超时或进程被 OOM Killer 强杀，该消息彻底灰飞烟灭。
2. 业务安全落库后，手动执行 basicAck：
   • 消费端必须在本地数据库事务提交成功、外部依赖调用成功之后，才在 finally 块中调用 channel.basicAck(deliveryTag, false)。
3. 不可恢复异常隔离至死信队列（DLX）：
   • 发生不可恢复的坏数据错误时，调用 channel.basicReject(deliveryTag, false)，将消息丢入死信队列待人工排查，绝不能无脑 requeue=true 造成死循环。

五、消息重复消费与幂等性设计（工业级落地）

保证了“消息绝不丢失”，必然会带来另一个副产物——消息可能重复投递（At-Least-Once 至少一次投递语义）。

为什么消息会重复？

1. 生产端重试重复：消息已成功到达 Broker 并落盘，但回传 ACK 时网络闪断丢包，生产者超时重发，导致 Broker 队列中存了两条内容相同的消息。
2. 消费端重发重复：消费者已经把业务做完了（如完成了扣款），但在即将发送 basicAck 的一瞬间网络断开或进程重启，Broker 判定消费者失联，自动将该消息重新放回队首派发给其他消费者执行！

四大生产幂等性防重方案

面试高频追问

1. RabbitMQ 如何做到百分之百消息不丢？请串讲全流程。
   • 生产端：开启异步 Confirm 监听 + mandatory/Return 回退机制，确保消息安全进队列。
   • Broker 端：声明持久化 Exchange + 持久化 Queue + 发送持久化消息（delivery_mode=2），生产集群必须使用基于 Raft 协议的 Quorum 队列。
   • 消费端：关闭 autoAck，业务落库成功后手动 basicAck；捕获坏消息 reject 进死信队列。
2. 为什么说只配了 Queue 持久化，消息依然可能在 Broker 丢失？
   • 队列持久化仅仅代表“队列本身的元数据和名称在 Broker 重启后还存在”。如果发送消息时未指定 delivery_mode=2，消息体仍然只驻留在操作系统的内存中，Broker 重启后该队列会变成一个空队列！三级持久化缺一不可。
3. 消费者处理一条消息需要 10 秒，在第 9 秒时消费者挂了，消息会怎样？
   • 因为没有收到 basicAck，Broker 监测到该消费者的 TCP 连接中断后，会立即将该消息的状态从 Unacknowledged 重新标记为 Ready，并立即派发给下一个活跃的消费者重新执行。这也是为什么消费端必须做幂等性的核心原因。