交换器不存储消息,所有消息都要路由到队列存储。如果中间过程消息丢失,对于生产者而言不设置的情况下是无法知晓的错误。Mandatory实现与Confirm实现类似,通过增加监控监听Listener实现。前面文章消息与队列进阶详细描述过这个参数监听
当消息到达交换器,但是没有匹配队列路由存储时。若通过Mandatory实现监听处理则需要如下几个处理过程:

ReturnListener中仅仅包含唯一方法handleReturn(),该方法中含有系列参数,参数含义如下表所示:

Mandatory增加的ReturnListener监听需要在发送消息代码中增加逻辑,这对于追求功能专一性而言不是好消息。通过RabbitMQ也根本检测不到这段逻辑,也不利于后续代码维护。所以提出备用交换器,创建交换器时绑定,当交换器消息未找到路由队列时消息将转发到备用交换器
备用交换器其原理类似于交换器与交换器绑定,需要注意以下几点:
通过参数Map绑定备用交换器,验证效果将消息发送路由键routingKey设置为备用交换器路由键。可以查看备用交换器创建时的第五个参数,上面也提到最优设置为内置交换器,属性internal
最后显示备用交换器中有一条消息,证明结果的正确性。备用交换器可以用作消息不能正确路由时的一种解决方案

这个问题在前面相关队列与队列消息的文章中已经详细讲解,为了整个消息投递可靠性的完整,这里再次描述一下队列与队列消息的持久化。注意以点:
单独的队列消息持久化并不能实现消息持久化,同理单独的队列持久化也不能实现消息持久化。需要队列与队列消息同时持久化方可
持久化即将队列信息写入磁盘持久化保存,当RabbitMQ应用服务故障宕机重启时可以自动进行数据恢复的操作称之为队列持久化。实现只需要在创建队列时将持久化参数设置为true即可,如下所示:

进入RabbitMQ应用的WEB页面控制台查看该队列标志D,表示持久化。如下所示:

队列持久化 + 队列消息持久化 = 完整持久化,持久化对RabbitMQ应用的性能是一种负担,可以根据数据类型进行范围数据持久化。如订单数据、支付数据等等较为重要的数据可以采用持久化的操作尽量避免消息丢失
生产者消息已经投递并路由到队列存储,当消费者消费时消费应用宕机导致消费逻辑不完整的宕机也是保证消息百分百投递消费的关键一环。RabbitMQ针对这一点提供消费者确认机制,配置该特性后,当且仅当消费者确认以后RabbitMQ应用才会删除消息
讲解RabbitMQ消费者确认机制前需要确认默认情况下消费者将自动确认,也就是当消息从RabbitMQ应用服务取出时将被删除,这也是诱发消息丢失的原因。所以为了实现后续手动控制消息确认的逻辑,消费消息时就需要将参数autoAck设置为false

消息确认,参数包含deliveryTag、multiple。作用与生产者确认Confirm一致:
消息拒绝有两个API,basicReject()与basicNack(),两者唯一的差距在于前者不能进行multiple的批量操作。两者共同含有以下两个参数属性: