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

简介 RabbitMQ高级篇一本章导航及BAT大厂如何保障生产端可靠性投递一:本章导航从本章节开始我们就要进入rabbitMq高级篇。我们先来看看本章导航:共分为九大模块。如下图:二:消息如何保证100%的投递成功?2.1:什么是生产端的可靠性投递?    思路:    保障消息的成功发布;   

🔔🔔🔔好消息!好消息!🔔🔔🔔

有需要的朋友👉:联系凯哥 微信号 kaigejava2022

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的消息,我们可以进行人工介入,进行人工消息补偿。


TopTop