Seata 包含以下 4种分布式事务的处理模式
1.XA 模式
它的性能相比其他事务模式要差一点，但能保证最严格的数据一致性。XA 模式需要设置为串行化隔离级别，相当于对数据添加了读写锁。另外连接资源需要在整个事务期间保持，这样可能会导致资源锁定问题，从而影响并发事务吞吐。
a.优点:实现简单、无业务侵入。
b.缺点:性能差、必须实现 XA 协议、容易产生死锁
c.适用场景:隔离级别要求高，强一致性分阶段事务模型，牺牲了一定的可用性(保证了强一致性)。
2.AT 模式(默认模式)
解决了 XA 模式中锁占用时间过长的问题。它的主要特点是简单无侵入，强一致，学习成。本低。缺点是需要遵守一定的开发规约，它并不是对所有的 SQL 类型都支持，有一定的使用限制。适应于通用的业务场景，但它并不适应于热点数据的高并发场景，像 SKU(Stock Keeping Unit，库存管理中的一个概念，用来唯一标识一个可售卖的商品)的库存的扣减。因为 AT 模式有应用层的全局锁，当需要对相同的数据修改操作时，需要使用全局锁控制事务的并发时序，实现上存在锁排队等待的机制。
a.优点:简单、无业务侵入、事务强一致、学习成本低、性能高于 XA 模式a.
b.缺点:连接数据库支持(本地)事务、遵循一定的开发规范(Java 应用、通过 JDBC 访问数据库)。
c.适用场景:通过场景，不适用于连接的数据库不支持(本地)事务，
3.TCC 模式
业务层面的分布式事务解决方案，TCC，Try-Confirm-Cancel 模式，是一种通过三个步骤(Try、Confirm、Cancel)来实现分布式事务的模式。在 TCC 模式下，应用程序需要自行实现 Try、Confirm、Cancel三个方法，分别表示尝试执行、确认提交和取消回滚。TCC 模式，不依赖于底层数据资源的事务支持
- -阶段 prepare 行为:调用自定义的 prepare 逻辑
- 二阶段 commit 行为:调用自定义的 commit 逻辑
- 二阶段 rollback 行为:调用自定义的 rollback 逻辑
所谓 TCC 模式，是指支持把自定义的分支事务纳入到全局事务的管理中
a.优点:灵活、性能高(不依赖全局锁、不需要生成快照)、不依赖数据库事务
b.缺点:业务侵入大、实现难度高(自己实现事务操作的业务代码)、事务最终一致性(不是强一致性)。
c.适用场景:连接的数据库不支持(本地)事务。
4.SAGA 模式
业务层面的分布式事务解决方案。一个基于长事务的解决方案，Saga 模式解决的是在没有二阶段提交的情况下解决分布式事务。它的核心思想是将一个业务流程中的长事务拆分成多个本地短事务，业务流程中的每个参与者都真实的提交本地短事务，当其中有一个参与者的事务执行失败，则通过补偿机制补偿给前面已经执行成功的参与者，
a.优点:灵活、性能高、可异步化
b.缺点:无锁、不保证隔离性、业务侵入大
c.适用场景:长事务
AT模式有哪些注意事项?
1.AT 模式支持的复合主键数据库有 mysql，oracle，pgsal，mariadb，其他数据库不支持复合主键，必须包是单列主键。因此，建议其他类型的数据库先建一列自增id 主键，原复合主键改为唯一键来规避下。
2.每个业务库中必须包含 undo_log 表，若与分库分表组件联用，分库不分表。
3.使用注解开启分布式事务时，若要求事务回滚，必须将异常抛出到事务的发起方，被事务发起方的@GlobalTransactional 注解感知到，否则将不能回滚全局事务