Seata是一款开源的分布式事务解决方案,致力于提供高性能和简单易用的分布式事务服务。Seata将为用户提供了AT、TCC、SAGA和XA事务模式,为用户打造一站式的分布式解决方案。
一.Seate的三大角色
在 Seata 的架构中,一共有三个角色:
1.TC(Transaction Coordinator)事务协调者或回滚:维护全局和分支事务的状态,驱动全局事务提交;(它的作用是代表是中间人,seate是用来处理分布式事务的,也就代表它会存在多个分支事务,多个分支事务需要统一处理,就需要一个中间者来进行协调)
2.TM(Transaction Manager)事务管理器:定义全局事务的范围,开始全局事务、提交或回衮全同事务;(如果要调用某个微服务的方法,当调用微服务的时候,就会开启全局事务,那么在它的结尾就会结束全局事务,这整个过程就代表是全局事务)
3.RM(Resource Manager)资源管理器:管理分支事务处理的资源,与TC交谈以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚。(在全局事务中,会调用许多其他微服务,它们都有自己的本地事务,这些就被叫做分支事务,命令为RM,当分支事务处理完以后就会把状态汇报给TC)
其中,TC 为单独部署的 Server 服务端,TM 和RM 为嵌入到应用中的 Client 客户端。
二.XA模型
XA 模型是指基于 XA 分布式事务协议 的分布式事务管理方式。
XA 是一种标准的分布式事务协议,定义了如何在多个资源(如数据库)之间协调事务的提交和回滚,确保跨数据库的事务一致性。
流程如下:
首先,当调用某个方法后,就会触发TM开启全局事务,然后会汇报给TC,TC会给它返回一个事务ID,这个事务ID在开启分支的时候会用到,当触发了分支事务的时候,就会先往TC里面注册分支事务,并且会代码事务ID,代表当前的分支事务是属于该全局事务的,其他微服务也会同样操作,也就代表当前事务下有哪些分支事务,TC是可以知道的,然后会执行业务sql,此时该sql不会立马提交,而是会将这部分的数据库的资源进行锁定,执行完成后,就会汇报自己的事务状态给TC(处理正常还是异常),当所有微服务都汇报给TC以后,整个全局事务就已经处理完成了,那么就会结束全局事务,触发TC的检查,当TC检查所有事务状态的时候,如果所有状态都是正常,就会通知所有事务进行提交,但凡有一个状态不正常,就会通知所有事务进行回滚,此时每个微服务所对应的数据库资源才会进行释放,也就是二阶段的所有事务完成后,才会释放数据库资源。
优缺点:
优点:
1.事务的强一致性,满足ACID原则;
2.常用数据库都支持,实现简单,并且没有代码侵入。
缺点:
1.性能较差因为一阶段需要锁定数据库资源等待二阶段结束才释放;
2.依赖 关系型数据库 实现事务。
三.AT模型
前面流程和XA模型一样,不同点在于执行sql以后它会立即提交,只是在提交前会进行一个备份,将当前的快照存储在undo_log里面,这个undo_log不是mysql中的日志,而是seate中创建的一个表,后续的流程也和XA模型一样,不同点在于如果TC发送提交事务的操作,就会去删除undo_log表对应的快照,如果分支收到回滚操作,就会去读取之前的快照开进行回滚数据,这就是AT模型的处理过程。
AT相对于XA模型最大的区别是,它的sql执行是立即提交的,它会等到TC下达提交或者回滚的时候才会释放这个资源,因此AT模型相对于XA模型,它处理的性能是相对较高的。
但是AT有一个问题:如果sql提交后,当前全局事务处理事件较长,其他全局事务也来进行处理的时候,就可能拿到一个脏数据,如下:
解决:
可以通过引入全局锁,来判断DB的资源是否被释放,只有被释放的DB资源其他全局锁才能进行资源的获取,这样就可以解决AT模式下的脏读问题,如下:
四.总结
TCC和SAGE这么就不做降级了,《彻底理解分布式事务的各种解决方案》对这两种做了详细解释,需要了解的可以查看一下。
XA | AT | TCC | SAGA | |
一致性 | 强一致 | 弱一致 | 弱一致 | 最终一致 |
隔离性 | 完全隔离 | 基于全局锁隔离 | 基于资源预留隔离 | 无隔离 |
代码侵入 | 无 | 无 | 有,需要编写三个接口 | 有,需要编写状态机和补偿业务 |
性能 | 差 | 好 | 非常好 | 非常好 |
场景 | 对一致性、隔离性有高要求的业务 | 基于关系型数据库的大多数分布式场景都可以 | 1.对事务要求较高的事务; 2.有非关系型数据库要产于的事务。 | 1.业务流程长、业务流程多; 2.参与者包含其他公司或遗留系统服务,无法提供TCC模式的要求。 |