RabbitMQ高级篇一 本章导航及BAT大厂如何保障生产端可靠性投递

RabbitMQ高级篇一 本章导航及BAT大厂如何保障生产端可靠性投递

一：本章导航

从本章节开始我们就要进入rabbitMq高级篇。我们先来看看本章导航：

共分为九大模块。如下图：

二：消息如何保证100%的投递成功？

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

    思路：

    保障消息的成功发布；

    保障MQ节点的成功接收；

    发送端收到MQ节点(Broker)确认应答

    完善的消息进行补偿机制

2.2：BAT/TMD互联网大厂的解决方案

    消息持久化入库，对消息状态进行标记

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

2.3先来看看消息持久化入库，对消息状态进行标记的思路。

如上图所示。说明：

消息信息入库，对消息进行打标大致可以分为以下七个步骤

以订单消息为例经行讲解。

1：当有消息到达后，先将消息信息入库到BIZDB库中(消息状态为0 发送中)，同时将需要发送给下一个系统的消息也进行入库。如果都两此入库都没有异常信息，再有sender进行发送。

2：将msg发送个消费者MQ Broker端

3：消费端消费后或者接收到消息后，给出应答。生产者的confirmListener进行异步监听。如果收到true的应答进行第四步操作

4：将msg数据状态修改为1 已处理

1—4步是正常的流程。假设在第三步给第四步发送消息的时候，网络抖动导致第四步一直没有收到消息怎么办？

此中情况，我们就要进行第五、六、七步的操作。

5：通过分布式的定时任务将msgdb中状态为0且创建时间是5分钟之前的消息都抽取出来，为第六步准备

6：我们通过retry send 重新发送。执行第二、三、四步操作。

一般情况下，retry send之后，会解决很多第一次没有收到消息的。但是，在生产上，有时候还有有其他 情况，如之前使用的routingkey，最近不使用了，被下线了或者其他原因导致第三步一直不往下执行。这个时候就需要我们的第七步操作了。

7：我们定时执行，但是执行的总次数有个上限。不可能一直无限次的retry send的。假设我们执行了3次依然收不到消费者的响应，此时我们可以将消息状态更新为2(消息未正常接收)即可。

针对于状态为2的消息，我们可以进行人工介入，进行人工消息补偿。

本文首发凯哥个人博客：www.kaigejava.com

凯哥公众号：凯哥Java(kaigejava)