03 - 消息可靠性保障
面试高频度：⭐⭐⭐⭐⭐ 考查方式：必考题、方案设计题、故障排查题
一、消息可能在哪里丢失？
要保障可靠性，首先要搞清楚消息经过了哪些环节，每个环节都有什么风险：
环节① 环节② 环节③
Producer ──────▶ Broker（Exchange+Queue）──────▶ Consumer
网络抖动 宕机/未持久化 未ACK就崩溃
发送失败 内存消息丢失 自动ACK后崩溃| 环节 | 丢失场景 | 为什么会丢 |
|---|---|---|
| ① 生产端 → Broker | 网络异常导致消息没到达 Broker | TCP 连接断开、Broker 宕机、网络分区 |
| ② Broker 存储 | Broker 宕机后消息消失 | 消息只存在内存中（非持久化），Broker 重启后丢失 |
| ③ Broker → Consumer | 消费者拿到消息后崩溃 | 自动 ACK 模式下，Broker 投递完就删消息了，消费者没来得及处理 |
一个关键认知：RabbitMQ 本身不保证消息的端到端可靠性。它提供了机制（Confirm、持久化、手动 ACK），但需要你在每个环节主动配置。不配置 = 不保障。
二、生产端可靠性——Confirm 模式
2.1 为什么需要 Confirm？
Producer 发消息到 Broker 后，怎么知道 Broker 确实收到了？默认情况下，Producer 发完就不管了——如果 Broker 此时正好宕机或网络断了，消息就丢了，Producer 也不知道。
Confirm 模式的机制：Producer 开启 Confirm 后，每条消息到达 Broker 后，Broker 会返回一个 ACK（确认）或 NACK（拒绝）。Producer 收到 ACK 才能确定消息安全到达。
2.2 同步 vs 异步 Confirm
| 方式 | 原理 | 性能 | 适用场景 |
|---|---|---|---|
| 同步 Confirm | 发一条消息，等待 Broker 返回 ACK，再发下一条 | 低（每条消息都要等一次网络往返） | 极低吞吐场景 |
| 异步 Confirm | 持续发送，Broker 通过回调批量通知哪些消息已确认 | 高（发送和确认并行） | 生产推荐 |
异步 Confirm 的核心机制：
- Producer 为每条消息分配一个递增的
deliveryTag（序列号） - 消息发送后，Producer 把 tag 记录到一个集合中（表示"待确认"）
- Broker 异步回调通知 ACK 时，可以是单条确认（只确认一个 tag），也可以是批量确认（确认该 tag 及之前的所有消息）
- Producer 从集合中移除已确认的 tag
批量确认的优化：Broker 的 ACK 回调有一个 multiple 参数，当 multiple=true 时，表示该 tag 及之前所有 tag 都已确认。用 ConcurrentSkipListSet 的 headSet(tag+1).clear() 可以一次性清理，而不是逐条 remove。
2.3 Confirm 只覆盖"到 Exchange"——Return 机制补位
一个常见误解：Confirm 只能保证消息到达了 Exchange，但不保证消息从 Exchange 路由到了 Queue。
如果 RoutingKey 写错了、没有匹配的 Binding，消息会被 Exchange 静默丢弃——Confirm 仍然返回 ACK（因为消息确实到了 Exchange）。这就是为什么需要 Return 机制：
mandatory=true：告诉 Broker，如果消息无法路由到任何 Queue，不要丢弃，而是返回给 ProducerReturnListener：Producer 注册的回调，收到路由失败的消息后可以重试、记录或告警
2.4 生产端可靠性全链路
Producer 的可靠性三件套：
1. confirmSelect() → 开启确认模式
2. basicPublish(mandatory=true) → 发送消息，声明路由失败时要返回
3. addConfirmListener() → 监听 Broker 的 ACK/NACK
4. addReturnListener() → 监听路由失败
失败处理策略：
├── 重试（指数退避：第1次立即，第2次1秒，第3次3秒）
├── 消息落库（本地记录发送状态，定时任务兜底重发）
└── 告警通知（超过重试次数后告警）三、Broker 存储可靠性——持久化
3.1 三重持久化缺一不可
持久化有三个层面，缺少任何一个都可能导致 Broker 重启后消息丢失：
| 持久化对象 | 不持久化的后果 | 配置方式 |
|---|---|---|
| Exchange | Broker 重启后 Exchange 消失，Producer 发消息报错 | durable=true |
| Queue | Broker 重启后 Queue 消失，消息无处可存 | durable=true |
| Message | Broker 重启后消息丢失（即使 Queue 还在） | deliveryMode=2 |
一个真实踩坑案例：Queue 设了 durable=true，但 Exchange 没设。Broker 重启后 Exchange 消失，所有消息路由失败。运维检查发现 Queue 还在、消息还在，但就是收不到新消息——因为 Producer 发消息时找不到 Exchange 了。
3.2 持久化是怎么实现的？
消息持久化不是"写入就安全"的。理解存储机制才能理解为什么持久化也有风险：
写入流程：
消息到达 Broker → 内存页（mnesia） → 异步刷盘到磁盘文件
磁盘文件结构：
├── 元数据文件（Exchange/Queue/Binding 定义）
├── 消息索引文件（消息在磁盘上的位置）
└── 消息内容文件（实际的消息体）关键风险：消息从内存写到磁盘是异步的（默认几百毫秒一次刷盘）。如果 Broker 在刷盘前宕机，内存中的消息就丢了。这就是为什么持久化不能 100% 保证安全——需要镜像队列或仲裁队列做多节点副本（详见 **集群与高可用架构**）。
3.3 持久化的性能代价
写磁盘比写内存慢 1-2 个数量级。持久化消息的吞吐量比非持久化消息低很多。这是一个可靠性与性能的权衡：
- 核心业务消息（订单、支付）→ 必须持久化
- 日志/监控消息 → 可以不持久化（丢了重新采集）
四、消费端可靠性——手动 ACK
4.1 自动 ACK 的风险
自动 ACK（autoAck=true）意味着 Consumer 收到消息的瞬间，Broker 就把消息标记为已消费并删除。如果 Consumer 收到消息后在处理业务的过程中崩溃了——消息已经从 Queue 中删除了，但业务没有处理完成——消息永久丢失。
这就是为什么生产环境必须用手动 ACK。
4.2 正确的 ACK 顺序
正确的顺序：先处理业务，后 ACK
错误的顺序：先 ACK，后处理业务
为什么？
- 先 ACK：Broker 删消息 → 业务处理失败 → 消息没了，无法重试
- 先业务：业务成功 → ACK → Broker 删消息。业务失败 → NACK → 消息重新投递4.3 NACK 和 requeue 的策略
消费失败时怎么处理？basicNack 的 requeue 参数决定了消息的命运：
| 策略 | 行为 | 风险 |
|---|---|---|
requeue=true | 消息重新回到队列头部，等待再次被消费 | 如果失败原因是代码 Bug，消息会反复失败（死循环） |
requeue=false | 消息进入死信队列（DLX），不再回到原队列 | 消息不会丢，但需要额外的死信消费者处理 |
生产推荐的做法：维护一个重试计数器（存在消息 Header 中），失败 N 次以内 requeue=true 重试，超过 N 次后 requeue=false 发到死信队列，触发告警。
4.4 Prefetch（预取数量）的影响
basicQos(N) 控制的是：每个 Consumer 同时能持有多少条未 ACK 的消息。
| prefetch 值 | 效果 | 适用场景 |
|---|---|---|
| 1 | 严格逐条消费，处理完一条才能取下一条 | 需要严格顺序（订单状态变更） |
| 10-50 | 适度并发，平衡吞吐和内存 | 大多数业务场景 |
| 0（不限制） | Broker 尽量多发 | 不推荐——Consumer 内存可能爆掉 |
prefetch 太大的风险：Broker 一次性投递大量消息到 Consumer，如果 Consumer 崩溃，这些未 ACK 的消息要等 TCP 连接超时后才会被重新投递。prefetch 越大，恢复时间越长。
五、Confirm vs 事务——为什么不用事务？
RabbitMQ 支持事务（txSelect/txCommit），也能保证消息不丢。那为什么生产不用？
| 维度 | Confirm | 事务 |
|---|---|---|
| 机制 | 异步回调确认 | 同步阻塞等待 |
| 吞吐量 | 万级/秒 | 百级/秒（下降 10 倍+） |
| 开销 | 几乎无额外开销 | 每条消息都要等 fsync |
| 粒度 | Channel 级别 | Channel 级别 |
事务模式下，每发一条消息都要经历 txSelect → basicPublish → txCommit 三步，其中 txCommit 会触发磁盘 fsync。这就是它慢的根因——每条消息都要等磁盘写入完成。
Confirm 模式异步回调，发送和确认并行进行，性能几乎不受影响。
六、完整可靠性架构
┌─────────────────────────────────────────────────────────────┐
│ 消息可靠性保障全链路 │
│ │
│ Producer Broker Consumer │
│ ┌──────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │Confirm+ │ │三重持久化 │ │手动ACK │ │
│ │Return │ │Exchange+ │ │先业务后确认 │ │
│ │ │ │Queue+Message │ │ │ │
│ └────┬─────┘ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ 失败重试 刷盘策略 失败处理 │
│ 消息落盘 (定期fsync) ├─有限次重试 │
│ 定时重发 镜像/仲裁队列(多副本) ├─死信队列 │
│ └─告警通知 │
└─────────────────────────────────────────────────────────────┘三个环节各自独立，缺一不可：
- 生产端的 Confirm 保证消息到达 Broker
- Broker 的持久化保证消息在 Broker 重启后存活
- 消费端的手动 ACK 保证消息被正确处理后才从 Queue 中删除
七、面试常见追问
Q1：ACK 丢了怎么办？
RabbitMQ 的 ACK 是幂等的——重复 ACK 同一个 deliveryTag 不会出错。如果 ACK 的网络包丢失，RabbitMQ 会在连接关闭后重新投递未确认的消息。
Q2：消息持久化了还是丢了怎么办？
持久化消息写入磁盘有异步窗口期（默认几百毫秒），窗口期内 Broker 宕机会丢消息。终极方案：**仲裁队列（Quorum Queue）**多节点同步写入，只有多数节点确认后才返回 ACK。
Q3：如何保证消息顺序性？
- 单 Queue 单 Consumer：天然有序
- 多 Consumer：无法保证顺序
- 解决方案：同一业务 key 路由到同一队列（hash routing_key），保证同一业务的消息只被一个 Consumer 处理
八、关联笔记
- **死信队列与延迟队列** - 消费失败的兜底方案
- **消息幂等性与重复消费** - ACK 机制下如何防重复
- **集群与高可用架构** - 多副本保障消息不丢
- **RabbitMQ面试高频题汇总** - 可靠性面试题汇总