mq和MySQL的可靠性比较_MQ消息可靠性保证----以RabbitMQ为例

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以为消息发送失败了重新发送，就会有重复发送的现象出现了，，关于这里就要确保有做幂等性的相关机制，参考我另一篇文章