在使用RabbitMQ的时候，可以通过消息持久化来解决因为服务器的异常而导致的消息就是，但是还有一个问题，当消息的生产者将消息发送出去之后，消息到底有没有正确地到达服务器呢？如果消息在到达服务器之前已经丢失，持久化操作也解决不了这个问题，那么该如何解决呢？
RabbitMQ为我们提供了两种解决方案：
1.通过事务机制实现
2.通过发送方确认机制实现
因为事务机制比较消耗性能，在实际工作中使用也不多，在这里主要介绍confirm机制来实现发送方的确认.RabbitMQ为我们提供了两个方式来控制消息的可靠性投递
1.confirm确认模式
生产者在发送消息的时候，对发送端设置了一个ConfirmCallback的监听，无论消息是否到达Exchange，这个监听都会被执行，如果Exchange成功收到，ACK确认字符为true，如果没有收到消息 ACK就为false.
在这里要讲一下ConfirmCallback和ConfirmListener区别：
两者都是用来处理消息确认的机制，但他们属于不同的客户端库，并且使用场景和方式有所不同.
1.ConfirmListener时RabbitMQ java Client库中的接口，这个库时RabbitMQ官方提供的一个直接与RabbitMQ服务器交互的客户端库，它提供了两个方法：handleAck和handleNack，用于处理消息确认和否定的事件.
2.ConfirmCallback是Spring AMQP框架中的一个接口，专门为Spring环境设计，用于简化与RabbitMQ交互的过程，它只包含一个confirm方法，用于处理消息确认的回调
在Spring Boot应用中，通常会使用ConfirmCallback，因为它与Spring框架的其他部分更加整合，可以利用Spring的配置和依赖注入功能，而在使用RabbitMQ java Client库时，则可能会直接实现ConfirmListener接口，更直接的与RabbitMQ的Channel交互.
2.return退回模式
消息到达Exchange之后，会根据路由规则匹配，把消息放入Queue中，Exchange到Queue的过程，如果一条消息无法被任何队列消费，可以选择把消息退回给发送者.消息退回给发送者时，我们可以设置一个返回回调方法，对消息进行处理.