Seata AT模式

前言

我们在之前所介绍的一些分布式事务的理论,是需要通过具体的框架工程化的,这样才能在我们日常工作中使用。

常见的开源分布式事务框架很多,比如: Seata、EasyTransaction等等。我们在这篇文章将会介绍阿里开源的分布式事务框架Seata。

Seata这个分布式事务框架支持有多种模式,如: AT、TCC、SAGA、XA。除了AT,后面三种分布式事务模式的大致流程,我们在之前的文章中有介绍过。

Seata的模块组成

1)TM:事务发起者。定义事务的边界,负责告知 TC,分布式事务的开始,提交,回滚。

2)RM:资源管理者。管理每个分支事务的资源,每一个 RM 都会作为一个分支事务注册在 TC。

3)TC :事务协调者。负责我们的事务ID的生成,事务注册、提交、回滚等。

在Seata的AT模式中,TM和RM都作为SDK的一部分和业务服务在一起,我们可以认为是Client。TC是一个独立的服务,通过服务的注册、发现将自己暴露给Client们。

工作流程

我们用一个比较简单的业务场景来描述一下Seata AT模式的工作过程。

有个充值业务,现在有两个服务,一个负责管理用户的余额,另外一个负责管理用户的积分。

当用户充值的时候,首先增加用户账户上的余额,然后增加用户的积分。

AT流程分为两阶段,主要逻辑全部在第一阶段,第二阶段主要做回滚或日志清理的工作。其中,第一阶段流程如下:

Seata AT模式

积分服务中也有TM,但是由于没有用到,因此直接可以忽略。

1)余额服务中的TM,向TC申请开启一个全局事务,TC会返回一个全局的事务ID。

2)余额服务在执行本地业务之前,RM会先向TC注册分支事务。

3)余额服务依次生成undo log、执行本地事务、生成redo log,最后直接提交本地事务。

4)余额服务的RM向TC汇报,事务状态是成功的。

5)余额服务发起远程调用,把事务ID传给积分服务。

6)积分服务在执行本地业务之前,也会先向TC注册分支事务。

7)积分服务次生成undo log、执行本地事务、生成redo log,最后直接提交本地事务。

8)积分服务的RM向TC汇报,事务状态是成功的。

9)积分服务返回远程调用成功给余额服务。

10)余额服务的TM向TC申请全局事务的提交/回滚。

我们如果使用Spring框架的注解式事务,远程调用会在本地事务提交之前发生。先发起远程调用还是先提交本地事务,这个其实没有任何影响。

第二阶段的逻辑就比较简单了。Client和TC之间是有长连接的,如果是正常全局提交,则TC通知多个RM异步清理掉本地的redo和undo log即可。如果是回滚,则TC通知每个RM回滚数据即可。

这里就会引出一个问题,由于本地事务都是自己直接提交了,后面如何回滚,由于我们在操作本地业务操作的前后,做记录了undo和redo log,因此可以通过undo log进行回滚。

由于undo和redo log和业务操作在同一个事务中,因此肯定会同时成功或同时失败。

但是还会存在一个问题,因为每个事务从本地提交到通知回滚这段时间里,可能这条数据已经被别的事务修改,如果直接用undo log回滚,会导致数据不一致的情况。

此时,RM会用redo log进行校验,对比数据是否一样,从而得知数据是否有别的事务修改过。注意:undo log是被修改前的数据,可以用于回滚;redo log是被修改后的数据,用于回滚校验。

如果数据未被其他事务修改过,则可以直接回滚;如果是脏数据,再根据不同策略处理。

Seata的数据隔离性

从前面的工作流程,我们可以很容易知道,Seata的写隔离级别是全局独占的。

因为事务开启之前,TM会在TC中获取全局锁。锁的的key会以行数据的维度来确定,即同一个数据库中的某个表中的某行数据,在同一时间只会被一个事务操作。

但是会容易出现等待锁的场景:A获取到TC全局锁,操作了数据D并提交了,此时A释放了DB行锁,但是未释放TC全局锁。与此同时,B获取到了D的行锁,A需要做回滚。A会一直等待B释放行锁,回滚了数据后,才释放TC全局锁。

读的隔离级别是Read Uncommitted,因为每个服务的本地事务是单独提交的,因此在全局事务未提交之前,是可以读取到部分数据的。

如果应用一定要达到Read Committed级别,可以使用SELECT FOR UPDATE 语句。对于这种语句,Seata会通过SELECT FOR UPDATE 持有数据的行锁,直到全局锁是已提交的,才返回。

我们也可以得知,Seata默认Read Uncommitted级别是出于性能的考虑。

总结

对比起TCC等其他事务模型,Seata的AT模式可以应对大多数的业务场景,并且基本可以做到无业务入侵、开发者无感知。

整个事务的协调、提交或回滚操作,都可以通过AOP完成,开发者只需要关注业务即可。

由于Seata需要在不同的服务之间传递全局唯一的事务ID,和Dubbo等框架集成会很友好,例如Dubbo可以通过隐式传参来做事务ID的传递,整个事务ID的传播过程对开发者也能做到无感.

 

上一篇:【剑指offer】12 矩阵中的路径


下一篇:TC的连接释放—四次挥手