Seata 目前支持四种事务模式，分别是 AT、TCC、Saga 以及 XA 模式
-
AT 模式: 通过代理数据库操作来实现分布式事务管理。Seata 在业务操作前后自动生成回滚日志，在提交时直接提交本地事务，在回滚时利用日志进行数据的还原。
-
TCC 模式: 是一种两阶段提交。将一个操作拆分为三个步骤: Try(预留资源)、Confirm(确认操作)、Cancel(回滚操作)。开发者需要自己实现每个步骤的逻辑。
-
Saga 模式: 是一种长事务模式，它将全局事务拆解为多个有序的小事务，每个事务都有对应的补偿操作。若某个事务失败，按照相反的顺序依次调用补偿操作
-
XA 模式: 是基于两阶段提交协议(2PC)的标准化分布式事务管理模式。通过协调多个资源管理器的事务提交和回滚来实现全局事务的管理
扩展
AT模式
AT模式采用了一种称为全局锁（Global Lock）的机制来实现事务的隔离性。这个全局锁并不是传统意义上的分布式锁，而是一种更贴近业务数据的逻辑锁。特点是乐观锁和悲观锁
AT 模式是一种无侵入的分布式事务解决方案。在 AT 模式下，用户只需关注自己的"业务 SQL"，用户的 "业务 SQL" 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作
通过全局事务xid进行管控，自己的分支事务branchId进行协调 ，模式采用branchType=AT
-
一阶段
-
业务数据和回滚日志在同一个本地事务中提交，释放本地锁和连接资源
-
在一阶段，Seata 会拦截"业务 SQL"，
-
解析 SQL 语义，找到"业务 SQL"要更新的业务数据，在业务数据被更新前，将其保存成"before image"，即原始数据
-
执行"业务 SQL"更新业务数据，在业务数据更新之后
-
其保存成"after image"，即修改数据库后的数据，最后生成行锁。
以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。
-
-
二阶段
-
正常提交：
-
因为数据库操作没有异常，无需回滚
-
"业务 SQL"在一阶段已经提交至数据库，所以Seata框架只需将一阶段保存的undo_log快照数据和行锁删掉，完成数据清理即可
-
异常情况 需回滚
-
回滚方式是用"before image"还原业务数据
-
还原前要首先要校验脏写，对比"数据库当前业务数据"和 "after image"，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理
-
脏写（Dirty Write）是数据库并发控制中的一个术语，指的是当一个事务（我们可以称之为事务A）覆写了另一个并发事务（称之为事务B）尚未提交的数据时发生的情况。
TCC 模式
将业务操作拆分为三个步骤: Try(预留资源)、Confirm(确认操作)、Cancel(回滚操作)。每个步骤都由业务开发者手动实现，Seata 负责协调这些步骤的执行和回滚，适合对资源控制要求高的场景。
有时候一些业务它不仅仅涉及到数据库，可能是发送一条短信，也可能是上传一张图片，所以说事务的提交和回滚就得提升到业务层面而不是数据库层面了，而 TCC 就是一种业务层面或者是应用层的两阶段提交。
比如有一个扣款服务，我需要写 Try 方法，用来冻结扣款资金，还需要一个 Confirm 方法来执行真正的扣款，最后还需要提供 Cancel 来进行冻结操作的回滚，对应的一个事务的所有服务都需要提供这三个方法。 可以看到本来就一个方法，现在需要膨胀成三个方法，所以说 TCC 对业务有很大的侵入像如果没有冻结的那个字段，还需要改表结构。 我们来看下流程。
Saga 模式
Saga 模式是 SEATA 提供的长事务解决方案，在 Saga 模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。
XA模式
基于两阶段提交协议(2PC)，能够保证全局事务的强一致性。TC 作为协调者管理各个参与者的提交和回滚操作，但这种模式性能较低，适合对一致性要求严格的场景。
执行阶段:
-
可回滚: 业务 SQL 操作放在 XA 分支中进行，由资源对 XA 协议的支持来保证 可回滚
-
持久化: XA分支完成后，执行 XA prepare，同样，由资源对 XA 协议的支持来保证 持久化( 即，之后任何意外都不会造成无法回滚的情况)
完成阶段:
-
分支提交: 执行 XA 分支的 commit
-
分支回滚: 执行 XA 分支的 rollback