RabbitMQ高级特性--消息如何保障100%的投递成功

什么是生产端的可靠性投递？

• 保证消息的成功发出
• 保证MQ节点的成功接收
• 发送端收到MQ节点（Broker)确认应答
• 完善的消息进行补偿机制

生产端-可靠性投递（一）

BAT/TMD互联网大厂的解决方案:
消息落库,对消息状态进行打标
(需要对数据库持久化两次,消息状态的修改)

• step1业务入库和消息入库
• step2:step1成功,生产端的Sender进行消息发送(消息状态初始值为0)
• step3:Broker(Server)收到消息并发送应答给生产端的Confirm Listener
• step4:Confirm Listener异步监听Broker的应答消息并进行判断
  假设step2通过，在step3回送响应时，网络突然出现了闪断，导致生产端的Listener收不到这条消息的confirm应答，消息的状态始终为0
• step5:分布式定时任务抓取状态为0的消息
• step6:将状态为0的消息重发
• step7如果尝试了3次(可按实际情况修改)以上则将状态置为2(消息投递失败状态)

生产端-可靠性投递（二）

保证MQ我们思考如果第一种可靠性投递,在高并发的场景下是否合适

在第一种情况下,高并发的情境下,数据库的两次写操作和读取操作会存在数据库IO瓶颈

解决方案
消息延迟投递,做二次确认,回调检查

目的是为了减少像方案一中的数据库操作

Upstream service：上游服务，可能为生产端
Downstream service：下游服务，可能为消费端
MQ Broker：可能为集群
Callback service：回调服务，监听confirm消息,独立的服务
下述直接假定上述可能

• step1 业务数据入库,成功后生产端发送消息到Broker
• step2 消息发送成功之后,生产端发送一条延迟消息(Second Send Delay Check),需要设置延迟时间
• step3 消息队列进行指定队列的监听,对收到的消息进行处理
• step4 消费端处理完毕之后,发送Confirm(不是ACK)到Broker
• step5 Callback service是一个单独的服务，其实它扮演了方案一的存储消息的DB角色,它通过Broker去监听消费端发送的Confirm消息,如果收到消息,那么将消息持久化到DB当中.
• step6 一定延迟时间之后再次发送消息给Broker,然后还是Callback Service去监听延迟消息所对应的队列.收到之后去检查MSG DB中是否有这条消息,如果存在,通过.不存在或者是消毒费失败了,那么Callback Service就需要主动发起RPC通信给上游服务,告诉它延迟投递的这条消息没有找到，需要重新发送，生产端收到信息后就会重新查询业务消息然后将消息发送出去,循环第一步。

方案二主要目的是为了减少对数据库的操作，提高并发量。 而不是关心消息是不是能够100%的投递成功.
参考课程:https://coding.imooc.com/class/262.html