1.RocketMq支持事务操作,其他mq和kafka不支持事务操作。
运行流程:第一阶段 Prepared 消息,会拿到消息的地址。 第二阶段执行本地事务,第三阶段通过第一阶段拿到的地址去访问消息,并修改状态。
原理以及例子:
1、A系统向消息中间件发送一条预备消息
2、消息中间件保存预备消息并返回成功
3
、
A
执行本地事务
4
、
A
发送提交消息给消息中间件
对于以上的
4
个步骤,每个步骤都可能产生错误,下面一一分析:
步骤一出错,则整个事务失败,不会执行
A
的本地操作
步骤二出错,则整个事务失败,不会执行
A
的本地操作
步骤三出错,这时候需要回滚预备消息,怎么回滚?答案是
A
系统实现一个消息中间件的回调接口,消 息中间件会去不断执行回调接口,检查A
事务执行是否执行成功,如果失败则回滚预备消息
步骤四出错,这时候
A
的本地事务是成功的,那么消息中间件要回滚
A
吗?答案是不需要,其实通过回调 接口,消息中间件能够检查到A
执行成功了,这时候其实不需要
A
发提交消息了,消息中间件可以自己对消息进行提交,从而完成整个消息事务。
基于消息中间件的两阶段提交往往用在高并发场景下,将一个分布式事务拆成一个消息事务(
A
系统的 本地操作+
发消息)
+B
系统的本地操作,其中
B
系统的操作由消息驱动,只要消息事务成功,那么
A
操作 一定成功,消息也一定发出来了,这时候B
会收到消息去执行本地操作,如果本地操作失败,消息会重 投,直到B
操作成功,这样就变相地实现了
A
与
B
的分布式事务。
优点:
实现了最终一致性,不需要依赖本地数据库事务。
缺点:
实现难度大,主流
MQ
不支持,没有
.NET
客户端,
RocketMQ
事务消息部分代码也未开源。