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