再问你一遍，你真的了解分布式事务吗？

如下图所示，Seata 中有三大模块，分别是 TM、RM 和 TC。其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 的服务端独立部署：

TC：事务协调者，维护全局和分支事务的状态，驱动全局事务提交或回滚。

TM：事务管理器，定义全局事务的范围：开始全局事务、提交或回滚全局事务。

RM：资源管理器，管理分支事务处理的资源，与 TC 交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

在 Seata 中，分布式事务的执行流程：

TM 开启分布式事务(TM 向 TC 注册全局事务记录)。

按业务场景，编排数据库、服务等事务内资源(RM 向 TC 汇报资源准备状态 )。

TM 结束分布式事务，事务一阶段结束(TM 通知 TC 提交/回滚分布式事务)。

TC 汇总事务信息，决定分布式事务是提交还是回滚。

TC 通知所有 RM 提交/回滚资源，事务二阶段结束。

①AT 模式

AT 模式是一种无侵入的分布式事务解决方案。

在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。

一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。

二阶段：提交异步化，非常快速地完成。回滚通过一阶段的回滚日志进行反向补偿。

在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。

以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。

②TCC 模式

一个分布式的全局事务，整体是两阶段提交的模型。全局事务是由若干分支事务组成的，分支事务要满足两阶段提交的模型要求，即需要每个分支事务都具备自己的：

一阶段 prepare 行为。

二阶段 commit 或 rollback 行为。

TCC 模式，不依赖于底层数据资源的事务支持：

一阶段 prepare 行为：调用自定义的 prepare 逻辑。

二阶段 commit 行为：调用自定义的 commit 逻辑。

二阶段 rollback 行为：调用自定义的 rollback 逻辑。

所谓 TCC 模式，是指支持把 自定义 的分支事务纳入到全局事务的管理中。

③Saga 模式

目前 Seata 提供的 Saga 模式是基于状态机引擎来实现的，机制是：

通过状态图来定义服务调用的流程并生成 json 状态语言定义文件。

状态图中一个节点可以是调用一个服务，节点可以配置它的补偿节点。

状态图 json 由状态机引擎驱动执行，当出现异常时状态引擎反向执行已成功节点对应的补偿节点将事务回滚 (异常发生时是否进行补偿也可由用户自定义决定)。

可以实现服务编排需求，支持单项选择、并发、子流程、参数转换、参数映射、服务执行状态判断、异常捕获等功能。

状态机引擎原理：

图中的状态图是先执行 stateA，再执行 stateB，然后执行 stateC。

"状态"的执行是基于事件驱动的模型，stateA 执行完成后，会产生路由消息放入 EventQueue，事件消费端从 EventQueue 取出消息，执行 stateB。

在整个状态机启动时会调用 Seata Server 开启分布式事务，并生产 xid，然后记录"状态机实例"启动事件到本地数据库。

当执行到一个"状态"时会调用 Seata Server 注册分支事务，并生产 branchId，然后记录"状态实例"开始执行事件到本地数据库。

当一个"状态"执行完成后会记录"状态实例"执行结束事件到本地数据库，然后调用 Seata Server 上报分支事务的状态。

当整个状态机执行完成, 会记录"状态机实例"执行完成事件到本地数据库，然后调用 Seata Server 提交或回滚分布式事务。