可靠消息服务事务(RocketMQ的分布式事务解决方案)

Mr_zly

已于 2024-01-17 09:27:34 修改

阅读量1.6k

点赞数 31

分类专栏：分布式事务 rocketmq 文章标签： rocketmq 分布式

于 2024-01-16 23:29:15 首次发布

本文链接：https://blog.csdn.net/Mr_zly/article/details/135638122

版权

本文介绍了RocketMQ的分布式事务解决方案，通过半消息机制确保最终一致性。详细阐述了事务消息的工作机制，包括生产者如何发送半消息、执行本地事务并提交二次确认，以及消费者如何处理消息。此外，提供了生产者和消费者的使用示例，以及解决依赖包冲突的方法。文中还讨论了RocketMQ事务消息的优缺点和适用场景。

摘要由CSDN通过智能技术生成

系统环境

Java: openjdk version“1.8.0_382”
rocketmq-all-5.1.4

整体机制

使用rocketmq的事务消息，分两个阶段保证分布式事务的最终一致性；

一阶段：消息生产者（分布式事务发起方）发送半消息（消费者不接收半消息），之后完成本地事务的执行，根据执行结果选择将半消息投递给消费者或撤回半消息；
二阶段：消息消费者（分布式事务的分支应用）接收到半消息后，完成分支事务的执行，该模式下分支事务要求最终一致，不支持回滚。
#工作机制
事务消息交互流程如下图所示：

生产者将消息发送至Apache RocketMQ服务端。
Apache RocketMQ服务端将消息持久化成功之后，向生产者返回Ack确认消息已经发送成功，此时消息被标记为"暂不能投递"，这种状态下的消息即为半事务消息。
生产者开始执行本地事务逻辑。
生产者根据本地事务执行结果向服务端提交二次确认结果（Commit或是Rollback），服务端收到确认结果后处理逻辑如下：
- 二次确认结果为Commit：服务端将半事务消息标记为可投递，并投递给消费者。
- 二次确认结果为Rollback：服务端将回滚事务，不会将半事务消息投递给消费者。
在断网或者是生产者应用重启的特殊情况下，若服务端未收到发送者提交的二次确认结果，或服务端收到的二次确认结果为Unknown未知状态，经过固定时间后，服务端将对消息生产者即生产者集群中任一生产者实例发起消息回查。
生产者收到消息回查后，需要检查对应消息的本地事务执行的最终结果。
生产者根据检查到的本地事务的最终状态再次提交二次确认，服务端仍按照步骤4对半事务消息进行处理。

使用示例

生产者

添加依赖rocketMQ依赖

implementation 'org.apache.rocketmq:rocketmq-spring-boot-starter:2.2.3'

添加配置

application.yml中添加如下配置：rocketmq.name-server为rocketMQ的NameServer注册服务

rocketmq:
#调整为NameServer注册服务
  name-server: 127.0.0.1:9876
  producer:
#生产者分组，非必填，集群使用
    group-name: tradeTxProducer

Spr

最低0.47元/天解锁文章