深入浅出 Seata：从二阶段提交到四大事务模式

摘要：​ 在微服务架构盛行的今天，分布式事务是绕不开的难题。Seata 作为一款开源的分布式事务解决方案，凭借其高性能和易用性，成为了许多开发者的首选。本文将结合流程图，深入剖析 Seata 的核心原理——二阶段提交协议，并详细讲解其四大事务模式，助你彻底搞懂分布式事务。

一、引言

随着业务复杂度的提升，单体架构逐渐被微服务架构取代。然而，微服务架构虽然带来了高内聚、低耦合的好处，却也引入了一个棘手的问题：分布式事务。

当一个业务操作需要跨多个服务、多个数据库执行时，如何保证这些操作要么全部成功，要么全部失败？这就是分布式事务要解决的问题。

Seata（Simple Extensible Autonomous Transaction Architecture）正是为了解决这一问题而生。它提供了高性能、易用的分布式事务解决方案。

二、Seata 的核心架构

在深入原理之前，我们先了解一下 Seata 的三大核心组件：

三、二阶段提交协议（2PC）流程详解

Seata 的核心原理基于二阶段提交协议（Two-Phase Commit）。

第一阶段：准备阶段（Prepare）

在这个阶段，TC 会通知各个 RM（分支事务）执行本地事务，但不提交，而是将执行结果（包括 undo log）上报给 TC。

1. 全局事务开启

• 流程：业务代码通过 @GlobalTransactional注解开启全局事务。

• 动作：TC 生成全局事务 ID（XID），并通知各个分支事务开始执行。

2. 分支事务执行（本地事务）

• 流程：以扣减库存为例。

• 动作：

  • 解析 SQL：RM 解析 SQL 语句（如 update storage_tbl set count = count – 2 where commodity_code = 'P0001'）。

  • 查询前镜像：在执行更新前，先查询当前数据的状态（前镜像），用于后续回滚。

  • 执行业务 SQL：执行实际的业务逻辑（扣减库存）。

  • 查询后镜像：执行更新后，查询数据的新状态（后镜像）。

  • 插入回滚日志：将前镜像、后镜像以及业务 SQL 生成一条 undo log 记录，插入到 undo_log 表中。

  • 申请全局锁：为了防止并发冲突，RM 会申请全局锁（如对 storage_tbl的 1 号记录加锁）。

  • 本地事务提交：将业务数据和 undo log 一起提交到数据库。

  • 汇报结果：RM 向 TC 汇报分支事务执行成功。

3. TC 汇总

• 流程：TC 收到所有分支事务的汇报。

• 动作：如果所有分支事务都执行成功，TC 进入第二阶段；如果有任何一个分支事务失败，TC 会触发回滚流程。

第二阶段：提交/回滚阶段（Commit/Rollback）

在这个阶段，TC 根据第一阶段的结果，决定是提交还是回滚。

1. 提交（Commit）

• 流程：如果所有分支事务都成功。

• 动作：TC 通知各个 RM 提交分支事务。RM 收到指令后，直接提交本地事务。由于 undo log 已经写入，提交过程非常快，通常只需要删除 undo log 即可（异步删除）。

2. 回滚（Rollback）

• 流程：如果任何一个分支事务失败。

• 动作：

  • 开启本地事务：RM 开启一个新的本地事务。

  • 找到 undo log：根据 XID 和 Branch ID 找到对应的 undo log 记录。

  • 数据校验：对比当前数据（后镜像）与 undo log 中的后镜像，防止数据被其他渠道修改（防篡改）。

  • 执行回滚：根据 undo log 中的前镜像，执行反向 SQL，将数据恢复到事务开始前的状态。

  • 提交回滚事务：提交回滚操作。

  • 删除 undo log：删除 undo log 记录。

四、Seata 的四大事务模式

Seata 提供了四种事务模式，以适应不同的业务场景：

1. AT 模式（Automatic Transaction）

• 特点：这是 Seata 默认且最常用的模式。它对业务代码无侵入，只需要在数据库中增加一张 undo_log 表。

• 适用场景：绝大多数基于关系型数据库的业务场景。

• 原理：如上文所述，通过解析 SQL 生成 undo log，实现自动回滚。

2. TCC 模式（Try-Confirm-Cancel）

• 特点：这是一种侵入性较强的模式，需要业务代码实现 Try、Confirm、Cancel 三个接口。

• 适用场景：对性能要求极高，或者需要对资源进行预留的场景（如秒杀、库存扣减）。

• 原理：

  • Try：尝试执行业务，预留资源（如冻结库存）。

  • Confirm：确认执行，真正扣减资源。

  • Cancel：取消执行，释放预留资源。

3. Saga 模式

• 特点：这是一种长事务解决方案，通过状态机来管理事务。

• 适用场景：业务流程长、步骤多，且需要人工介入或异步处理的场景（如订单创建、支付、发货）。

• 原理：将长事务拆分为一系列短事务，每个短事务都有对应的补偿操作。如果某个步骤失败，Seata 会自动执行前面步骤的补偿操作来回滚。

4. XA 模式

• 特点：基于标准的 XA 协议，依赖数据库的 XA 支持。

• 适用场景：需要强一致性的场景，或者已经使用了支持 XA 的数据库。

• 原理：利用数据库自身的两阶段提交能力，Seata 作为协调者来管理全局事务。

五、总结

Seata 通过二阶段提交协议，结合 undo log 机制，巧妙地解决了分布式事务的一致性问题。无论是无侵入的 AT 模式，还是高性能的 TCC 模式，Seata 都提供了灵活的解决方案。

希望本文能帮助你彻底搞懂 Seata 的原理。如果你在实际项目中遇到了分布式事务的难题，不妨试试 Seata，相信它能给你带来惊喜。