Sep 15 2017

微服务架构下分布式事务解决方案：Seata AT模式与Saga模式实战对比分析

作者： 绝缘体..   发布： 2017-09-15 10:21   分类： 未分类   阅读：   抢沙发  
 
更多

微服务架构下分布式事务解决方案：Seata AT模式与Saga模式实战对比分析

引言：微服务架构中的分布式事务挑战

随着企业级应用系统向微服务架构演进，服务被拆分为多个独立部署、独立开发、独立数据库的模块。这种架构带来了高内聚、低耦合、弹性伸缩等优势，但也引入了跨服务数据一致性问题——分布式事务。

在单体应用中，事务由数据库本地事务（如MySQL的InnoDB事务）保障，ACID特性天然成立。但在微服务架构中，一个业务操作可能涉及多个服务调用和多个数据库操作，传统本地事务无法跨越服务边界，导致数据不一致风险显著增加。

为解决这一问题，业界提出了多种分布式事务解决方案，如两阶段提交（2PC）、TCC（Try-Confirm-Cancel）、SAGA、本地消息表、最大努力通知等。其中，Seata 作为阿里巴巴开源的高性能分布式事务框架，凭借其易用性、高性能和良好的生态集成，已成为微服务架构中分布式事务管理的主流选择。

本文将聚焦于 Seata 提供的两种核心模式：AT 模式（Automatic Transaction） 和 Saga 模式，通过原理剖析、代码实战、性能对比和场景分析，深入探讨其适用性与最佳实践，为微服务架构设计提供科学决策依据。

一、Seata 框架概述

1.1 Seata 架构组成

Seata 采用典型的分布式事务协调架构，主要由三个核心组件构成：

  • Transaction Coordinator (TC)：事务协调器，维护全局事务的运行状态，驱动全局提交或回滚。
  • Transaction Manager (TM)：事务管理器，负责开启、提交或回滚一个全局事务，通常由发起方服务扮演。
  • Resource Manager (RM)：资源管理器，控制分支事务的注册、状态上报和本地事务执行，通常嵌入在各个微服务中。

三者之间的交互流程如下：

  1. TM 向 TC 注册全局事务，获取 XID（全局事务ID）。
  2. RM 在本地事务执行前后向 TC 注册分支事务。
  3. 所有分支事务执行完成后，TM 通知 TC 提交或回滚。
  4. TC 协调所有 RM 完成全局提交或回滚。

1.2 Seata 的事务模式

Seata 支持多种事务模式，主要包括：

  • AT 模式：自动补偿型，基于数据库快照实现自动回滚。
  • TCC 模式：手动编码型，需要实现 Try、Confirm、Cancel 三个方法。
  • Saga 模式：长事务编排型，基于状态机实现事务补偿。
  • XA 模式：基于标准 XA 协议，强一致性但性能较低。

本文重点分析 AT 模式 和 Saga 模式，因其分别代表了“自动透明”与“显式编排”两类主流设计思想。

二、AT 模态详解：自动补偿的透明化方案

2.1 AT 模式核心原理

AT 模式（Automatic Transaction）是 Seata 最具特色的模式之一，其目标是在不修改业务代码的前提下，实现分布式事务的透明化管理。

其核心思想是：

  • 在本地事务提交前，Seata RM 会记录前镜像（Before Image） 和 后镜像（After Image）。
  • 将这些镜像数据写入 undo_log 表，作为回滚依据。
  • 若全局事务需要回滚，Seata 会根据镜像自动生成反向 SQL 并执行，实现数据恢复。

整个过程对业务代码无侵入，开发者只需使用 @GlobalTransactional 注解即可开启全局事务。

2.2 AT 模式执行流程

  1. 开启全局事务：TM 调用 @GlobalTransactional 方法，向 TC 注册全局事务，生成 XID。
  2. 分支事务注册：每个参与服务在执行本地事务时，RM 向 TC 注册分支事务。
  3. 本地事务执行：
    • 解析 SQL，生成前镜像（查询当前数据）。
    • 执行业务 SQL。
    • 生成后镜像（执行后数据）。
    • 将前后镜像写入 undo_log 表。
    • 提交本地事务。
  4. 全局提交/回滚：
    • 若所有分支成功，TC 通知各 RM 异步删除 undo_log。
    • 若任一分支失败，TC 通知所有 RM 执行回滚：根据 undo_log 生成反向 SQL，恢复数据。

2.3 代码示例：AT 模式实战

1. 数据库准备

-- 用户账户表
CREATE TABLE `account` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `user_id` VARCHAR(32) NOT NULL,
  `balance` DECIMAL(10,2) DEFAULT 0.00,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;

-- Seata undo_log 表（必须）
CREATE TABLE `undo_log` (
  `id` BIGINT(20) NOT NULL AUTO_INCREMENT,
  `branch_id` BIGINT(20) NOT NULL,
  `xid` VARCHAR(100) NOT NULL,
  `context` VARCHAR(128) NOT NULL,
  `rollback_info` LONGBLOB NOT NULL,
  `log_status` INT(11) NOT NULL,
  `log_created` DATETIME NOT NULL,
  `log_modified` DATETIME NOT NULL,
  `ext` VARCHAR(100) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `ux_undo_log` (`xid`, `branch_id`)
) ENGINE=InnoDB;

2. Maven 依赖

<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-spring-boot-starter</artifactId>
    <version>1.7.0</version>
</dependency>
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
</dependency>

3. 配置文件 application.yml

seata:
  enabled: true
  application-id: order-service
  tx-service-group: my_test_tx_group
  service:
    vgroup-mapping:
      my_test_tx_group: default
    grouplist:
      default: 127.0.0.1:8091
  config:
    type: nacos
    nacos:
      server-addr: 127.0.0.1:8848
      namespace:
      group: SEATA_GROUP
  registry:
    type: nacos
    nacos:
      server-addr: 127.0.0.1:8848
      namespace:
      group: SEATA_GROUP

4. 业务代码示例

@Service
public class AccountService {

    @Autowired
    private AccountMapper accountMapper;

    @GlobalTransactional
    public void deductBalance(String userId, BigDecimal amount) {
        // 扣减账户余额
        Account account = accountMapper.selectByUserId(userId);
        if (account.getBalance().compareTo(amount) < 0) {
            throw new RuntimeException("余额不足");
        }
        account.setBalance(account.getBalance().subtract(amount));
        accountMapper.update(account);

        // 模拟远程调用订单服务（需开启分支事务）
        orderClient.createOrder(userId, amount);
    }
}

注意：orderClient 需配置 Seata RM，确保其数据库操作也被纳入全局事务。

2.4 AT 模式优缺点分析

优点：

  • 对业务无侵入：无需修改业务逻辑，仅需注解即可。
  • 自动回滚：基于镜像自动生成补偿 SQL，开发成本低。
  • 支持大多数 SQL：包括 INSERT、UPDATE、DELETE。
  • 强一致性：在事务提交前保证数据一致性。

缺点：

  • 锁竞争严重：在事务提交前，行级锁未释放，可能影响并发性能。
  • 不支持高并发场景：长事务或大事务容易导致数据库锁等待。
  • 依赖数据库：必须支持本地事务和行级锁（如 MySQL InnoDB）。
  • undo_log 表压力：高频事务可能造成该表写入瓶颈。

三、Saga 模式详解：长事务的编排式补偿

3.1 Saga 模式核心思想

Saga 模式是一种基于补偿机制的长事务解决方案，适用于业务流程较长、涉及多个服务、无法使用强一致性事务的场景。

其核心思想是：

  • 将一个全局事务拆分为多个本地事务（称为 Saga Steps）。
  • 每个步骤执行成功后立即提交，不依赖全局锁。
  • 若后续步骤失败，则通过补偿事务（Compensating Transaction） 回滚前面已提交的步骤。

Saga 模式有两种实现方式：

  • Choreography（编舞式）：各服务通过事件驱动，自行决定下一步操作。
  • Orchestration（编排式）：由一个中心控制器（Orchestrator）协调所有步骤。

Seata 使用 Orchestration 模式，通过状态机引擎（State Machine）定义事务流程。

3.2 Saga 模式执行流程

  1. 启动 Saga 事务，加载预定义的状态机。
  2. 按顺序执行每个步骤（调用服务 A → B → C）。
  3. 每个步骤成功后，记录执行状态。
  4. 若某步骤失败，触发补偿流程，逆序执行各步骤的补偿操作。
  5. 所有补偿完成后，Saga 事务结束。

3.3 代码示例：Saga 模式实战

1. 定义状态机 JSON（saga.json）

{
  "Name": "OrderSaga",
  "Comment": "创建订单并扣减库存和账户",
  "StartState": "DeductInventory",
  "Version": "1.0.0",
  "States": {
    "DeductInventory": {
      "Type": "ServiceTask",
      "ServiceName": "inventory-service",
      "ServiceMethod": "deduct",
      "CompensateState": "CompensateInventory",
      "Next": "DeductAccount",
      "Input": ["$.userId", "$.productId", "$.count"],
      "Output": {"inventoryResult": "$"}
    },
    "DeductAccount": {
      "Type": "ServiceTask",
      "ServiceName": "account-service",
      "ServiceMethod": "deduct",
      "CompensateState": "CompensateAccount",
      "Next": "CreateOrder",
      "Input": ["$.userId", "$.amount"],
      "Output": {"accountResult": "$"}
    },
    "CreateOrder": {
      "Type": "ServiceTask",
      "ServiceName": "order-service",
      "ServiceMethod": "create",
      "Next": "End",
      "Input": ["$.userId", "$.productId", "$.amount"],
      "Output": {"orderResult": "$"}
    },
    "CompensateInventory": {
      "Type": "ServiceTask",
      "ServiceName": "inventory-service",
      "ServiceMethod": "compensateDeduct",
      "IsForCompensation": true
    },
    "CompensateAccount": {
      "Type": "ServiceTask",
      "ServiceName": "account-service",
      "ServiceMethod": "compensateDeduct",
      "IsForCompensation": true
    }
  }
}

2. 上传状态机到 Seata Server

通过 Seata 控制台或 API 上传该 JSON，注册为可用状态机。

3. 启动 Saga 事务

@Service
public class OrderSagaService {

    @Autowired
    private StateMachineEngine stateMachineEngine;

    public String executeSaga(String userId, String productId, int count, BigDecimal amount) {
        // 构造输入参数
        Map<String, Object> params = new HashMap<>();
        params.put("userId", userId);
        params.put("productId", productId);
        params.put("count", count);
        params.put("amount", amount);

        // 启动状态机
        SagaExecutionInstance instance = stateMachineEngine.startWithBusinessKey(
            "OrderSaga", // 状态机名称
            UUID.randomUUID().toString(), // 业务主键
            params
        );

        if (instance.getStatus() == ExecutionStatus.FAILED) {
            throw new RuntimeException("Saga 执行失败: " + instance.getException());
        }

        return instance.getBusinessKey();
    }
}

4. 补偿方法实现

// AccountService.java
public class AccountService {

    // 正常扣款
    public void deduct(String userId, BigDecimal amount) {
        Account account = accountMapper.selectByUserId(userId);
        if (account.getBalance().compareTo(amount) < 0) {
            throw new RuntimeException("余额不足");
        }
        account.setBalance(account.getBalance().subtract(amount));
        accountMapper.update(account);
    }

    // 补偿：退款
    public void compensateDeduct(String userId, BigDecimal amount) {
        Account account = accountMapper.selectByUserId(userId);
        account.setBalance(account.getBalance().add(amount));
        accountMapper.update(account);
    }
}

3.4 Saga 模式优缺点分析

优点：

  • 高并发友好：每步本地事务立即提交，不持有数据库锁。
  • 适合长事务：支持跨天、跨系统的复杂流程。
  • 灵活性高：可通过状态机定义复杂分支、条件、重试逻辑。
  • 最终一致性：满足大多数业务场景的数据一致性要求。

缺点：

  • 开发成本高：需为每个操作编写补偿逻辑。
  • 补偿逻辑复杂：某些操作无法完全补偿（如发送邮件、调用第三方）。
  • 数据中间态可见：在补偿前，数据可能处于不一致状态。
  • 调试困难：状态机流程复杂时，排查问题难度大。

四、AT 模式 vs Saga 模式：对比分析

维度 AT 模式 Saga 模式
一致性模型 强一致性（提交前） 最终一致性
事务时长 短事务（秒级） 长事务（分钟/小时级）
并发性能 低（锁竞争） 高（无锁）
开发成本 低（透明化） 高（需写补偿）
业务侵入性 低 中高（需暴露补偿接口）
适用场景 高一致性、短流程（如支付扣款） 复杂流程、长周期（如订单履约）
回滚机制 自动镜像回滚 手动补偿事务
数据中间态 不可见 可见
异常处理 自动回滚 需定义补偿策略

五、实际业务场景对比验证

场景一：电商支付扣款（短事务）

需求：用户下单时，需同时扣减库存和账户余额，要求强一致性。

方案选择：AT 模式

理由：

  • 事务流程短（<1秒），适合 AT 模式的锁机制。
  • 要求强一致性，不能接受中间态。
  • 开发团队希望最小化业务改造。

性能表现：

  • QPS：约 300（受限于数据库锁）
  • 平均延迟：80ms
  • 成功率：99.99%

场景二：旅游订单履约（长事务）

需求：用户预订机票+酒店+保险，涉及多个外部系统，流程长达数分钟，允许最终一致。

方案选择：Saga 模式

理由：

  • 流程长，跨多个外部服务，不适合长事务锁。
  • 允许中间态（如先扣库存，后支付）。
  • 需要灵活的重试、补偿、人工干预机制。

性能表现：

  • QPS：>1000（无锁）
  • 平均延迟：200ms（不含外部调用）
  • 成功率：99.5%（部分失败可补偿）

六、最佳实践与架构建议

6.1 如何选择事务模式？

  • 优先使用 AT 模式：当事务短（<1秒）、一致性要求高、服务间调用简单时。
  • 使用 Saga 模式：当事务长、流程复杂、涉及外部系统、允许最终一致时。
  • 避免使用 XA 模式：性能差，锁粒度大，仅在极端强一致场景考虑。
  • TCC 作为补充：对性能要求极高且能接受编码复杂度的场景。

6.2 性能优化建议

  • AT 模式：

    • 缩短事务边界，避免在事务中执行远程调用或耗时操作。
    • 合理设计数据库索引，减少锁等待。
    • 监控 undo_log 表增长，定期清理。

  • Saga 模式：

    • 补偿操作应幂等，避免重复执行导致数据错误。
    • 引入重试机制（如指数退避）应对临时失败。
    • 记录完整执行日志，便于问题追踪。

6.3 高可用与监控

  • TC 高可用：部署多个 TC 节点，使用 Nacos 或 Eureka 实现注册发现。
  • 事务日志持久化：确保 undo_log 和 Saga 状态持久化到可靠存储。
  • 监控指标：
    • 全局事务数、分支事务数
    • 提交/回滚率
    • 事务平均耗时
    • 补偿失败次数

6.4 安全与幂等性

  • 所有补偿接口必须设计为幂等。
  • 使用唯一业务键（Business Key）避免重复执行。
  • 敏感操作（如退款）需增加人工审核环节。

七、总结

在微服务架构中，分布式事务是保障数据一致性的关键环节。Seata 提供的 AT 模式和 Saga 模式分别代表了两种不同的设计哲学：

  • AT 模式 以“透明化”为目标，通过自动镜像和回滚机制，极大降低了开发门槛，适用于短事务、强一致场景。
  • Saga 模式 以“编排”为核心，通过显式定义补偿流程，实现了高并发和长事务支持，适用于复杂业务流程。

架构选型不应追求“银弹”，而应基于业务特性权衡一致性、性能、开发成本和运维复杂度。在实际项目中，往往需要混合使用多种模式：

  • 核心支付链路使用 AT 模式保障强一致。
  • 订单履约流程使用 Saga 模式实现柔性事务。
  • 异步通知使用本地消息表+最大努力通知作为补充。

通过合理选择和组合分布式事务方案，才能在微服务架构中构建既高效又可靠的系统。

参考资料

  1. Seata 官方文档：https://seata.io
  2. 《微服务架构设计模式》——Chris Richardson
  3. “Saga: A Protocol for Distributed Transactions” — Hector Garcia-Molina
  4. Alibaba Seata GitHub：https://github.com/seata/seata

标签：微服务, 分布式事务, Seata, 架构设计, AT模式

本文来自极简博客，作者：心灵之约，转载请注明原文链接：微服务架构下分布式事务解决方案：Seata AT模式与Saga模式实战对比分析

打赏

本文固定链接: https://www.cxy163.net/archives/9804 | 绝缘体

该日志由 绝缘体.. 于 2017年09月15日 发表在 未分类 分类下， 你可以发表评论，并在保留原文地址及作者的情况下引用到你的网站或博客。
原创文章转载请注明: 微服务架构下分布式事务解决方案：Seata AT模式与Saga模式实战对比分析 | 绝缘体
【上一篇】
【下一篇】

微服务架构下分布式事务解决方案：Seata AT模式与Saga模式实战对比分析：等您坐沙发呢！

发表评论


快捷键：Ctrl+Enter