seata的AT模式将分布式事务是分为准备阶段和提交回滚阶段，主要通过TC、TM、RM三个组件协同完成,然后我分别来解释一下这两个阶段要做的事情。
第一个阶段，首先得让TM主动发起全局事务，生成全局事务id，标记事务边界。TM主要就是触发@GlobalTransactional 注解，开始全局事务，然后就是调用分支事务，就是调用各微服务的分支逻辑，每个分支对应一个RM（资源管理器）。然后呢注册分支事务，就是说RM向TC事务协调者注册分支事务，将分支与全局事务关联，TC记录分支状态。然后在执行sql并提交事务，主要就是RM执行本地SQL，同时记录undo log：记录【更新前快照】（修改前的数据，用于回滚），还有就是记录【更新后快照】（修改后的数据，用于提交检验），本地事务是直接提交。然后到了第二个阶段，首先就是TM根据业务逻辑，就是判断是全局提交或全局回滚，通知TC执行。检查分支事务状态，TC主动检查分支事务的状态，确定是否有失败的分支事务，最后就是提交或者回滚了，如果是提交的话，TC会通知所有的RM执行删除undo log，清理日志完成最后的确认嘛，全局回滚的话，就是通知RM恢复数据，使用undo log数s据恢复数据后删除undo log日志。
在整个流程中，AT 模式的核心优势在于对业务代码的侵入性极低，开发者只需通过 @GlobalTransactional 注解标记全局事务边界，无需手动编写事务协调逻辑，极大简化了分布式事务的实现复杂度。
从技术细节来看，准备阶段中 RM 执行本地 SQL 并提交的设计尤为关键。这不同于传统 2PC 的 “预提交” 机制，本地事务直接提交使得资源不会被长时间锁定，大幅提升了系统的并发性能。而 undo log 的双快照设计则为后续的提交确认和回滚操作提供了可靠依据 —— 更新前快照用于回滚时恢复原始数据，更新后快照则在提交阶段用于校验数据是否被其他事务篡改，确保了分布式事务的隔离性。
在提交阶段，TC 通知 RM 删除 undo log 的过程采用了异步化处理策略。对于已经确认提交的事务，RM 会异步清理日志文件，避免因日志清理操作阻塞主业务流程。而回滚阶段则更为严谨，RM 需要先根据 undo log 中的更新前快照执行数据恢复，待确认数据完全回滚后才删除日志，整个过程通过 TC 的状态跟踪机制保证一致性，防止出现部分分支回滚失败的情况。
此外，AT 模式还具备完善的异常处理机制。当某个分支事务在准备阶段执行失败时，RM 会立即向 TC 反馈错误状态，TC 则会通知 TM 触发全局回滚，避免事务处于中间状态。若在提交或回滚阶段出现网络分区等异常，TC 会通过定时任务重试通知，直到所有 RM 都完成对应操作，同时结合事务日志的持久化存储，确保即使 TC 节点重启，仍能恢复未完成的事务状态，保证最终一致性。
这种基于 “本地事务 + 日志补偿” 的设计思路，既保留了分布式事务的强一致性，又兼顾了系统的可用性和性能，使得 Seata 的 AT 模式能够适应高并发、高可用的微服务场景，成为分布式事务解决方案中的主流选择。
