![8eabd0f754fba18b334e38e9adb81741.png](https://i-blog.csdnimg.cn/blog_migrate/b83cdbd9f4abed4685289e7dbcc5a94f.jpeg)
1、RocketMQ 的事务消息流程
![7295ff0902231d88834d0b7506e08a4e.png](https://i-blog.csdnimg.cn/blog_migrate/b81ad3745cad514e4efe9f0a57e32611.jpeg)
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 配置类:
![2b5f59978eee257f5734bf63f34ea9ef.png](https://i-blog.csdnimg.cn/blog_migrate/251fec45e916fa84028de86eee06b6aa.jpeg)
MQTransactionProducerConfiguration
controller 发送消息
![bb04485cb98ec74665877f94cc07479e.png](https://i-blog.csdnimg.cn/blog_migrate/9227071ef0ed6bf0ec4ccdab51271532.jpeg)
5、consumer 接收消息
当发送半消息成功时,我们使用 executeLocalTransaction 方法来执行本地事务。它返回前一节中提到的三个事务状态之一。checkLocalTransaction 方法用于检查本地事务状态,并回应消息队列的检查请求。它也是返回前一节中提到的三个事务状态之一。
![9ed1c17cafd9c6d8a479959bee0f412a.png](https://i-blog.csdnimg.cn/blog_migrate/dd2968747f2f61c0f91da2cb46eee5bf.jpeg)
实现事务的监听接口
MQConsumerConfiguration 配置类,传入 TransactionListenerHandler
![57392caa31fb41a48c9ef8a223f1ce50.png](https://i-blog.csdnimg.cn/blog_migrate/50814dfc6a8738ff8e7506d82fb94e79.jpeg)
只有状态最后是 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 大星 | 文
![67e1cd40d3ef9b9149da782e915df045.png](https://i-blog.csdnimg.cn/blog_migrate/e0885bdefa85404b2c5d833d7205101a.jpeg)