消息如何保障100%的投递成功?
什么是生产端的可靠性投递?
- 保障消息的成功发出
- 保障MQ节点的成功接收
- 发送端收到MQ节点( Broker)确认应答
- 完善的消息进行补偿机制
生产端-可靠性投递(一)
BAT/TMD互联网大厂的解决方案:
- 消息落库,对消息状态进行打标
- 消息的延迟投递,做二次确认,回调检查
生产端-可靠性投递(二)
- 1.进行消息的入库
- 2.发送消息
- 3.将受到消息的应答返回给生产端
- 4.修改库中消息状态
- 5.查询数据库中数据，查看次数，假定次数为3，超过三次状态么米有被修改，确认没有受到消息
- 6.重发该消息，设置重发消息限制，假定三次，如果发了3次都不成功。设置消息状态为2.确认该消息存在问题，对此消息打标，人工确认。
生产端-可靠性投递(三)
- 保障MQ我们思考如果第-种可靠性投递,在高并发的场景下是否适合?
- 消息的延迟投递,做二次确认,回调检査
- 1.发送消息（生成两条消息 第一条真实消息，第二条消息，延迟确认的消息，可能延迟消息可能会在第2分钟或者第三分钟后发送）
- 2.broker接收消息
- 3.监听的消费端接收消息
- 4.消费端处理完消息之后，发送一个确认消息到broker
- 5.监听确认消息的消息队列，接收确认消息，Callback服务接收到，存储到数据库
- 6.延迟投递的消息发送了，被Check Detail监听到，Callback服务接收到，检查数据库是否存储
- 7.检查到没有储存，重发该消息，ReSend一次这个消息
- 8.重走该流程
相关文章：
-
2019-08-28
-
2019-08-26
-
2019-09-01
-
2021-09-15
-
2019-01-28
-
2021-12-18
-
2021-05-03
-
2021-08-17
猜你喜欢
-
2020-01-16
-
2021-11-08
-
2021-10-27
-
2021-05-14
-
2021-10-31
-
2021-10-15
-
2021-11-16
-
2021-11-11
相关资源
-
下载
2022-12-06
-
下载
2022-11-30
-
下载
2021-06-30