使用消息中间件时，有一个非常重要的问题，如何保证发送端发的每一个消息，接收端一定都能接收并消费成功，不会少消费，也不会重复消费？
如图，要想整个流程安全可靠，那么消息投递过程中一定要确保MQ收到消息，MQ则是要做持久化，保证消息不会丢失，消息消费过程需要确保消息成功消费后，在确认，并且需要防止重复消费
确保消息正确地发送至RabbitMQ
将 channel 设置成 confirm 模式（发送方确认模式），则所有在 channel 上发布的消息都会被指派一个唯一的ID。一旦消息被投递到目的队列后，或者消息被写入磁盘后（可持久化的消息），信道会发送一个确认给生产者（包含消息唯一ID）。 如果RabbitMQ发生内部错误从而导致消息丢失，会发送一条nack（not acknowledged，未确认）消息。
发送方确认模式是异步的，生产者应用程序在等待确认的同时，可以继续发送消息。当确认消息到达生产者应用程序，生产者应用程序的回调方法就会被触发来处理确认消息
确保消息接收方消费了消息
消费方接收每一条消息后都必须在消费完之后进行手动确认（消息接收和消息确认是两个不同操作）消费端确认之后，RabbitMQ 会把消息从队列中删除
这里并说到超时机制，RabbitMQ仅通过消费端的连接中断来确认是否需要重新发送消息。也就是说，只要连接不中断，RabbitMQ给了消费端足够长的时间来处理消息。保证数据的最终一致性；
下面罗列几种特殊情况： 如果消费者接收到消息，在确认之前断开了连接或取消订阅，RabbitMQ会认为消息没有被分发，然后重新分发给下一个订阅的消费者。（可能存在消息重复消费的隐患，需要去重） 如果消费者接收到消息却没有确认消息，连接也未断开，则RabbitMQ认为该消费者繁忙，将不会给该消费者分发更多的消息。
避免消息重复投递
在消息生产时，MQ内部针对每条生产者发送的消息生成一个inner-msg-id，作为去重的依据（消息投递失败并重传），避免重复的消息进入队列；
避免消息重复消费
方法一： 在消息消费时，要求消息体中必须要有一个唯一Id（对于同一业务全局唯一，如支付ID、订单ID、帖子ID等）作为去重的依据，避免同一条消息被重复消费
方法二：消费消息接口做幂等处理
确保Mq中消息不丢失
消息持久化，将queue的durable设置为true,则代表是一个持久化的队列 RabbitMQ确保持久性消化能从服务器重启中恢复的方式是，将它们写入磁盘上的一个持久化日志文件，当发布一条持久性消息到持久交换器上时，Rabbit会在消息提交到日志文件后才发送响应。
一旦消费者从持久队列中消费了一条持久化消息，RabbitMQ会在持久化日志中把这条消息标记为等待垃圾收集。如果持久化消息在被消费之前RabbitMQ重启，那么Rabbit会自动重建交换器和队列（以及绑定），并重新发布持久化日志文件中的消息到合适的队列
消息投递的可靠性
消息投递的可靠性 主要靠 投递方来实现
主流做法是
- 发送消息前，先将消息持久化到本地(比如数据库)，防止消息发送失败时，再次发送找不到原来的消息
- 设置发送方确认模式
- 发送消息后，将消息的状态存入数据库并设置为发送中
- 发送端设定签收超时时间并监听 RabbitMQ 看消费端是否有签收
- 如果监听到签收，则将该消息的状态改为投递成功，否则一直等待直到超时
投递成功，流程就走完了，但如果超时，就需要一定的补偿机制
- 起一个定时任务，每隔一段时间，从数据库中找出状态为发送中且时间超时的消息，重新投递
- 如果多次重投后依然失败，就需要人工去处理
