去年末接触RocketMQ,主要因为官方标注消息必达,项目为支付相关,通过Restful
api接收订单存库+推送MQ,再由消费端支付。后期发现即使消息必达,但消息不一定100%发送成功,那么如何判断消息发送成功又成为了一个坑。

消息发送结果SendStatus分4种SEND_OK、FLUSH_DISK_TIMEOUT、FLUSH_SLAVE_TIMEOUT、SLAVE_NOT_AVAILABLE,理论上如果broker配置同步落盘+同步双写,那么只有SEND_OK才能明确标识发送成功,其它状态为发送失败,但是实际上回执其它3种状态时消息都发送成功。因此改为如果消息发送无异常则认为消息发送成功,然而后期高并发测试中出现了消息发送异常,但是消费端接到了消息
,尝试了2种解决方案,最终使用了方案2:

方案1:如果消息发送异常,则数据回滚,同时在消费端增加消息确认,比如订单是否入库,但是存在一个问题,有可能consumer消息接收速度比数据commit更快,那么就会出现消费端先判断数据不再数据库,而后数据才插入,因此方案1不论从性能还是逻辑上都比较差,pass。

方案2(推荐)
:api接收订单后入库,不论MQ消息是否发送成,都返回请求成功,无需回滚。增加监听程序,定时把超时未消费(即消息发送失败)的订单补发消息,这个方案相对好在发送消息使用默认配置也可以,可以不加大发消息重试次数和重试超时时长限制,以最快的速度接收订单+存库+推送消息。消息发送失败是比较极端情况,因此监听任务量不大而且执行逻辑非常简单,补发消息就是了。

建议不论使用什么MQ,消息吞吐量和消息必达的测试结果都是扯淡的,加上业务逻辑后就会出现各种各样的坑,如果希望确保消息必达或必发,那么方案2中的监听是一个必不可少的模块。

技术
©2019-2020 Toolsou All rights reserved,
2021年2月程序员工资统计,平均15144元初识MySQL之综合复习篇(干货)Faster RCNN系列算法原理讲解(笔记)谷歌称居家办公影响工作效率!2021 年将回归线下办公C语言控制台小游戏,打砖块GDOI2019 游记CSS架构设计Python基础知识整理笔记2019年终总结——工作第二年用C++跟你聊聊“原型模式” (复制/拷贝构造函数)