seata的AT模式的执行流程

分布式事务

分布式事务是为了解决业务跨多个服务实现，业务跨多个数据源实现的问题，更优于传统事务
解决分布式事务的思想非常简单：
就是找一个统一的事务协调者，与多个分支事务通信，检测每个分支事务的执行状态，保证全局事务下的每一个分支事务同时成功或失败即可。大多数的分布式事务框架都是基于这个理论来实现的。

Seata也不例外，在Seata的事务管理中有三个重要的角色：

• TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。
• TM (Transaction Manager) - 事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。
• RM (Resource Manager) - 资源管理器：管理分支事务，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

TM和RM可以理解为Seata的客户端部分，引入到参与事务的微服务依赖中即可。将来TM和RM就会协助微服务，实现本地分支事务与TC之间交互，实现事务的提交或回滚。TC服务则是事务协调中心，是一个独立的微服务，需要单独部署。

AT模式（最终一致性）

在Seata中，AT模式同样是分阶段提交的事务模型，不过缺弥补了XA模型中资源锁定周期过长的缺陷。
流程图如下：

阶段一：
1.1 当全局事务执行时，TM会感知到，并向TC注册一个全局事务，开启全局事务
1.2 再调用分支（即微服务），这些服务会调用自己的业务逻辑
1.3 执行前会被RM拦截，RM先去注册分支事务到TC
1.4 执行sql并提交（执行前先生成快照，保存修改前的数据）
阶段二：
2.1 提交或回滚事务
2.2 检查分支事务的状态
2.3 如果成功，一阶段已提交过，不需要再做什么，删除log（快照）
2.4 如果失败，需要回滚，恢复log数据