本地消息表

在微服务架构中实现分布式事务时，往往需要在完成本地事务后，发送消息，以触发其他服务响应事件。这两个操作必须保证原子性，否则可能使整个系统处于不一致的状态。

传统的解决方案是在数据库和消息代理之间通过XA实现分布式事务，但遗憾的是，很多常用的消息代理，比如Apache Kafka并不支持XA分布式事务。

这个时候，可以通过在本地数据库中创建一个临时消息表，在更新业务数据的事务里，增加向这个临时消息表插入数据。利用本地数据库的ACID事务，来保证本地事务和发送消息的原子性。
然后通过异步的方式，将这个临时消息表中的消息发布到消息代理。
有2种方式来实现这个目的：

  • 轮询临时消息表，将消息发送到消息代理，再把完成发送的消息从临时消息表中删除。
  • 通过读取数据库的事务日志，比如mysql的binlog, 把每条与消息有关的记录发送给消息代理。

RocketMQ的事务消息

在上述的本地消息表方案中，生产者需要额外创建消息表，还需要对本地消息表进行轮询，业务负担较重。阿里开源的RocketMQ 4.3之后的版本正式支持事务消息，所谓事务消息，指的是在普通消息基础上，支持二阶段的提交能力。将二阶段提交和本地事务绑定，实现全局提交结果的一致性。

RocketMQ的事务消息交互流程
  1. 生产者将消息发送至Apache RocketMQ服务端。
  2. Apache RocketMQ服务端将消息持久化成功之后，向生产者返回Ack确认消息已经发送成功，此时消息被标记为”暂不能投递”，这种状态下的消息即为半事务消息。
  3. 生产者开始执行本地事务逻辑。
  4. 生产者根据本地事务执行结果向服务端提交二次确认结果（Commit或是Rollback），RocketMQ服务端收到确认结果后处理逻辑如下：
    • 二次确认结果为Commit：服务端将半事务消息标记为可投递，并投递给消费者。
    • 二次确认结果为Rollback：服务端将回滚事务，不会将半事务消息投递给消费者。
  5. 在断网或者是生产者应用重启的特殊情况下，若服务端未收到发送者提交的二次确认结果，或服务端收到的二次确认结果为Unknown未知状态，经过固定时间后，服务端将对消息生产者即生产者集群中任一生产者实例发起消息回查。
  6. 生产者收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
  7. 生产者根据检查到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤4对半事务消息进行处理。