RocketMq事务消息原理及分布式事务场景分析

前言

分布式事务，是一个在每个微服务项目中都绕不开的问题。常见的解决分案有通过Redis、zk、mq、seata等方式处理。这篇博文全面的分析一下RocketMq中事务消息的机制。

场景案例

事务的经典场景有很多，如银行转账、订单库存等等。相对于分布式事务来说，订单系统和库存系统间的事务场景更为形象。如：用户操作下单，我们首先需要生成一条订单信息，然后库存系统需要针对订单中的商品进行库存扣减的操作。这两步操作必须保证数据的一致性，否则会出现库存超扣等情况。

使用RocketMQ处理分布式事务

rocketMq主要解决的问题是确保本地事务执行和事务消息发送的一致性问题。也就说保证本地事务提交成功后消息能够正常发出，本地事务提交失败，事务消息无效。下图为RocketMq事务消息生产者的设计思路。

对于事务消息的消费方而言，如果消费失败，将会和普通消息作出相同的处理，重试N次后，抛出异常/丢弃等处理。rocketMq开源的代码中并没有很好的处理这个问题，如果出现这个情况，需要人工介入处理。

RocketMQ事务消息设计分析

第一种情况如图所示，在本地事务提交前发送事务消息。若在创建订单信息时发生了异常，而此时事务消息已经成功发送，库存系统消费事务消息就会导致订单并没有创建成功，而库存却被扣减。

进而有了第二种情况，如图所示，在本地事务提交完成后再发送事务消息。若在发送事务消息的过程发生了异常，如网络波动等等，将会出现订单已创建完成，而库存系统永远也监听不到消息，导致库存无法正常扣减。

综合第一和第二种情况，汇总成第三种方案如图所示。在本地事务执行前，先向MQ发送前置的Prepared消息，在本地事务执行完毕后，再发送确认的消息，告知MQ当前事务消息需提交/回滚。如果事务正常提交成功，那么这条消息将会被消息消费方监听到；如果事务回滚，MQ会丢弃这条消息，消息消费方无法监听到这条消息。以上情况对应 事务消息生产者的设计思路 图中的  1、2、3、4步骤。

继续分析，如果上图的第二步中，发送确认消息的过程中，出现异常，没有发送成功怎么办？RocketMQ会定期（默认60s）扫描Prepared消息，如果迟迟没有收到确认消息，将会执行事务回查的逻辑，主动去消息生产方确认事务状态。对应 事务消息生产者的设计思路 图中的  5、6、7步骤。综上，是事务消息中生产者的设计思路，保证本地事务和事务消息一致性。

消费事务消息

如上图中，在事务消息者中，如果步骤4返回了消费失败或者超时未响应的情况，怎么办？RocketMQ对待事务消息的处理和普通消息一样。如果消费失败或超时，将会把这条消息加入到重试队列中，不断是重复执行步骤3、4，如果重复的次数达到阈值，那么可能需要人工介入处理。

如果消费方本地事务执行成功，仅仅是在确认消息时失败呢？ 那么这里又会出现另一个问题 重复消费？ 这里就需要具体的业务模块去处理消息的幂等性。如接住Redis来处理。如在本地事务执行前先去查询redis中当前消息是否已经消费，执行成功后再向redis写入一条成功消费的记录，这样就能保证消费不会被重复消费了。

Q&A

Q：从一致性方面考虑，直接采用RPC也可以完成，RPC也支持重试，为什么还要采用MQ?

A：首先应该分清MQ和RPC的应用场景，在现在微服务的架构下，所有人都强调低耦合高内聚，做业务上的解耦，直接采用RPC的方式就会出现强依赖，与微服务的理念背道而驰。

Q：为什么事务消息消费失败后，需要人工介入处理？

A：首先对于一个复杂的系统来讲，将实现整个业务逻辑回滚的代价是巨大的，不但系统复杂度将大大提升，而且还会引入新的问题，如在回滚的过程中又出现了其他事务异常，又该如何处理？其次在一个健壮的系统中出现事务回滚的情况本来就是概率极低的情况，在程序设计时，需要衡量一下为解决这个问题付出的人力物力成本值不值得。

Q：为什么不直接在消息服务层面解决重复消费的问题？

A：消费重复消费解决可以从两个方面考虑。第一 消费方处理消息的业务逻辑保持幂等性，只要保持幂等性，不管重复消费多少次，结果都是一样的；第二保证每条消息都有唯一编号且保证消费处理成功和去重表的日志同时出现，正常情况下出现重复消费的概率并不大，如果消费系统对所有的消费都做处理的话，对系统的吞吐量和高可用会产生影响，所以最好由各自业务系统决定如果处理重复消费。

Q：RocketMQ没能从根本上结果分布式事务问题

A：RocketMQ自身没办法做到像本地事务处理添加@Transactional注解就可以完成事务的提交和回滚。如果有需要，可以尝试使用seata中间件来处理分布式事务。