Seata是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata将为用户提供了AT、TCC、SAGA和XA事务模式，为用户打造一站式的分布式解决方案。
AT模式
🍮实现原理
阿里SEATA独有模式，通过生成反向SQL实现数据回滚，需要在数据库额外附加UNDO_LOG表，UNDO_LOG表中保存的是自动生成的回滚SQL。
举个🌰
insert into 订单 values(1001,...)
update 仓储 set num = 300 where gid =100；
自动生成UNDO_LOG回滚日志
DELETE FROM 订单 where id =1001
update 仓储 set num=210 where gid = 100
特点
性能：高
模式：AP,存在数据不一致的中间状态
难易程度：简单，靠SEATA自己解析反向SQL并闻滚
使用要求：
所有服务与数据库必须要自己拥有管理权，因为要创建UNDO LOG表
最好都是MySQL,听说也支持PSQL,不过没试验过
应用场景：
高并发互联网应用，允许数据出现短时不一致，可通过对账程序或补录来保证最终一致性。
TCC模式
🍮实现原理
TCC是Try-尝试、Confirm-确认、Cancel-取消Try尝试阶段，对资源进行锁定。
Confirm确认阶段，对资源进行确认，完成操作Cancel取消阶段，对资源进行还原，取消操作。
在代码与数据表中扩展字段，实现对特定数据资源的锁定。
Try阶段：预留所需的资源，预增金额，冻结库存
Confirm确认阶段：把预留的资源放入真实资源字段，清空预留资源
cancel阶段：对锁定的资源释放
特点
性能：好
模式：AP,存在数据不一致的中间状态
难易程度：复杂，SEATA TC只负责全局事务的提交与回滚指令，具体的回滚处理全靠程序员自己实现(每个业务流程车都需手动写代码TRY,COMMIT,CANCEL三个对应的方法)
使用要求：
所有服务与数据库必须要自己拥有管理权
支持异构数据库，可以使用不同选型实现
应用场景：
高并发互联网应用，允许数据出现短时不一致，可通过对账程序或补录来保证最终一致性。
SAGA模式
🍮实现原理
Saga模式是SEATA提供的长事务解决方案，在Saga模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务具体实现者开发实现。
这里比如支付宝只提供了转账接口和退款接口，而你具体负责商城订单业务，正向流程下单-支付成功-扣减库存-订单状态变更为待发货。
如果扣减库存失败，比如库存为0扣减失败了，这时候你需要自行调用支付宝的退款接口，模拟事务回滚的业务流程，支付宝是不会帮你实现事务回滚的。
特点
性能：不一定，取决于三方服务
模式：AP,存在数据不一致的中间状态
难易程度：复杂，提交与回滚流程全靠程序员编排
使用要求：
在当前架构引入状态机机制，类似于工作流
无法保证隔离性
应用场景：
需要与第三方交互时才会考虑，例如：调用支付宝支付接口->出库失败->调用支付宝退款接口
XA模式
🍮实现原理
基于数据库的XA协议来实现2PC又称为XA方案，数据库必须实现并支持XA协议
特点
性能：低
模式：CP,强一致性
难易程度：简单，基于数据库自带特性实现，无需改表
使用要求：
使用支持XA方案的关系型数据库（主流都支持）
应用场景：
金融行业，并发量不大，但数据很重要的项目
总结：
可以看出，除了TCC基本都是两阶段模式，成功提交，失败回滚。而根据实现难度，TCC和SAGA都需要手动实现业务回滚代码，复杂度要高一些。其他都可以有数据库或者第三方事务管理器实现回滚业务流程，而你只需要专注业务流程本身。
AT,SAGA模式需要所有参与方都有数据库权限，这点如果项目参与方都是一起的不涉及第三方或许可以实现。但如果你调用的是第三方服务，显然不可能支持，第三方更不可能给你提供数据库访问权限，比如支付服务，任何第三方支付都不可能提供数据库权限给你。
因此要综合考虑自己的使用情况，再决定使用哪种模式。
但是现实中，分布式事务还是要根据情况去使用，绝大多数项目能不是使用分布式事务就不会使用。只要确保最终事务一致性即可。
