RabbitMQ防丢方案：生产者开启Confirm，Broker配置持久化与集群，消费者手动ACK。

RabbitMQ 要保证消息不丢失，必须在全链路（生产者、Broker、消费者）上进行配合。如果其中任何一个环节出了问题，都可能导致消息丢失。

以下是基于这三个层面的详细解决方案：

---

一、 生产者层面 (Producer)

目标：确保消息成功发送到了 RabbitMQ Broker，并且被正确路由到了队列。

1. 开启发布确认机制 (Publisher Confirms)
这是防止消息在发送途中丢失的核心机制。

• 原理：生产者将信道设置成 confirm 模式，一旦信道进入该模式，所有在该信道上面发布的消息都会被指派一个唯一的 ID。一旦消息被投递到所有匹配的队列之后，Broker 就会发送一个确认（Basic.Ack）给生产者（包含消息的唯一 ID）。
• 实现方式：
  • 同步等待：发送一条等待确认一条（性能差）。
  • 批量确认：发送一批等待确认（由隐患，出错难以定位）。
  • 异步确认（推荐）：提供一个回调方法，Broker 确认收到后回调该方法。如果 Broker 发生内部错误导致消息丢失，会发送 nack，生产者可以在回调中进行重试。

2. 开启失败回退机制 (Return Mechanism)

• 原理：Publisher Confirms 只能保证消息到了 Switch（交换机），但如果交换机没有匹配的 Queue（队列），消息会被丢弃。
• 实现：设置 mandatory 参数为 true，并添加 ReturnListener。当消息无法路由到队列时，RabbitMQ 会通过 Return 回调将消息退回给生产者。

3. 本地消息表（终极补偿）

• 在发送消息前，先将业务数据和消息状态存入本地数据库（状态为“发送中”）。
• 收到 Broker 的 Ack 后，更新状态为“已发送”。
• 有一个定时任务轮询“发送中”且超时的消息进行重发。

---

二、 Broker 层面 (RabbitMQ Server)

目标：确保 RabbitMQ 收到消息后，即使服务重启或宕机，消息依然存在。

1. 队列持久化 (Queue Durability)

• 在声明队列时，将 durable 参数设置为 true。
• 这样 RabbitMQ 重启后，元数据（队列的定义）不会丢失，但里面的消息默认还是会丢失。

2. 消息持久化 (Message Persistence)

• 在发送消息时，将消息的属性 delivery_mode 设置为 2（Persistent）。
• 注意：只有同时设置了“队列持久化”和“消息持久化”，消息才会被写入磁盘。

3. 交换机持久化 (Exchange Durability)

• 声明交换机时 durable 设为 true，防止重启后交换机消失，导致消息无法路由。

4. 高可用机制 (Clustering)
单机持久化也怕硬盘损坏。为了保证硬件故障下的不丢失，需要使用集群。

• 镜像队列 (Mirrored Queues - 经典方案)：将队列镜像到集群中的其他节点上。如果主节点挂了，从节点会自动提升为主节点。
• 仲裁队列 (Quorum Queues - 新版推荐)：基于 Raft 一致性协议，提供更强的数据安全性和更高的一致性，专门用于替代镜像队列解决数据丢失问题。

---

三、 消费者层面 (Consumer)

目标：确保消费者真正处理完业务逻辑后，消息才被移除。

1. 关闭自动确认 (Auto Ack -> Manual Ack)

• 默认行为：RabbitMQ 默认是自动确认（Auto Ack），即消息一旦推送到消费者，RabbitMQ 就会将该消息从内存/磁盘删除。如果消费者在处理过程中（比如写入数据库时）抛出异常或宕机，消息就丢了。
• 解决方案：将 autoAck 设置为 false，改为手动确认。
• 流程：
  1. 消费者收到消息。
  2. 执行业务逻辑（如扣减库存、写入 DB）。
  3. 业务执行成功 -> 发送 basicAck 给 Broker，Broker 删除消息。
  4. 业务执行失败 -> 发送 basicNack 或 basicReject，并设置 requeue=true 让消息重新回到队列（或者进入死信队列）。

2. 幂等性处理

• 既然为了不丢消息而引入了重试机制（如生产者重发、消费者 requeue），那么消费者就必然会收到重复消息。
• 必须在业务层面实现幂等性（如使用 Redis 的 SetNX、数据库唯一索引、版本号机制），防止重复消费导致数据错误。

---

总结图谱