RabbitMq如何保证消息可靠性投递？

1. 保证消息的成功发出

2. 保障Mq节点的成功接收

3. 发送端收到Mq节点（Broker）确认应答

4. 完善的消息补偿机制

解决方案：

1.消息落库，对消息状态进行打标。  

2.消息的延迟投递，做二次确认，回调检查

方案一：

第一步：

  消息先进行数据入库，（小规模的可以加事务，大规模的并发 尽可能不加事务，做补偿，有兴趣可以可以了解下阿里的TCC柔性事务）。

第二步：

发送消息(假设Borker收到了消息)

第三步:

broker端返回响应消息，confrom模式监听消息应答。

第四步：

更新数据库状态标记为已发送

第五步：

  （此时假设broker端返回响应消息，网络突然闪断，此时监听不到Ack,此时该消息在数据库中的状态是不会更新的）用分布式定时任务Elastic-job或者XXL-job等分布式定时任务框架做补偿机制，定时获取状态符合的数据重新发送，当然了消费端要做消息幂等性，以防止重复消费。

方案二：

    方案一在高并发的场景下是不适用的。

第一步： 

数据落库成功后， 消息发送到Broker

第二步：

消息发送后发送第二条消息（5分钟 延迟投递）假设都成功）注意两条消息不是同一个队列但是是同一个业务消息。

第三步：

消费端监听到制定队列，将消息收到进行处理 ，处理完成后

第四步:

 发送一个 Conform消息（内部重新生成 一个消息发送到mq【Callback Service】）

第五步：

Callback Service收到消息后，保存到数据库中

第六步：

监听 延迟发送的消息 拿到该消息放到数据库中进行对比如果存在 则不做处理，否侧RPC调用上游服务做补偿。