RocketMQ第九章：手把手教老婆代码实现-事务消息生产者和事务消息消费者 及深入源码探索事务的消息回查

(4)此时执行本地事务后，并没有执行Commit或Rollback操作

(5) 对没有Commit/Rollback的事务消息（pending状态的消息），从服务端发起一次“回查”（最多重试15次（由配置参数决定），超过了默认丢弃此消息）

(6) Producer收到回查消息，检查回查消息对应的本地事务的状态

(7) 根据本地事务状态，重新Commit或者Rollback

其中，补偿阶段用于解决消息Commit或者Rollback发生超时或者失败的情况。

3）事务消息状态

事务消息共有三种状态，提交状态、回滚状态、中间状态：

• TransactionStatus.CommitTransaction: 提交事务，它允许消费者消费此消息。

• TransactionStatus.RollbackTransaction: 回滚事务，它代表该消息将被删除，不允许被消费。

• TransactionStatus.Unknown: 中间状态，它代表需要检查消息队列来确定状态。

使用限制

---

1. 事务消息不支持延时消息和批量消息。

2. 为了避免单个消息被检查太多次而导致半队列消息累积，我们默认将单个消息的检查次数限制为 15 次，但是用户可以通过 Broker 配置文件的 `transactionCheckMax`参数来修改此限制。如果已经检查某条消息超过 N 次的话（ N = `transactionCheckMax` ） 则 Broker 将丢弃此消息，并在默认情况下同时打印错误日志。用户可以通过重写 `AbstractTransactionCheckListener` 类来修改这个行为。

3. 事务消息将在 Broker 配置文件中的参数 transactionMsgTimeout 这样的特定时间长度之后被检查。当发送事务消息时，用户还可以通过设置用户属性 CHECK_IMMUNITY_TIME_IN_SECONDS 来改变这个限制，该参数优先于 `transactionMsgTimeout` 参数。

4. 事务性消息可能不止一次被检查或消费。

5. 提交给用户的目标主题消息可能会失败，目前这依日志的记录而定。它的高可用性通过 RocketMQ 本身的高可用性机制来保证，如果希望确保事务消息不丢失、并且事务完整性得到保证，建议使用同步的双重写入机制。

6. 事务消息的生产者 ID 不能与其他类型消息的生产者 ID 共享。与其他类型的消息不同，事务消息允许反向查询、MQ服务器能通过它们的生产者 ID 查询到消费者。

第二节：使用场景

========

同步消息解决的问题是：消息一定投递成功（Broker 响应Send_OK状态码时才代表消息发送成功）

事务消息解决的问题是：本地事务+消息投递一起做

例子：李四要给张三转钱1万元。

同步消息

1、 银行发一个同步消息给MQ，给张三加钱1万元

2、MQ ack反馈发送成功了

3、银行给李四扣1万元

可能的问题，ack Send_OK之后，系统抛出异常，没有给李四扣钱，但是消息已经发送出去了，张三加钱成功了。

事务消息

1、银行发一个事务消息给MQ，给张三加钱1万元

2、Broker precommit成功，回调excuteCommit，真正执行李四扣款1万元

3、扣款成功ACK Commit给MQ

4、MQ收到Commit ACK时，commit消息，系统可以消费这个消息

如果系统扣款异常，则消息虽然prepareCommit在MQ中，但是对系统不可见。另外如果ACK网络丢失或者延时，MQ