rabbitmq消息丢失的三种情况
- 生产者将消息发送到RabbitMQ的过程中时，消息丢失。
- 消息发送到RabbitMQ，还未被持久化就丢失了数据。
- 消费者接收到消息，还未处理，比如服务宕机导致消息丢失。
解决方案
生产者发送过程中，消息丢失
方案1 - 开启RabbitMQ事务
生产者发送消息之前，开启RabbitMQ事务channel.txSelect，如果消息没有成功被RabbitMQ接收到，那么生产者会收到异常报错，此时可以回滚事务channel.txRollback，然后重试发送消息，如果收到了消息，那么可以正常提交事务。channel.txCommit。（不建议，同步阻塞）
方案2 - 使用confirm机制
事务机制和Confirm机制最大的不同在于，事务机制是同步的，提交一个事务之后会阻塞在那儿，但是Confirm机制是异步的。
在生产者开启confirm机制后，每次写消息都会分配一个唯一id，然后RabbitMQ正常处理了这个消息，RabbitMQ会回传给你一个ack消息，告诉你这个消息发送ok了，如果没能正常处理，会回调一个nack接口，告诉你这个消息失败了，此时，你可以对这个消息发起重试。
并且你可以基于这个机制，维护每个消息的id，如果超过一定的时候还没接收到这个消息的回调，你可以进行重发。（消费者需要做好幂等）
RabbitMQ 服务端消息丢失
丢失场景：
- 未持久化消息
- 磁盘损坏或集群故障
方案 - 消息持久化
RabbitMQ的消息默认存放在内存上的，如果不特别声明设置，消息不会持久化保存到硬盘上，如果节点重启或者意外crash掉，消息就会丢失。
Exchange 设置持久化
Queue 设置持久化
Message 设置持久化
方案 - 设置集群镜像模式
RabbitMQ有以下三种部署模式
- 单节点部署
最简单的模式，非集群模式，节点挂了，业务瘫痪 - 普通模式（默认集群模式）
消息只会存在主节点上，不会同步到其他节点，当前节点宕机，有影响的业务会瘫痪，只能等待节点重启后恢复可用， - 镜像模式（镜像队列模式）
消息会同步到其他节点上，可以设置同步的节点个数，但吞吐量会下降，属于RabbitMQ的HA方案
以下是三种HA策略模式
- 同步所有的
- 同步最多N个机器的
- 只同步至服务执行名称的节点
消费者丢失消息
方案 - ACK确认机制
关闭自动应答（自动ack），业务服务端在确保正确处理完消息后，手动ack，避免消息还未被处理完就ack，这样就避免了，当一个消费者出了问题，也会有其他的消费者去消费， 保证了消息不丢失的场景。
