如何保证 RabbitMQ 的消息可靠传输

在 RabbitMQ 的整个消息传递过程中，有三种情况会存在丢失。

• 生产者把消息发送到 RabbitMQ Server 的过程中丢失
• RabbitMQ Server 收到消息后在持久化之前宕机导致数据丢失
• 消费端收到消息还没来得及处理宕机，导致 RabbitMQ Server 认为这个消息已签收

所以，我认为只需要从这三个纬度去保证消息的可靠性传输就行了。

生产者发送消息的角度

从生产者发送消息的角度来说，RabbitMQ 提供了一个 Confirm（消息确认）机制，生产者发送消息到 Server 端以后，如果消息处理成功，Server 端会返回一个 ack 消息。客户端可以根据消息的处理结果来决定是否要做消息的重新发送，从而确保消息一定到达 RabbitMQ Server 上。

RabbitMQ Server 端的角度

从 RabbitMQ Server 端来说，可以开启消息的持久化机制，也就是收到消息之后持久化到磁盘里面。设置消息的持久化有两个步骤：

• 创建 Queue 的时候设置为持久化        
• 发送消息的时候，把消息投递模式设置为持久化投递 

不过虽然设置了持久化消息，但是有可能会出现，消息刷新到磁盘之前，RabbitMQ Server 宕机导致消息丢失的问题。所以为了确保万无一失，需要结合 Confirm 消息确认机制一起使用。

消费端的角度

从消费端的角度来说，我们可以把消息的自动确认机制修改成手动确认，也就是说消费端只有手动调用消息确认方法才表示消息已经被签收。这种方式可能会造成重复消费问题，所以这里需要考虑到幂等性的设计。

预防丢失的常用解决方案

一般工作中每发送一条消息都会 log 记录一下.

解决步骤：

• 生产者将消息发送出去后，记录该消息到MySQL中并设置状态为未消费状态
• 消费者消费完该消息后更细消息的状态为已消费状态
• 设置定时任务，每天一查，遍历查询createTime < 1天的并且状态未被消费的消息，进行补发操作，注意幂等控制