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