在这个图中，消息可能丢失的场景是1，2，3
1.在生产者将消息发送给RabbitMQ的时候，消息到底有没有正确的到达服务器呢，RabbitMQ提供了两种解决方案：
a. 通过事务机制实现（比较消耗性能，此处不展开）
b. 通过发送方确认（publisher confirm）机制实现
发送方确认：
RabbitMQ提供了两个方式来控制消息的可靠性传递
1.confirm确认模式
2.return退回模式
confirm确认模式：
在producer发送消息的是和，对发送端设置一个ConfirmCallback的监听，无论消息是否到达Exchange，这个监听都会执行，如果Exchange成功收到，ACK会确认为true，如果没收到消息ACK就为false。
2.消息在交换机中无法路由到指定队列：
可能原因：代码或者配置层面错误，导致消息路由失败。
return退回模式：
消息到达Exchange之后, 会根据路由规则匹配, 把消息放⼊Queue中. Exchange到Queue的过程, 如果⼀条消息⽆法被任何队列消费(即没有队列与消息的路由键匹配或队列不存在等), 可以选择把消息退回给发送者. 消息退回给发送者时, 我们可以设置⼀个返回回调⽅法, 对消息进⾏处理.
3.消息队列自身数据丢失：
可能原因：消息到达rabbitMQ中，mq宕机导致消息丢失
解决办法：开启RabbitMQ持久化，就是把消息写入磁盘中，如果RabbitMQ挂了，重启之后会自动读取磁盘中的数据恢复到内存中（但是，还是有一些非常极端的情况，RabbitMQ还未将全部数据持久化到磁盘中，服务器就挂了，还是会导致一些数据丢失的，可以通过集群来提高可靠性）
4.消费者异常，导致消息丢失（也就是上图中3那个过程）
可能原因：消息到达消费者，还没来得及消费，消费者宕机或者消费者逻辑有问题
解决办法：RabbitMQ提供了消费者应答机制，来使得RabbitMQ能够感知到消费者是否成功消费消息，默认情况下是自动应答的，但是一些比较重要的场景和近期相关的，我们也可以手动确认，当消费者确认消费信息成功之后才会删除消息，从而避免消息丢失，除此之外，也可以配置重试机制，当消息消费异常时，通过消息重试确保消息的可靠性。
