在微服务架构大行其道的今天一个业务操作往往需要调用多个服务、操作多个数据库。如何保证跨服务、跨数据库的数据一致性成为开发者必须面对的挑战。SeataSimple Extensible Autonomous Transaction Architecture作为一款开源的分布式事务解决方案正是为了解决这一问题而生的。Seata 定义了三个核心角色来协调分布式事务· TCTransaction Coordinator 事务协调者独立部署的服务端维护全局和分支事务的状态驱动全局事务的提交或回滚。· TMTransaction Manager 事务管理器嵌入在应用中负责定义全局事务的范围开启、提交或回滚。· RMResource Manager 资源管理器嵌入在应用中管理分支事务的资源向 TC 注册分支事务并报告其状态。Seata 提供了四种事务模式AT、TCC、Saga 和 XA。下面逐一深入剖析每种模式的工作原理。一、AT 模式自动补偿零侵入ATAuto Transaction模式是 Seata 默认推荐、也是最常用的模式主打零业务侵入和高性能。核心机制AT 模式是对传统两阶段提交2PC协议的演进一阶段业务数据和回滚日志在同一个本地事务中提交然后释放本地锁和连接资源。二阶段如果是提交则异步化处理非常快速地完成如果是回滚则通过一阶段记录的回滚日志进行反向补偿。工作流程详解以一更新操作为例AT 模式的一阶段会执行以下步骤解析 SQL解析出 SQL 的类型如 UPDATE、表名、条件等信息。查询前镜像根据条件查询数据修改前的状态。执行业务 SQL执行实际的业务更新操作。查询后镜像根据主键查询数据修改后的状态。插入回滚日志将前后镜像数据及业务 SQL 信息组装成一条记录插入 UNDO_LOG 表。注册分支事务向 TC 申请该记录的全局锁。提交本地事务业务数据更新和 UNDO_LOG 一并提交然后释放本地锁。二阶段如果收到回滚请求RM 会通过 UNDO_LOG 中的前镜像数据生成反向补偿 SQL 并执行将数据恢复到修改前的状态。如果收到提交请求则异步删除对应的 UNDO_LOG 记录。隔离性保障AT 模式通过全局锁机制来保证写隔离。一阶段本地事务提交前必须先拿到全局锁否则不能提交。这确保了不同全局事务之间不会发生脏写。在读隔离方面AT 模式默认的全局隔离级别是读未提交。如果业务需要全局读已提交可以通过 SELECT FOR UPDATE 语句来申请全局锁从而读到已提交的数据。适用场景大多数需要分布式事务的普通业务场景开发成本低性能好。二、TCC 模式手动补偿精细控制TCCTry-Confirm-Cancel模式是 Seata 支持的第二种事务模式最早由蚂蚁金服贡献。它是一种侵入式的分布式事务解决方案需要业务方自行实现 Try、Confirm、Cancel 三个操作。核心机制TCC 模式本质上是服务化的两阶段提交· Try一阶段 负责资源的检查和预留。· Confirm二阶段提交 执行真正的业务操作。· Cancel二阶段回滚 执行预留资源的取消使资源回到初始状态。工作流程TM 向 TC 开启全局事务。各参与者执行 Try 操作进行资源预留。如果所有参与者的 Try 都成功TC 驱动各参与者执行 Confirm 操作完成最终提交。如果任一参与者的 Try 失败TC 驱动所有参与者执行 Cancel 操作释放预留资源。在 Seata 中TCC 接口通过 TwoPhaseBusinessAction 注解来标记分别指定 commitMethodConfirm和 rollbackMethodCancel。优势与挑战优势完全不依赖底层数据库能实现跨数据库、跨应用的资源管理业务方可灵活控制资源锁定粒度。挑战三个操作都需要业务编码实现对业务侵入大设计相对复杂还需额外处理幂等、空回滚和悬挂等问题。适用场景核心系统等对性能有很高要求、需要精细控制事务粒度的场景。三、Saga 模式长事务最终一致性Saga 模式是 Seata 提供的长事务解决方案。其理论基础源于 Hector Kenneth 在 1987 年发表的论文 Sagas。核心机制在 Saga 模式中每个参与者都提交自己的本地事务。当某个参与者失败时会补偿前面所有已经成功的参与者。一阶段的正向服务和二阶段的补偿服务都需要业务开发实现。Seata 的 Saga 模式基于状态机引擎来实现通过状态图定义服务调用流程生成 JSON 状态语言定义文件。状态图中的每个节点可以调用一个服务并配置对应的补偿节点。状态图 JSON 由状态机引擎驱动执行。当出现异常时状态引擎反向执行已成功节点对应的补偿节点实现事务回滚。状态机引擎原理状态机的执行基于事件驱动模型一个状态执行完成后产生路由消息放入 EventQueue消费端取出消息执行下一个状态。状态机启动时会调用 Seata Server 开启分布式事务并生成 XID执行每个状态时会注册分支事务整个状态机执行完成后提交或回滚分布式事务。状态机引擎是无状态的内嵌在应用中执行日志存储在业务数据库中具备高可用能力。适用场景业务流程复杂、执行时间长的长事务场景。四、XA 模式标准协议平滑迁移XA 模式是 Seata 从 1.2 版本开始支持的事务模式。它利用数据库等事务资源对 XA 协议的原生支持来管理分支事务。核心机制XA 模式遵循标准的 XA 两阶段提交协议执行阶段· 业务 SQL 在 XA 分支中执行由数据库的 XA 协议支持保证可回滚。· XA 分支完成后执行 XA prepare由数据库保证持久化即使之后发生意外也能回滚。完成阶段· 分支提交执行 XA commit。· 分支回滚执行 XA rollback。优势与局限优势· 业务无侵入和 AT 模式一样不给应用带来额外负担。· 数据库支持广泛XA 协议被主流关系型数据库广泛支持。· 强一致性事务资源本身保障数据的有效隔离和全局一致性。局限· XA prepare 后分支事务进入阻塞阶段必须等待 commit 或 rollback资源锁定周期长性能较差。适用场景希望从基于 XA 协议的老应用平滑迁移到 Seata 平台或 AT 模式尚未适配的数据库应用。总结对比模式 侵入性 一致性 性能 适用场景AT 无侵入 强一致 高 大多数业务场景TCC 高侵入 强一致 高 核心系统、需精细控制Saga 中侵入 最终一致 中 长事务、复杂流程XA 无侵入 强一致 低 老应用迁移、特殊数据库在实际选型时AT 模式是大多数场景的首选因其零侵入和良好的性能。当需要更精细的资源控制时可以考虑 TCC面对长事务场景则 Saga 更为合适而 XA 模式则为特定迁移场景提供了平滑路径。理解这四种模式的工作原理能够帮助你在不同的业务场景中做出更合理的分布式事务方案选择。