知识回顾本文不讲什么是 RocketMQ 不讲它的实现原理只想和大家探讨下它的事务消息的正确使用方式再探讨之前先带大家回顾下知识点事务消息的设计原理RocketMQ 在 4.3.0 版中已经支持分布式事务消息采用 2PC 的思想实现事务消息提交同时增加一个补偿逻辑来处理二阶段超时或者失败的消息如下图所示什么英文看不懂贴心的我早已想到中文版的也有其中有两个点半事务、回查事务状态值得我们重点回顾Half 消息何谓 half 消息消息发送方把消息发送到 MQ 服务但是此消息的状态被标记为不能投递处于这种状态下的消息称为 half 消息消费方不能消费 half 消息发送方对 half 消息二次确认后也就是 Commit 之后消费方才可以消费到如果是 Rollback该消息则会被删除永远不会被消费到事务状态回查如果在 RocketMQ 事务消息的二阶段过程中失败了例如在做 Commit 操作时上图中的第 4 步出现网络问题导致 Commit 失败那么需要通过一定的策略使这条消息最终被 CommitRocketMQ 采用了一种补偿机制称为“回查”。Broker 端对未确定状态的消息发起回查将消息发送到对应的 Producer 端同一个 Group 的 Producer由 Producer 根据消息来检查本地事务的状态进而执行 Commit 或者 Rollback值得注意的是RocketMQ 并不会无休止的的信息事务状态回查默认回查 15 次如果 15 次回查还是无法得知事务状态RocketMQ 默认回滚该消息更多细节请查看事务消息实战示例理论知识理解之后就需要我们进行实操与分析了需求背景假设我们有两个服务订单服务、积分服务当用户成功下单之后需要给用户加相应的积分实现方式有很多种你知道哪些假设我们用 RocketMQ 事务消息来保证最终一致性我们又该如何实现环境准备RocketMQ4.8.0rocketmq-client4.9.2Spring Boot2.1.0.RELEASEMySQL5.7.29MyBatis Plus3.4.2建表 SQLView Code项目地址spring-boot-rocketmq-orderspring-boot-rocketmq-points后续只会对关键代码进行讲解所以建议大家把代码 down 下来看看保证有个基本的印象回到标题楼主为什么会强调正确的打开方式你猜对了RocketMQ 事务消息的使用方式有很多种楼主就结合工作项目中的使用方式来和大家一起讨论下哪些方式是正确的哪些方式是不正确的以及不正确的原因结合 Half 消息发送的时机大致可分为三种根据 half 消息的位置我们暂且将这三种方式命名为half 消息后置、half 消息中置、half 消息前置我们逐个来讨论使用是否正确half 消息后置这种方式有没有觉得似曾相识与发普通消息是不是很类似 本地业务执行完之后发普通消息给积分中心是不是熟悉的味道但还是有区别的至少有回查机制我们结合伪代码具体看看我们来分析下各种异常情况看看这种方式是否有问题1、订单数据或订单事务日志落库异常事务回滚half 消息不会发送没问题2、half 消息发送异常事务会回滚没问题3、half 消息发送未发生异常但返回的不是 SEND_OK 状态代码抛出了异常事务回滚没问题思考如果我们不关注 half 消息发送的结果像这样最终消息会推送给积分服务吗虽然看起来怪怪的但又挑不出毛病half 消息中置我们直接看伪代码我们来分析下各种异常情况看看这种方式是否有问题1、订单数据落库异常事务回滚half 消息不会发送没问题2、half 消息发送异常事务会回滚没问题3、half 消息发送未发生异常但返回的不是 SEND_OK 状态代码抛出异常事务会回滚没问题思考与之前的思考问题一样如果我们不关注 half 消息发送的结果最终消息会推送给积分服务吗只有发送 half 消息成功并且发送状态为 SEND_OK 才会执行 executeLocalTransaction 向 t_order_transaction_log 表写入事务日志那么即使 Broker 回查事务状态它得到的结果始终是 UNKNOW 最终 half 消息会被回滚积分服务收不到消息导致的问题就是用户下单成功但却没有增加积分可见关注 half 消息发送结果的重要性4、half 消息发送成功且返回的是 SEND_OK 状态但 executeLocalTransaction 执行异常了会是什么结果代码很明显我们进行了 catch 异常不会向上抛订单落库还是成功的只是订单事务日志落库失败了返回 ROLLBACK_MESSAGE half 消息会回滚积分服务收不到消息那么同样的问题又出现了用户下单成功但却没有增加积分如果我们不 catch 像这样理论上来讲异常往上抛订单数据会回滚 Broker 回查事务状态一直返回 UNKNOW 最终积分服务收不到消息理论上来讲没问题但事实呢 我们来实践一下哦豁竟然没有打印异常日志也就说异常被 catch 没有往外抛订单数据也落库了那么又会出现同样的问题用户下单成功但却没有增加积分至于谁把异常 catch 了没往外抛相信大家都能想到这算是 rocketmq-client 的一个 bug 源码稍后再跟我们先看完前置half 消息前置直接上伪代码我们来分析下各种异常情况看看这种方式是否有问题1、half 消息发送异常本地事务不会执行没问题2、half 消息发送未发生异常但返回的不是 SEND_OK 状态代码抛出异常本地事务不会执行没问题思考与之前的思考问题一样如果我们不关注 half 消息发送的结果会是什么结果只有 half 消息发送成功且返回状态是 SEND_OK 才会执行 executeLocalTransaction即使 Broker 回查事务状态得到的结果始终是 UNKNOW 最终 half 消息会被回滚积分服务收不到消息订单服务与积分服务都没有落库成功也就说是没问题的3、half 消息发送成功且返回的状态是 SEND_OK 但 executeLocalTransaction 执行异常了会是什么结果也就是 save 方法执行异常了我们来实践下异常还是被 catch 了没往外抛但是订单数据却回滚了就结果而言是没问题的half 消息发送成功了但是 Broker 一直未收到本地事务的确认消息 Broker 会回查得到的结果始终是 UNKNOW 最终 half 消息会被回滚积分服务收不到消息订单数据回滚了积分服务未收到消息那么此种情况是没问题的看起来挺顺眼异常情况下也没什么问题rocketmq-client 的 bug需要弄清楚的问题有两个1、half 消息中置 executeLocalTransaction 的异常为什么没有抛出来2、half 消息前置 异常同样没有抛出来为什么订单数据却回滚了先看第一个问题我们来跟下源码rocketmq-client 捕获了异常但并未向外抛其实 RocketMQ 是有打印日志的只是楼主的日志配置的不对导致控制台未打印出来对于第 1 个问题相信大家已经清楚了关于第 2 个问题我就不具体分析了我给个提示从事务 AOP 的控制范围与异常抛出点来考虑如下图最终一致性前面讲了那么多都是讲的订单服务总结起来就是事务消息而非 half 消息发送成功那么本地事务一定是执行成功的保证的是事务消息的发送与订单服务的强一致如果积分服务消费异常呢那对不起RocketMQ 事务消息处理不了这种情况回滚不了订单服务的数据只能通过补偿机制比如人工修复修复积分服务的数据总结1、三种方式的抉择half 消息中置问题比较多不推荐half 消息后置看起来挺别扭的难道只是楼主这么觉得倒是没什么问题half 消息前置符合 RocketMQ 事务消息的设计原理推荐采用此种方式2、一定要关注 half 消息发送的结果不抛异常不代表一定成功了必要时需要根据 half 消息发送的结果做后续逻辑处理3、最终一致性RocketMQ 考虑的是数据最终一致性上游服务提交之后下游服务最终只能成功做不到回滚上游服务的数据