【RocketMQ】源码研究【005】rocketmq事务消息的应用

事务消息：

 概念介绍：

 事务消息：消息队列RocketMQ提供 基于类似2PC 的分布式事务功能，通过消息队列RocketMQ版事务消息能达到分布式事务的最终一致性。

 半事务消息：暂不能投递的消息，发送方已经成功地将消息发送到了消息队列 RocketMQ 版服务端，但是服务端未收到生产者对该消息的二次确认，此时该消息被标记成“暂不能投递”状态，处于该种状态下的消息即半事务消息。

消息回查：由于网络闪断、生产者应用重启等原因，导致某条事务消息的二次确认丢失，消息队列 RocketMQ 版服务端通过扫描发现某条消息长期处于“半事务消息”时，需要主动向消息生产者询问该消息的最终状态（Commit 或是 Rollback），该询问过程即消息回查。

典型场景：

在电商物车下单时，涉及到购物车系统和交易系统，这两个系统之间的数据最终一致性可以通过分布式事务消息的异步处理实现。在这种场景下，交易系统是最为核心的系统，需要最大限度地保证下单成功。而购物车系统只需要订阅消息队列 RocketMQ 版的交易订单消息，做相应的业务处理，即可保证最终的数据一致性。

交互流程：

 

事务消息发送步骤如下：

1. 发送方将半事务消息发送至消息队列 RocketMQ 版服务端。 （参考2PC中的prepare ）
2. 消息队列 RocketMQ 版服务端将消息持久化成功之后，向发送方返回 Ack 确认消息已经发送成功，此时消息为半事务消息。(得到第一步prepare结果为 成功)【注意此种状态的消息，是不会被消费的】
3. 发送方开始执行本地事务逻辑。（发起本地事务commit，然后根据本地事务执行的成功或者失败返回commit或者rollback）
4. 发送方根据本地事务执行结果向服务端提交二次确认（Commit 或是 Rollback），服务端收到 Commit 状态则将半事务消息标记为可投递，订阅方最终将收到该消息；服务端收到 Rollback 状态则删除半事务消息，订阅方将不会接受该消息。

事务消息回查步骤如下：

1. 在断网或者是应用重启的特殊情况下，上述步骤 4 提交的二次确认最终未到达服务端，经过固定时间后服务端将对该消息发起消息回查。
2. 发送方收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
3. 发送方根据检查得到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤 4 对半事务消息进行操作。

注意事项

• 事务消息的 Group ID 不能与其他类型消息的 Group ID 共用。与其他类型的消息不同，事务消息有回查机制，回查时消息队列 RocketMQ 版服务端会根据 Group ID 去查询客户端。【 为了保证高可用，这种事务类型的生产者一般部署多份，groupID需要一致】因为具体回查到哪个事务生产者，需要根据具体的负载策略来定。
• 通过 ONSFactory.createTransactionProducer 创建事务消息的 Producer 时必须指定checkLocalTransaction
  的实现类，处理异常情况下事务消息的回查。
• 事务消息发送完成本地事务后，可在 execute 方法中返回以下三种状态：
  • TransactionStatus.CommitTransaction：提交事务，允许订阅方消费该消息。
  • TransactionStatus.RollbackTransaction：回滚事务，消息将被丢弃不允许消费。
  • TransactionStatus.Unknow：暂时无法判断状态，等待固定时间以后消息队列 RocketMQ 版服务端向发送方进行消息回查。
• 可通过以下方式给每条消息设定第一次消息回查的最快时间：

  Message message = new Message();
  // 在消息属性中添加第一次消息回查的最快时间，单位秒。例如，以下设置实际第一次回查时间为 120 秒 ~ 125 秒之间
  message.putUserProperties(PropertyKeyConst.CheckImmunityTimeInSeconds,"120");
  // 以上方式只确定事务消息的第一次回查的最快时间，实际回查时间向后浮动 0 秒 ~ 5 秒；如第一次回查后事务仍未提交，后续每隔 5 秒回查一次                    

 

事务状态回查

   回查入口任务

org.apache.rocketmq.broker.transaction#TransactionalMessageCheckService

几个重要参数：

/**
 * Transaction message check interval.
 */
@ImportantField
private long transactionCheckInterval = 60 * 1000;

默认的检测周期 1分钟

/**
 * The minimum time of the transactional message  to be checked firstly, one message only exceed this time interval
 * that can be checked.
检查事务性消息的最短时间，也就是说，当这个消息到broken上超过6秒，才能进行回查。
 */
@ImportantField
private long transactionTimeOut = 6 * 1000;

/**
 * The maximum number of times the message was checked, if exceed this value, this message will be discarded.
   最大回查次数，如果超过此回查次数，消息将被丢弃
 */
@ImportantField
private int transactionCheckMax = 15;

经过跟踪如下：

新建了一个主题名字叫 TRANS_CHECK_MAX_TIME_TOPIC 读写队列都为1的 主题，然后把消息放到这里面了。

具体代码入口：

@Override
protected void onWaitEnd() {
    long timeout = brokerController.getBrokerConfig().getTransactionTimeOut();
    int checkMax = brokerController.getBrokerConfig().getTransactionCheckMax();
    long begin = System.currentTimeMillis();
    log.info("Begin to check prepare message, begin time:{}", begin);
    this.brokerController.getTransactionalMessageService().check(timeout, checkMax, this.brokerController.getTransactionalMessageCheckListener());
    log.info("End to check prepare message, consumed time:{}", System.currentTimeMillis() - begin);
}

 

最后拓展

 上面的事务其实是不完整的，只保证了生产者，生产的事务消息，如果不出异常的话一定能投递到消费者。但是如果最后消费端

消费事务消息的时候出异常了，怎样处理？这个就需要自己指定相应的补偿策略了。 或者就入上文所说的，订单下成功后，物流不允许失败，如果失败，常规做法时添加预警，或者人工干预。

 

大家也知道这个RocketMQ本来就是阿里家开源的，所以很多一手资料最好还是看阿里云的官方解释，比现有apache 上面的资料

可能解释的更明白。

参考资料：

https://help.aliyun.com/document_detail/43348.html?spm=a2c4g.11186623.2.21.bab42010V27FR6#concept-2047067