为了保证消息在 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 会将消息返回给生产者，生产者可以选择处理返回的消息或进行重试。
java
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 崩溃重启后消息不会丢失：
javaMessageProperties.PERSISTENT_TEXT_PLAIN // 持久化消息（2）队列持久化
除了消息，队列本身也需要设置为持久化队列。即使 RabbitMQ 重启，队列依然存在并保存消息：
javachannel.queueDeclare("queueName", true, false, false, null);（3）镜像队列
为了防止单点故障，可以采用镜像队列，即在 RabbitMQ 的多个节点上复制队列。当主节点宕机时，副本节点可以继续处理消息，保证消息的可靠性。
三、总结
要保证 RabbitMQ 的消息不丢失，需要从生产者、路由过程、消费者和 Broker 端采取一系列措施。消息丢失的常见原因包括：生产者发送失败、消息路由失败、消费者处理异常，以及 RabbitMQ 服务宕机未持久化。
为解决生产者端的消息丢失问题，可以采用事务机制或发布确认机制，确保消息成功发送并得到确认。路由过程中，可以通过
mandatory参数或设置备份交换机来处理路由失败的情况，确保消息到达队列。消费者端则应使用手动确认模式，保证消息处理完成后才返回 ACK，避免因处理失败导致消息丢失。同时，在 RabbitMQ 宕机的情况下，通过持久化消息和队列、配置镜像队列等方式保证消息不会丢失。综合以上机制，RabbitMQ 提供了一个较为全面的消息可靠性保证方案，虽然不能确保 100% 消息不丢失，但可以最大程度上减少消息丢失的风险。
- 在消费者处理完消息后，手动调用