Linux上保障 RabbitMQ 消息不丢失的实用方案
一 关键原则与整体思路
- 在生产端开启Publisher Confirms，确保消息至少到达Exchange；若需“到达队列”的更强保证，结合mandatory/Return或备份交换机处理无法路由的消息。
- 在 Broker 侧开启持久化（Exchange/Queue/Message 三者都需持久化），否则节点重启会丢消息。
- 在消费端使用手动确认（ack/nack），处理完成再确认，避免进程崩溃导致消息丢失。
- 需要高可用时，使用镜像队列/仲裁队列避免单点故障。
- 需要“至少一次”语义时，可在发送端进行同步等待确认；注意这会带来性能下降。
二 生产者侧防丢
- 开启 Publisher Confirms：将信道置为 confirm 模式，异步接收 ack/nack；若要实现“到达队列”的确认，可配合 Return 监听或备份交换机。
- 处理路由不可达：发送时开启 mandatory=true 并添加 ReturnListener，或使用备份交换机捕获无法路由的消息，避免静默丢弃。
- 同步等待确认以保障“至少一次”：在关键场景可用 channel.waitForConfirms() 同步等待，但会显著影响吞吐量。
- Spring Boot 常用配置示例：
- application.yml
- spring.rabbitmq.publisher-confirms=true
- spring.rabbitmq.publisher-confirm-type=correlated
- spring.rabbitmq.publisher-returns=true
- spring.rabbitmq.listener.simple.acknowledge-mode=manual
- Java 回调
- setConfirmCallback 处理 ack/nack（记录状态、失败重发）
- setReturnCallback 处理 Exchange→Queue 路由失败（告警、补偿）
- setMandatory(true) 配合 Return 使用
三 Broker 侧防丢
- 持久化三要素：
- Exchange 持久化：声明时 durable=true
- Queue 持久化：声明时 durable=true
- Message 持久化：发送时 deliveryMode=2（PERSISTENT）
- 重要限制：
- 非持久化的 Exchange/Queue 在重启后会丢失；非持久化消息在重启后也会丢失。
- 持久化消息在“尚未完成持久化”前若节点宕机/重启，仍可能丢失（例如 fsync 未完成）。
- 高可用：
- 使用镜像队列将队列复制到多个节点，例如策略：rabbitmqctl set_policy ha-all “^myQueue$” ‘{“ha-mode”:“all”,“ha-sync-mode”:“automatic”}’（经典镜像队列）。
- 新集群建议使用**仲裁队列（Quorum Queue）**替代镜像队列以获得更强的数据一致性与恢复能力。
四 消费者侧防丢
- 关闭自动确认，改为手动确认：仅在业务处理成功时调用 basicAck，处理失败可 basicNack/reject 并选择是否重回队列。
- 控制预取数量（prefetch）：限制未确认消息数量，防止消费者内存暴涨与重投递风暴。
- Spring AMQP 确认模式：
- none：自动确认，风险最高
- manual：业务代码显式 ack/nack，最灵活
- auto：框架根据异常类型自动 ack/nack/reject，便于快速接入
五 快速排查与落地清单
- 配置核对
- 生产者：开启 publisher confirms/returns，必要时使用同步等待；发送端为每条消息生成唯一ID以便追踪。
- Broker：Exchange/Queue/Message 均设置为持久化；关键队列配置镜像/仲裁策略。
- 消费者：手动确认，合理设置 prefetch，异常分支明确 nack/reject 策略。
- 日志与告警
- 查看 /var/log/rabbitmq/ 下的服务日志，定位连接、权限、路由、磁盘等异常。
- 打开生产端 confirm/return 日志与指标，监控 nack/return 与重发率。
- 典型场景对策
- 发送成功但未落盘宕机：持久化+confirm 可大幅降低概率，关键业务可结合同步等待或外部事务表实现端到端“至少一次”。
- 路由不到队列：开启 mandatory/Return 或配置备份交换机进行补偿与告警。
- 消费端崩溃：确保未确认消息不会丢失且可重投递，配合 prefetch 与重试/死信策略避免消息堆积与无限循环。