RocketMQ使用心得1-消息发送

去年末接触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中的监听是一个必不可少的模块。

  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值