RabbitMQ高级篇一 本章导航及BAT大厂如何保障生产端可靠性投递
- RabbitMQ学习系列教程
- 时间:2019-07-19 09:02
- 3417人已阅读
🔔🔔🔔好消息!好消息!🔔🔔🔔
有需要的朋友👉:联系凯哥
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的消息,我们可以进行人工介入,进行人工消息补偿。