消息在传递过程中，任何一个环节都有可能发生丢失的状态。所以我要从生产者、MQ、消费者三个方面去梳理并提供不丢失的方案。
1、生产者
生产者在发送消息的过程着由于网络问题导致消息丢失；
消息还在rabbitmq的内存中，还未持久化的磁盘的时候宕机了，这时消息会丢失。
这时我们2种方案
-
开启rabbitmq的事务功能
生产者在投递消息之前开启事务，如果消息没有成功被rabbitmq接收到，那么生产者就会接收到异常报错，然后回滚事务，重试发送消息。如果mq接收成功，则提交事务。
但有一点MQ的事务机制是同步的，严重影响性能和吞吐量，不建议使用。 - 开启rabbitmq的confirm模式（推荐）
- 相比较事务机制，最大的不同在于confirm是异步的，你发送完消息后，可以发送下一条。当MQ接收成功后，会异步回调我们的监听接口通知我们成功了。
- 同样confirm也是有自己的不足。confirm具有高延迟性，因为投递给MQ后消息会先驻留在内存中，然后过几百毫秒后才会批量持久化到磁盘中，然后我们才会收到ack。
- 优化方案
我们可以把发送的消息放在redis中，然后监听ack采用异步处理。成功了就删除，失败了就重新投递。
2、MQ集群
对于MQ来说，我们需要做到持久化到磁盘才能保障数据不丢失。但是如果MQ磁盘也挂了呢？所以我们要采用MQ集群，并开启持久化。
- 采用mq的集群模式
rabbitmq的集群模式有2种，一种是普通集群模式不具备高可用，所以我们要采用镜像集群模式。 - 开启rabbitmq持久化
队列持久化durable=true；消息持久化deliveryMode=2在springboot中该值默认是持久化的。
3、消费者
在消费者这边为了避免丢失，我们要关闭autoACK方式，采用手动ack，只有消费者消费完成后才去提交ack。
4、高并发情况
如果高峰期突发10倍流量，恰好此时MQ集群也挂了，消息该如何处理才能不丢。
我们可以在生产者这边进行持久化，可以采用内存双缓冲+批量持久化到磁盘。
