消息中间件入门之 两种100%可靠性投递解决方案分析

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

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

生产端-可靠性传递
常见解决方案：

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

BIZ DB:订单数据库(或其他具体业务)
MSG DB：消息数据库

• 第1步：将订单入库，创建一条MSG(状态为0) 入MSG DB库
• 第2步：将消息发出去
• 第3步：监听消息应答(来自Broker)
• 第4步：修改消息的状态为1(成功)
• 第5步：分布式定时任务抓取状态为0的消息
• 第6步：将状态为0的消息重发
• 第7步：如果尝试了3次(可按实际情况修改)以上则将状态置为2(消息投递失败状态)

这种方案，需要入两次库(step1)，在高并发的场景下性能可能不是那么好

消息的延迟投递确认, 回调检查, 异步补偿

Upstream service：上游服务，可能为生产端
Downstream service：下游服务，可能为消费端
MQ Broker：可能为集群
Callback service：回调服务，监听confirm消息

• 第1步：首先业务数据落库，成功才后第一次消息发送
• 第2步：紧着着发送第2条消息（可以用于寻找第1条消息），用于延迟(可能2,3分钟后才发送)消息投递检查
• 第3步：Broker端收到消息后，消费端进行消息处理
• 第4步：处理成功后，发送confirm消息
• 第5步：收到confirm消息后，将消息进行持久化存储
• 第6步：收到了delay消息，检查DB数据库，若对应的第1条消息已处理完成，则不做任何事情；若收到了delay消息，检查DB数据库，发现对应的第1条消息处理失败(或无记录)，则发送重传命令到上游服务，循环第1步

这种方法不但是一次入库, 同时依靠异步确认, 还将可靠性保证的逻辑交给了broker 有效的降低了并发的压力.