Seata AT事务方案
Seata 的 AT 模式（Automatic Transaction）是一种无侵入的分布式事务解决方案。下面结合具体业务场景来分析其执行的原理。
业务场景
订单系统
当用户下订单时，执行以下三步流程：
订单系统保存订单 订单系统调用库存服务，
减少商品库存 订单系统调用账户服务，
扣减用户金额
这三步要作为一个整体事务进行管理，要么整体成功，要么整体失败。
Seata AT基本原理
Seata AT 事务分两个阶段来管理全局事务：
第一阶段： 执行各分支事务
第二阶段： 控制全局事务最终提交或回滚
第一阶段：执行各分支事务
微服务系统中，各服务之间无法相互感知事务是否执行成功，这时就需要一个专门的服务，来协调各个服务的运行状态。这个服务称为 TC（Transaction Coordinator），事务协调器。
订单系统开始执行保存订单之前，首先启动 TM（Transaction Manager，事务管理器），由 TM 向 TC 申请开启一个全局事务：
这时TC会产生一个全局事务ID，称为 XID，并将 XID 传回 TM：
这样就开启了全局事务！
全局事务开启后，开始执行创建订单的业务。首先执行保存订单，这时会先启动一个 RM（Resource Manager，资源管理器），并将 XID 传递给 RM。
RM 负责对分支事务（即微服务的本地事务）进行管理，并与 TC 通信，上报分支事务的执行状态、接收全局事务的提交或回滚指令。
RM 首先会使用 XID 向 TC 注册分支事务，将分支事务纳入对应的全局事务管辖。
现在可以执行保存订单的分支事务了。一旦分支事务执行成功，RM 会上报事务状态：
TC 收到后，会将该状态信息传递到 TM：
到此，保存订单过程结束。下面是调用库存服务，减少商品库存，与订单的执行过程相同。
首先调用库存服务，启动 RM，并传递 XID：
库存服务的 RM 使用 XID 向 TC 进行注册，纳入全局事务管辖：
执行本地事务成功后上报状态，TC会将状态发送给TM：
相同的，完成账户分支事务：
第二阶段：控制全局事务最终提交
现在，TM（全局事务管理器）收集齐了全部分支事务的成功状态，它会进行决策，确定全局事务成功，向 TC 发送全局事务的提交请求：
然后，TC 会向所有 RM 发送提交操作指令，RM 会完成最终提交操作：
到此，全局事务全部提交完成！
第二阶段：控制全局事务最终回滚
上面是全局事务执行成功的情况，下面再来看看事务执行失败的情况。
假设订单业务执行过程中，扣减账户金额这一步分支事务执行失败，那么失败状态对TC上报，然后再发送给TM
TM 会进行决策，确定全局事务失败，向 TC 发送全局事务的回滚请求：
然后，TC 会向所有 RM 发送回滚操作指令，RM 会完成最终回滚操作：
TCC 基本原理
TCC 与 Seata AT 事务一样都是两阶段事务，它与 AT 事务的主要区别为：
TCC 对业务代码侵入严重
每个阶段的数据操作都要自己进行编码来实现，事务框架无法自动处理。
TCC 效率更高
不必对数据加全局锁，允许多个事务同时操作数据。
第一阶段 Try
以账户服务为例，当下订单时要扣减用户账户金额：
假如用户购买 100 元商品，要扣减 100 元。
TCC 事务首先对这100元的扣减金额进行预留，或者说是先冻结这100元：
第二阶段 Confirm
如果第一阶段能够顺利完成，那么说明“扣减金额”业务（分支事务）最终肯定是可以成功的。当全局事务提交时， TC会控制当前分支事务进行提交，如果提交失败，TC 会反复尝试，直到提交成功为止。
当全局事务提交时，就可以使用冻结的金额来最终实现业务数据操作：
第二阶段 Cancel
如果全局事务回滚，就把冻结的金额进行解冻，恢复到以前的状态，TC 会控制当前分支事务回滚，如果回滚失败，TC 会反复尝试，直到回滚完成为止。
多个事务并发的情况
多个TCC全局事务允许并发，它们执行扣减金额时，只需要冻结各自的金额即可：
————————————————
版权声明：本文为CSDN博主「闪耀太阳a」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/Gufang617/article/details/129111735