开心一刻

　　昨晚和一哥们一起吃夜宵，点了几瓶啤酒

　　不一会天空下起了小雨，哥们突然道：糟了

　　我：怎么了

　　哥们：外面下雨了，我老婆还在等着我去接她

　　他给了自己一巴掌，说道：真他妈不是个东西

　　我心想：哥们真是个好丈夫

　　很快他补充道：喝酒怎么能分心呢

　　我一口啤酒直接笑喷而出

知识回顾

　　本文不讲什么是 RocketMQ ，不讲它的实现原理，只想和大家探讨下它的事务消息的正确使用方式

　　再探讨之前，先带大家回顾下知识点

　　事务消息的设计原理

　　 RocketMQ 在 4.3.0 版中已经支持分布式事务消息，采用 2PC 的思想实现事务消息提交，同时增加一个补偿逻辑来处理二阶段超时或者失败的消息，如下图所示

　　什么，英文看不懂？贴心的我早已想到，中文版的也有

　　其中有两个点：半事务、回查事务状态，值得我们重点回顾

　　Half 消息

　　何谓 half 消息？

　　消息发送方把消息发送到 MQ 服务，但是此消息的状态被标记为不能投递，处于这种状态下的消息称为 half 消息；消费方不能消费 half 消息

　　发送方对 half 消息二次确认后，也就是 Commit 之后，消费方才可以消费到；如果是 Rollback，该消息则会被删除，永远不会被消费到

　　事务状态回查

　　如果在 RocketMQ 事务消息的二阶段过程中失败了，例如在做 Commit 操作时（上图中的第 4 步），出现网络问题导致 Commit 失败，那么需要通过一定的策略使这条消息最终被 Commit

　　RocketMQ 采用了一种补偿机制，称为“回查”。Broker 端对未确定状态的消息发起回查，将消息发送到对应的 Producer 端（同一个 Group 的 Producer），由 Producer 根据消息来检查本地事务的状态，进而执行 Commit 或者 Rollback

　　值得注意的是，RocketMQ 并不会无休止的的信息事务状态回查，默认回查 15 次，如果 15 次回查还是无法得知事务状态，RocketMQ 默认回滚该消息

　　更多细节请查看：事务消息

实战示例

　　理论知识理解之后，就需要我们进行实操与分析了

　　需求背景

　　假设我们有两个服务：订单服务、积分服务，当用户成功下单之后，需要给用户加相应的积分

　　实现方式有很多种，你知道哪些？

　　假设我们用 RocketMQ 事务消息来保证最终一致性，我们又该如何实现？

　　环境准备

　　RocketMQ：4.8.0

　　rocketmq-client：4.9.2

　　Spring Boot：2.1.0.RELEASE

　　MySQL：5.7.29

　　MyBatis Plus：3.4.2

　　建表 SQL

-- order
CREATE TABLE `order`.`t_order` (
  `order_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
  `order_no` char(20) NOT NULL COMMENT '订单号',
  `user_id` bigint(32) NOT NULL COMMENT '用户id',
  `order_amount` decimal(16,2) NOT NULL,
  `note` varchar(255) DEFAULT NULL COMMENT '备注',
  PRIMARY KEY (`order_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
-- 不一定非要存half消息的事务id，实现方式有很多，甚至可以不用这张表，直接通过 t_order 新增字段来实现
CREATE TABLE `order`.`t_order_transaction_log` (
  `transaction_id` varchar(32) NOT NULL COMMENT '主键（half 消息的事务id）',
  `order_id` bigint(20) NOT NULL COMMENT '订单主键',
  `note` varchar(500) DEFAULT NULL COMMENT '备注',
  PRIMARY KEY (`transaction_id`) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;


-- points
CREATE TABLE `points`.`t_point` (
  `point_id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '自增主键',
  `order_no` char(20) NOT NULL COMMENT '订单号',
  `user_id` bigint(20) NOT NULL COMMENT '用户id',
  `point_num` decimal(16,2) NOT NULL COMMENT '积分数量',
  `note` varchar(255) DEFAULT NULL COMMENT '备注',
  PRIMARY KEY (`point_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

View Code

　　项目地址：spring-boot-rocketmq-order，spring-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 考虑的是数据最终一致性，上游服务提交之后，下游服务最终只能成功，做不到回滚上游服务的数据

参考

　　基于RocketMQ分布式事务 - 完整示例