Seata 是阿里开源的基于Java的分布式事务解决方案
Seata 提供四种模式解决分布式事务场景,AT,XA,TCC,Saga。简单叨咕叨咕我对这几种模式的理解
这是Seata的一大特色,AT对业务代码完全无侵入性,使用非常简单,改造成本低。我们只需要关注自己的业务SQL,Seata会通过分析我们业务SQL,反向生成回滚数据
AT 包含两个阶段
也是我们常说的二阶段提交,XA要求数据库本身提供对规范和协议的支持。XA用起来的话,也是对业务代码无侵入性的。
上述其他三种模式,都是属于补偿型,无法保证全局一致性。啥意思呢,例如刚刚说的AT模式,我们是可能读到这一次分布式事务的中间状态,而XA模式不会。
补偿型 事务处理机制构建在 事务资源(数据库) 之上(要么在中间件层面,要么在应用层面),事务资源 本身对分布式事务是无感知的,这也就导致了补偿型事务无法做到真正的 全局一致性 。比如,一条库存记录,处在 补偿型 事务处理过程中,由 100 扣减为 50。此时,仓库管理员连接数据库,查询统计库存,就看到当前的 50。之后,事务因为意外回滚,库存会被补偿回滚为 100。显然,仓库管理员查询统计到的 50 就是 脏 数据。如果是XA的话,中间态数据库存 50 由数据库本身保证,不会被仓库管理员读到(当然隔离级别需要 读已提交 以上)
但是全局一致性带来的结果就是数据的锁定(AT模式也是存在全局锁的,但是隔离级别无法保证,后边我们会详细说),例如全局事务中有一条update语句,其他事务想要更新同一条数据的话,只能等待全局事务结束
传统XA模式是存在一些问题的,Seata也是做了相关的优化,更多关于Seata XA的内容,传送门?http://seata.io/zh-cn/blog/seata-xa-introduce.html
TCC 模式同样包含两个阶段
对比AT或者XA模式来说,TCC模式需要我们自己抽象并实现Try,Confirm,Cancel三个接口,编码量会大一些,但是由于事务的每一个阶段都由开发人员自行实现。而且相较于AT模式来说,减少了SQL解析的过程,也没有全局锁的限制,所以TCC模式的性能是优于AT 、XA模式。PS:果然简单和高效难以两全的
Saga 是长事务解决方案,每个参与者需要实现事务的正向操作和补偿操作。当参与者正向操作执行失败时,回滚本地事务的同时,会调用上一阶段的补偿操作,在业务失败时最终会使事务回到初始状态
Saga与TCC类似,同样没有全局锁。由于相比缺少锁定资源这一步,在某些适合的场景,Saga要比TCC实现起来更简单。由于Saga和TCC都需要我们手动编码实现,所以在开发时我们需要参考一些设计上的规范,由于不是本文重点,这里就不多说了,可以参考分布式事务 Seata 及其三种模式详解
在我们了解完四种分布式事务的原理之后,我们回到本文重点AT模式
模拟需求:以下订单为例,在分布式的电商场景中,订单服务和库存服务可能是两个数据库
我们先来看看AT模式下的代码是什么样的,这里忽略了Seata的相关配置,只看业务部分
image.png在需要开启分布式事务的方法上标记@GlobalTransactional,然后执行分别执行扣减库存和扣减库存操作的,事务的参与者可以是本地的数据源,或者RPC的远程调用(远程调用的话需要携带全局事务ID,也就是上图的xid)
之前说过AT模式分为两个阶段,第一阶段包括提交业务数据和回滚日志(undoLog),第一阶段具体流程如下图
image.png标记@GlobalTransactional
的方法通过AOP实现了,开启全局事务和提交全局事务两个操作,与Spring 事务机制类似,当 GlobalTransactionalInterceptor 在事务执行过程中捕获到Throwable时,会发起全局事务回滚
0.1 步骤中会生成一个全局事务ID
0.2 所有事务参与者执行结束后,一阶段事务提交
我们先来看看 Seata undoLog 的结构
// 省略了相关方法
public class SQLUndoLog {
// insert, update ...
private SQLType sqlType;
private String tableName;
private TableRecords beforeImage;
private TableRecords afterImage;
}
Seata 在执行业务SQL前后,会生成beforeImage和afterImage,在需要回滚时,根据SQLType,决定具体的回滚策略,例如SQLType=update时,将数据回滚到beforeImage的状态,如果SQLType=insert,则根据afterImage删除数据
如2.4所示,每条业务SQL,执行成功后,会为这条SQL生成LockKey,格式为tableName:PrimaryKey
在3.1步骤注册分支事务时,client会把所有的LockKey 拼到一起作为全局锁发送给Seata-server。如果注册成功,写入undoLog,并提交本地事务,一阶段结束,等待二阶段反馈
如果当前有其他分支事务已经持有了相同的锁(即其他事务也在处理相同表的同一行),则client 注册事务分支失败。client会根据客户端定义的重发时间和重发次数进行不断的尝试,如果重试结束仍然没有获得锁,则一阶段失败,本地事务回滚。如果该全局事务存在已经注册成功分支事务,Seata-server 进行二阶段回滚
全局锁会在分支事务二阶段结束后释放
Seata 全局锁的设计是为了什么?以扣减库存场景为例,TX1 完成库存扣减的一阶段,库存从100扣减为99,正在等待二阶段的通知。TX2也要扣减同一商品的库存,如果没有全局锁的限制,TX2库存从99扣减为98,这时如果TX1接收到回滚通知,进行回滚把库存从98回滚到100。因为没有全局锁,造成了脏写
二阶段是完全异步化的并且完全由Seata控制,Seata根据所有事务参与者的提交情况决定二阶段如何处理
至此我们已经初步了解了Seata的AT模式是如何实现的了
如果你也和我一样,仔细思考了上述过程,可能会提出一些问题,这边我列举一下我在学习Seata时,遇到的问题,以及我得出的结论
问题1. Seata如何做到无侵入的分析业务SQL生成undoLog,注册事务分支等操作?
Seata 代理了DataSource,我们可以通过在代码注入一个DataSource来验证我的说法,目前的DataSource 是 io.seata.rm.datasource.DataSourceProxy
所有的Java持久化框架,最终在操作数据库时都会通过DataSource接口获取Connection,通过Connection 实现对数据库的增删改查,事务控制。
image.pngSeata 通过代理Connection的方式,做到了无侵入的生成undoLog,注册事务分支,具体源码可以查看io.seata.rm.datasource.ConnectionProxy
问题2. ConnectionProxy 如何判断当前事务是全局事务,还是本地事务?
通过当前线程是否绑定了全局事务id,在进行全局事务之前,需要调用RootContext.bind(xid);
问题3. 全局事务并发更新
还是以下订单扣减库存的场景为例,如果TX1和TX2同时扣减product_id为1的库存,这时Seata会不会生成相同的beforeImage?
举个例子,TX1读库存为100,TX1扣减库存1,此时BeforeImage为100 紧接着 如果TX2读库存也为100,那么就有问题了,不管TX2扣减多少库存,如果TX1回滚那么相当于覆盖了TX2扣减的库存,出现了脏写
Seata是如何解决这个问题的?
源码位置:io.seata.rm.datasource.exec.AbstractDMLBaseExecutor::executeAutoCommitFalse
可以看到这里的逻辑和我上面画的图一致,证明我没有瞎说 ?
我们来看一下beforeImage()
,这是一个抽象方法,看一下他的子类UpdateExecutor
是如何实现的
通过Debug,可以看出Seata这边也是确实考虑了这个问题,直接简单而有效的解决了这个问题
回到我们的例子,由于SELECT FOR UPDATE
的存在,TX2如果也想读同一条数据的话,只能等到TX1 提交事务后,才能读到。所以问题解决
问题4. 全局事务外的更新
我们现在可以确认在Seata的保证下,全局事务,不会造成数据的脏写,但是全局事务外会!
什么意思呢?
还以库存为例
Seata 针对这个问题,提供了@GlobalLock
注解,标记该注解时,会像全局事务一样进行SQL分析,竞争全局锁,就不会出现上述问题了
关于这个问题可以参考Seata的FAQ文档 http://seata.io/zh-cn/docs/overview/faq.html
问题5. @GlobalTransactional 和 @Transactional 同时使用会怎么样
我们上文中已经说过了 @GlobalTransactional 的作用了,他是负责开启全局事务/提交事务1阶段,说白了@GlobalTransactional 只和Seata-server 交互,而 @Transactional 管理的是本地数据库的事务,所以二者不发生冲突。
但是需要注意 @GlobalTransactional AOP 覆盖范围一定要大于 @Transactional
问题6. 如果其中某一个事务分支超时未提交,会发生什么
这个我并没有看源码,而是通过跑demo,验证的
例如现在有A,B两个事务分支
Seata的全局事务超时时间,默认是1分钟,Seata-server 在检测到有超时的全局事务时,会向所有已提交的分支,发起回滚。而超时提交的事务,向Seata-server发起分支注册时,响应结果为事务已超时,或者事务不存在,也会回滚本地事务
问题7. Seata-client 如何接收Seata-server发起的通知
Seata-client 包含了Netty服务,在启动时Netty会监听端口,并向Seata-server 发起注册。server中存储了client 的调用地址。
我们学习了Seata的AT模式是如何工作的,可以看出Seata模式在开发上是非常简单的,但是Seata的背后为了维持分布式事务的数据一致性,做了大量的工作,AT模式非常适合现有的业务模型直接迁移。
但是他的缺点也很明显,性能并不是那么的优秀。例如我们刚刚看到的全局锁的问题,为了数据不会发生脏写,Seata牺牲了业务的并发能力。在非常要求性能的场景,可能还是需要考虑TCC,SAGA,可靠消息等方案
在使用Seata开发前,建议大家先去阅读一下FAQ文档,避免踩坑 https://seata.io/zh-cn/docs/overview/faq.html
https://github.com/TavenYin/taven-springboot-learning/tree/master/springboot-seata