RocketMQ13-事务消息的理解

1.事务消息流程图

RocketMQ采用了2PC(二阶段提交)的思想来实现了提交事务消息，同时增加一个补偿逻辑来处理二阶段超时或者失败的消息，如下图所示。

?

?

2.RocketMQ事务消息流程概要?

根据上图可以有一个大概的理解，其中分为两个流程：正常事务消息的发送及提交、事务消息的补偿流程。

2.1事务消息发送及提交：

1. 生产者发送消息到broker（这个消息暂时称为：half消息(半事务消息))
2. broker服务端响应消息写入结果。
3. 生产者根据发送结果执行本地事务（如果写入失败，此时half消息对业务不可见，本地逻辑不执行）
4. 生产者根据本地事务状态执行Commit/Rollback，broker收到执行状态后处理逻辑如下：

• 二次确认结果为 Commit：broker将半事务消息标记为可投递，并投递给消费者；
• 二次确认结果为 Rollback：broker将回滚事务，会将消息储存一定时间后删除。

2.2补偿流程：

1. 对没有Commit/Rollback的事务消息（pending状态的消息），从服务端发起一次“回查”
2. Producer收到回查消息，检查回查消息对应的本地事务的状态
3. ?根据本地事务状态，重新Commit/Rollback

3. 几个概念

3.1事务模式

RocketMQ 提供类似 XA 或 Open XA 的分布式事务功能,通过该功实现最终一致性的分布式事务

3.2半事务消息

暂不能消费的消息，Producer已经成功地将消息发送到了Broker，但是Broker未收到最终确认指令，此时该消息被标记成“暂不能消费”状态，即不能被消费者看到。处于该种状态下的消息即半事务消息

3.3消息回查

消息回查，即重新查询本地事务的执行状态（也就是上图中的步骤6）。

假如张三给李四转账，张三首先发送一条需要转账的消息到MQ, 发送成功后，张三开始从建设银行卡扣款，可能由于网络的问题，张三在扣款的时候发生了故障，出现了扣款未知(UNKNOW, 就不是成功也不是失败)的状态，紧接着张三将这条UNKNOW状态的消息发给MQ, MQ 接收到是UNKNOW状态，则需要发起回查，给张三个机会，看看网络是不是好了，好了就扣款，如果是余额不足，那就结束转账。

在RocketMQ中，事务消息有三个状态：

public enum LocalTransactionState {
    //本地事务执行成功，给broker发送一个commit的标识
    COMMIT_MESSAGE,
    
    ROLLBACK_MESSAGE,
    
    //这个状态将会引起回查
    UNKNOW,
}