事务失败返回_不明觉厉：RocketMQ 的事务消息

1、RocketMQ 的事务消息流程

2 、事务消息分 2 个阶段：

① 正常事务消息的发送与提交：

a.发送消息(half 消息)

b.服务响应消息写入结果

c.根据发送结果执行本地事务(如果写入失败，此时half消息对业务不可见，本地逻辑不执行)

d.根据本地事务状态执行 Commit 或者 Rollback ( Commit操作生成消息索引，消息对消费者可见)

② 事务消息的补偿流程(补偿阶段用于解决消息 Commit 或者 Rollback 发生超时或者失败的情况)

a.对没有 Commit / Rolback 的事务消息( pending 状态的消息)，从服务端发起-一次"回查"

b. Producer 收到回查消息，检查回查消息对应的本地事务的状态

c.根据本地事务状态，重新 Commit 或者 Rollback

3、事务的消息状态

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

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

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

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

4、producer 发送消息

MQTransactionProducerConfiguration 配置类：

MQTransactionProducerConfiguration

controller 发送消息

5、consumer 接收消息

当发送半消息成功时，我们使用 executeLocalTransaction 方法来执行本地事务。它返回前一节中提到的三个事务状态之一。checkLocalTransaction 方法用于检查本地事务状态，并回应消息队列的检查请求。它也是返回前一节中提到的三个事务状态之一。

实现事务的监听接口

MQConsumerConfiguration 配置类，传入 TransactionListenerHandler

只有状态最后是 LocalTransactionState.COMMIT_MESSAGE 的消息才能被消费者接收。

6、RocketMQ 事务消息上的限制

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

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

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

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

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

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

---

欢迎关注 @Python 大星 ，一个会点 Python 的 Java 程序员。如果你有更好的想法，欢迎留言，一起探讨，想说你就说啊！后面继续分享 Java 的相关开发，人少就散了吧！@Python 大星

@Python 大星 | 文