原创 :江南一点雨
分布式事务,咱们前边也聊过很多次了,网上其实也有不少文章在介绍分布式事务,不过里边都会涉及到不少专业名词,看的大家云里雾里,所以还是有一些小伙伴在微信上问我。
那么今天,我就再来一篇文章,和大家捋一捋这个话题。以下的内容主要围绕阿里的 seata 来和大家解释。
1. 什么是反向补偿
首先,来和大家解释一个名词,大家在看分布式事务相关资料的时候,经常会看到一个名词:反向补偿。啥是反向补偿呢?
我举一个例子:假设我们现在有三个微服务分别是 A、B、C,现在在 A 服务中分别调用 B 和 C 服务,为了确保 B 和 C 同时成功或者同时失败,我们需要使用到分布式事务。但是按照我们之前对本地事务的理解,B 和 C 中的本地事务,当 B 服务中的事务执行完毕并且提交之后,现在 C 服务中的事务出现异常需要回滚了,但是,B 已经提交了还怎么回滚呀?
此时我们所说的回滚其实并不是传统意义上的,通过 MySQL redo log 日志来回滚的那种,而是通过一条更新 SQL,再把 B 服务中已经更改过的数据复原。
这就是我们所说的反向补偿!
2. 基本概念梳理
Seata 中有三个核心概念:
-
TC (Transaction Coordinator) - 事务协调者:维护全局和分支事务的状态,驱动全局事务提交或回滚。
-
TM (Transaction Manager) - 事务管理器:定义全局事务的范围,开始全局事务、提交或回滚全局事务。
-
RM ( Resource Manager ) - 资源管理器:管理分支事务处理的资源( Resource ),与 TC 交谈以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚。
其中,TC 为单独部署的 Server 服务端,TM 和 RM 为嵌入到应用中的 Client 客户端。我们来看如下一张图片:
这张图基本上把这个三个概念解释清楚了。
其实不看这张图,我们大概也能猜到分布式事务的实现原理:首先得有一个全局的事务协调者(TC),各个本地事务(RM)在开始执行的时候,或者在执行的过程中,及时将自己的状态报告给全局事务协调者,这个全局事务协调者知道每一个分支事务目前的执行状态,当他(TC)发现所有的本地事务都执行成功的时候,就通知大家一起提交;当他发现在本次事务中,有人执行失败的时候,就通知大家一起回滚(当然这个回滚不一定是真的回滚,而是反向补偿)。那么一个事务什么时候开始什么时候结束呢?也就是事务的边界在哪里?seata 中的分布式事务都是通过 @GlobalTransactional
注解来实现的,换句话说,这个注解该加在哪里?添加该注解的地方其实就是事务管理器 TM 了。
经过上面的介绍