Reference
[1] https://www.sofastack.tech/blog/seata-distributed-transaction-deep-dive/
分布式事务有 AT、TCC、Saga 和 XA 四种模式。
AT
AT是一种业务无侵入的模式, AT框架自动解析sql, 找到对应的库去执行分布式事务.
在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，框架会自动生成事务的二阶段提交和回滚操作。AT模式需要全局锁来保证同一个库下的主键同时只有一个全局分布式事务.
TCC
TCC: Try, Confirm, Cancel需要业务层面支持第一阶段Try和第二阶段的Confirm, Cancel.
用户接入 TCC 模式，最重要的事情就是考虑如何将业务模型拆成 2 阶段，实现成 TCC 的 3 个方法，并且保证 Try 成功 Confirm 一定能成功。相对于 AT 模式，TCC 模式对业务代码有一定的侵入性，但是 TCC 模式无 AT 模式的全局行锁，TCC 性能会比 AT 模式高很多。
SAGA
Saga 模式是 Seata 即将开源的长事务解决方案，将由蚂蚁金服主要贡献。在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作.
分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。
Saga模式最重要的是业务要自主定义长事务的每个流程编排和对应的回滚流程.
Saga 模式下分布式事务通常是由事件驱动的，各个参与者之间是异步执行的，Saga 模式是一种长事务解决方案。
XA
XA 模式是 Seata 将会开源的另一种无侵入的分布式事务解决方案，任何实现了 XA 协议的数据库都可以作为资源参与到分布式事务中，目前主流数据库，例如 MySql、Oracle、DB2、Oceanbase 等均支持 XA 协议。
XA 模式下，用户只需关注“业务 SQL”，Seata 会自动生成一阶段、二阶段提交和二阶段回滚操作。XA 模式和 AT 模式一样是一种对业务无侵入性的解决方案；但与 AT 模式不同的是，XA 模式将快照数据和行锁等通过 XA 指令委托给了数据库来完成，这样 XA 模式实现更加轻量化。
分布式事务优化点
1. 同库模式
通常，一个 TM 会产生一笔主事务日志，一个 RM 会产生一条分支事务日志，每个分布式事务由一个 TM 和若干 RM 组成，一个分布式事务总共会有 1+N 条事务日志（N 为 RM 个数）。
在默认情况下，分布式事务执行过程中客户端将事务日志发送给服务端，服务端再将事务日志存储至数据库中，一条事务日志的存储链路会有 2 次 TCP ，分别是“客户端到服务端”和“服务端到数据库”， 我们称这种模式为异库模式。
在异库模式下，分布式事务存储事务日志总共需要 2*（1+N） 次左右的 TCP 通信。在 RM 数量较少的业务场景下，分布式事务性能还能接收，但有些业务场景下 RM 数量较多，此时事务内 TCP 数量也会增多，分布式事务性能急剧下降。
在事务执行过程中，客户端和服务端进行通信的目的是为了存储事务日志。如果客户端在存储事务日志时，绕过服务端直接将事务日志写入数据库（如上图“同库模式”所示），那么一笔事务日志的存储链路就由原来的 2 次 TCP 变成只需访问一次数据库便可，每条事务日志的存储减少了一次 TCP 通信，整个分布式事务就减少了 N+2 次 TCP 请求，分布式事务的性能大幅提升。我们将客户端直接将事务日志存储至数据库的模式称为同库模式。
2. 二阶段异步执行
通常情况下，分布式事务发起方会依次执行一阶段和二阶段方法，然后结束分布式事务，返回结果。如果让分布式事务发起方执行完一阶段之后马上结束并返回结果，二阶段交由独立的线程或者进程异步执行，这样分布式事务的二阶段会晚几秒钟或者若干分钟执行，但事务的最终结果不会有任何改变。
3. 分布式事务的高可用
分布式事务服务是无状态的，而底层数据库副本在各机房间也是双向同步，这样业务流量从一个机房切到另外一个机房，分布式事务服务不会对业务有任何影响，从而保证了分布式事务服务的高可用。