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模式的要求。