RabbitMQ 如何保证消息不丢失？

为了保证消息在 RabbitMQ 中不丢失，必须从生产者、Exchange 路由、Broker 和消费者等多个方面采取有效措施。RabbitMQ 消息丢失的场景主要分为以下三种情况：生产者端、路由过程以及消费者端。

一、RabbitMQ 消息丢失的三种情况

在讨论如何保证消息不丢失之前，我们先来看看一条消息从生产到消费的完整流程：

生产者将消息发送到Exchange。
Exchange根据Routing Key将消息路由到Queue。
消费者订阅Queue，从Queue中获取消息进行消费。

消息丢失可能发生在以下几个阶段：

生产者丢失消息：生产者在将消息发送到 Exchange 的过程中，由于网络问题或发送到不存在的 Exchange，导致消息丢失。
路由失败：消息发送到了 Exchange，但 Exchange 在根据 Routing Key 路由时没有找到对应的 Queue，导致消息没有进入任何 Queue，从而丢失。
消费者处理失败：消费者已经成功从 Queue 中获取了消息，但在处理过程中发生异常，消息未正确处理或确认（ACK），导致消息丢失。

其他情况：RabbitMQ 服务崩溃时的消息丢失

即便上述问题都解决了，如果 RabbitMQ 服务器宕机且消息未被持久化，服务重启后这些未持久化的消息仍会丢失。因此，消息的持久化也是关键一环。

二、RabbitMQ 消息丢失的解决方案

针对不同的丢失场景，RabbitMQ 提供了多种机制来解决这些问题：

2.1 针对生产者端消息丢失

问题：生产者发送消息到 Exchange 时，由于网络问题或目标 Exchange 不存在，导致消息丢失。

解决方案：
RabbitMQ 提供了两种方式来解决生产者端的消息丢失问题：事务机制和发布确认机制。

（1）事务机制（不推荐，性能较差）

生产者可以在发送消息之前开启 RabbitMQ 事务，通过以下步骤确保消息不会丢失：

开启事务：channel.txSelect()。
发送消息：channel.basicPublish()。
如果发送成功，提交事务：channel.txCommit()；否则，回滚事务：channel.txRollback()，并重试发送。

事务机制虽然可以确保消息可靠性，但由于性能问题不适合高并发场景。

（2）发布确认机制（推荐）

发布确认机制是一种更高效的方案，生产者在发送消息后可以收到 RabbitMQ 的确认（ACK）或否定确认（NACK）。步骤如下：

开启发布确认模式：channel.confirmSelect()。
监听确认回调：
- onAck()：消息成功发送到 Broker。
- onNack()：消息发送失败，生产者可以选择重新发送。

发布确认模式不仅能够保证消息不会丢失，而且性能较事务模式要高得多，是生产环境中首选的方案。

2.2 针对路由失败

问题：消息到达了 Exchange，但由于没有合适的 Queue 路由，消息丢失。

解决方案：
通过配置 RabbitMQ 的备份交换机（Alternate Exchange，AE）和Mandatory 参数来处理消息的路由失败问题。

（1）Mandatory 参数

设置 mandatory=true，如果消息无法路由到任何 Queue，RabbitMQ 会将消息返回给生产者，生产者可以选择处理返回的消息或进行重试。

channel.basicPublish(exchange, routingKey, true, null, message);

（2）备份交换机（AE）

备份交换机是当消息未成功路由到 Queue 时，将消息路由到一个备用的 Exchange，确保消息不会丢失。例如，某些高优先级的消息可以转到备份交换机做进一步处理或记录。

2.3 针对消费者端消息丢失

问题：消费者已经从 Queue 中获取消息，但在处理消息时发生了异常，没有返回 ACK，导致消息丢失。

解决方案：
使用手动确认模式代替自动确认，确保消费者在成功处理完消息后才返回确认。

手动确认模式：
- 在消费者处理完消息后，手动调用 channel.basicAck() 来确认消息处理成功。
- 如果消息处理失败，可以调用 channel.basicNack() 或 channel.basicReject() 来拒绝该消息，RabbitMQ 会重新将消息投递给其他消费者
- 持久化消费者状态：为了防止在处理消息过程中出现宕机等意外情况，消费者可以将消息处理过程中的中间状态持久化到数据库，确保即使消费者宕机也可以继续未完成的工作。
- 2.4 RabbitMQ 服务宕机时的消息丢失
  
  问题：RabbitMQ 宕机导致未持久化的消息丢失。
  
  解决方案：
  通过持久化消息、队列和集群部署来提高消息的可靠性。
  
  （1）消息持久化
  
  生产者可以将消息标记为持久化消息，确保 RabbitMQ 崩溃重启后消息不会丢失：
```
MessageProperties.PERSISTENT_TEXT_PLAIN  // 持久化消息
```
  （2）队列持久化
  
  除了消息，队列本身也需要设置为持久化队列。即使 RabbitMQ 重启，队列依然存在并保存消息：
```
channel.queueDeclare("queueName", true, false, false, null);
```
  （3）镜像队列
  
  为了防止单点故障，可以采用镜像队列，即在 RabbitMQ 的多个节点上复制队列。当主节点宕机时，副本节点可以继续处理消息，保证消息的可靠性。
  
  三、总结
  
  要保证 RabbitMQ 的消息不丢失，需要从生产者、路由过程、消费者和 Broker 端采取一系列措施。消息丢失的常见原因包括：生产者发送失败、消息路由失败、消费者处理异常，以及 RabbitMQ 服务宕机未持久化。
  
  为解决生产者端的消息丢失问题，可以采用事务机制或发布确认机制，确保消息成功发送并得到确认。路由过程中，可以通过 mandatory 参数或设置备份交换机来处理路由失败的情况，确保消息到达队列。消费者端则应使用手动确认模式，保证消息处理完成后才返回 ACK，避免因处理失败导致消息丢失。同时，在 RabbitMQ 宕机的情况下，通过持久化消息和队列、配置镜像队列等方式保证消息不会丢失。
  
  综合以上机制，RabbitMQ 提供了一个较为全面的消息可靠性保证方案，虽然不能确保 100% 消息不丢失，但可以最大程度上减少消息丢失的风险。