MQ的整个过程中有三处可能产生消息的丢失
- 生产者到MQ的链路
- MQ自身宕机
- MQ到消费端的链路
生产者到MQ的消息丢失
生产者发送消息过程中可能因为网络问题等导致消息发送不成功，丢失数据，这个过程MQ提供了两种机制来解决：
- MQ事务
在生产端发送消息时，可以使用MQ提供的事务提交机制，当消息发送成功后才会提交事务继续运行，否则当次处理回滚
// 开启事务
channel.txSelect
try {
// 发送消息
} catch (Exception e) {
channel.txRollback
// 重发消息
}
// 提交事务
channel.txCommit
这种方式虽然可以保证发送消息的可靠性，但是由于事务机制是同步的，这样的操作会使MQ的吞吐量大大降低，所以一般场景下不建议这样去使用
- Confirm机制
在生产者端配置开启Confirm模式，每次向MQ发送的每一条消息都会被分配上唯一一个消息ID，在MQ接收到消息之后，会返回一个ack通知发送成功，相反如果没有接收到这个消息，则会回调nack接口，可以在回调方法中做重发。Confirm机制是异步操作进行的，所以对于这个问题是一个很好的解决方案
MQ自身故障
好不容易把消息发送到MQ上，生产端可以甩锅了，MQ自己想不背锅就不能自己忘了数据啊。所以MQ本身是有持久化功能的，根据生产者的要求，是否需要持久化消息。
生产者在持久化上要配置两个地方：
- queue的持久化设置，这样可以保证MQ会持久化queue的元数据，但是这不包括queue内的内容
- 消息发送时设置deliveryMode，记得是设置成2，这样发送的每条消息都会在MQ上持久化到磁盘
通过这两个持久化设置，基本就能保证消息不会因为MQ宕机的问题丢失了，在MQ重启的时候都会从磁盘上重新加载消息内容
MQ到消费端的消息丢失
在消费端的处理方式和生产端类似，主要都是和MQ之间要建立ack的机制。MQ在把消息给消费者时默认会使用自动ack的方式，要确保消费端确实消费了数据就要关闭自动ack，在消费端确实收到MQ发来的消息以后，再向MQ发送ack。如果消费端一直没有ack，那么MQ就会认为消息发送失败，就可以重发到别的消费者上。
这里存在一个问题就是如果消费端收到数据了，返回ack时宕机，或者ack发送过程中丢失了，这时MQ以为消息发送失败了重新发送，就会有重复发送的现象出现了，，关于这里就要确保有做幂等性的相关机制，参考我另一篇文章
