Jan 20 2022

微服务架构下的分布式事务处理技术预研：Seata、Saga与TCC模式深度对比分析

作者： 绝缘体..   发布： 2022-01-20 06:13   分类： kubernetes, mybatis, MySQL, redis, spring, 云计算, 后端框架, 数据库   阅读：   抢沙发  
 
更多

微服务架构下的分布式事务处理技术预研：Seata、Saga与TCC模式深度对比分析

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

随着企业级应用系统向微服务架构演进，服务的拆分带来了更高的灵活性和可维护性。然而，这种架构也引入了新的技术难题——分布式事务（Distributed Transaction）。在传统单体架构中，事务由数据库的本地事务机制保障，所有操作都在同一个数据库实例中完成，ACID特性（原子性、一致性、隔离性、持久性）得以天然满足。

但在微服务架构中，业务逻辑被拆分为多个独立部署的服务，每个服务通常拥有自己的数据库实例。当一个业务操作需要跨多个服务进行数据更新时，传统的本地事务无法再保证一致性。例如，在电商系统中，“下单”操作可能涉及库存服务扣减库存、订单服务创建订单、支付服务发起支付等多个服务调用。若其中一个步骤失败，而其他步骤已经成功执行，则会导致数据不一致，产生“部分成功”的异常状态。

因此，如何在分布式环境下实现跨服务的事务一致性，成为微服务架构设计的核心挑战之一。为应对这一问题，业界提出了多种解决方案，其中最具代表性的包括 Seata 框架、Saga 模式 和 TCC 模式。本文将深入剖析这三种技术的实现原理、优缺点、适用场景，并结合代码示例与最佳实践，为复杂业务系统提供清晰的技术选型指导。

一、分布式事务核心问题与CAP理论约束

在讨论具体方案之前，必须理解分布式事务的本质限制。根据 CAP 理论（Consistency, Availability, Partition Tolerance），一个分布式系统最多只能同时满足三个属性中的两个：

  • C（一致性）：所有节点在同一时间看到相同的数据。
  • A（可用性）：系统始终能够响应请求。
  • P（分区容忍性）：系统在网络分区发生时仍能继续运行。

在微服务架构中，网络通信不可避免地存在延迟或中断，因此 P 是不可放弃的。这意味着我们必须在 C 和 A 之间做出权衡。

✅ 结论：在高可用要求下，强一致性难以实现。大多数分布式事务方案采用“最终一致性”（Eventual Consistency）策略，即通过补偿机制或协调机制，使系统在一段时间后达到一致状态。

二、Seata：基于 AT 模式的分布式事务框架

2.1 Seata 架构概述

Seata（Simple Extensible Autonomous Transaction Architecture）是由阿里巴巴开源的一款高性能、易于使用的分布式事务解决方案。其核心目标是支持微服务架构下的透明化事务管理，让开发者无需感知底层事务协调过程。

Seata 的整体架构包含以下核心组件：

组件 作用
TC（Transaction Coordinator） 事务协调器，负责全局事务的注册、提交、回滚等控制
TM（Transaction Manager） 事务管理器，位于应用端，负责开启、提交、回滚本地事务
RM（Resource Manager） 资源管理器，负责注册数据源并监听本地事务事件

Seata 支持多种事务模式，其中最常用的是 AT 模式（Automatic Transaction Mode），它对业务代码无侵入，适合大多数场景。

2.2 AT 模式工作原理

AT 模式的核心思想是：利用数据库的 undo log 机制实现自动回滚。

工作流程如下：

  1. 开启全局事务：TM 向 TC 注册一个全局事务，获取全局事务 ID（XID）。
  2. 执行本地事务：
    • RM 在本地数据库执行 SQL 操作前，先记录当前数据快照到 undo_log 表。
    • 执行实际 SQL。
  3. 提交阶段：
    • 如果所有服务都成功，TM 向 TC 发送提交请求。
    • TC 通知所有 RM 提交事务。
    • RM 删除 undo_log 表中的记录。
  4. 回滚阶段：
    • 若任一服务失败，TC 发起全局回滚。
    • RM 根据 undo_log 中的快照数据，反向生成 SQL 并执行，恢复原数据。

📌 关键点：Seata 在数据库层面上插入了 undo_log 表，用于存储操作前后的数据快照。该表需提前创建，且每张业务表对应一条 undo_log 记录。

2.3 部署与配置

1. 启动 TC 服务（推荐使用 Nacos 作为注册中心）

# application.yml
server:
  port: 8091

spring:
  application:
    name: seata-tc

seata:
  config:
    type: nacos
    nacos:
      server-addr: 127.0.0.1:8848
      namespace: public
      group: SEATA_GROUP
      data-id: seata-server.properties

  registry:
    type: nacos
    nacos:
      server-addr: 127.0.0.1:8848
      namespace: public
      group: SEATA_GROUP

2. 数据库初始化（创建 undo_log 表）

CREATE TABLE IF NOT EXISTS `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 DEFAULT CHARSET=utf8;

3. 应用端配置（Spring Boot + MyBatis）

添加依赖：

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-seata</artifactId>
    <version>2021.0.5.0</version>
</dependency>

配置文件：

spring:
  application:
    name: order-service
  datasource:
    url: jdbc:mysql://localhost:3306/order_db?useUnicode=true&characterEncoding=UTF-8&useSSL=false&serverTimezone=UTC
    username: root
    password: 123456
    driver-class-name: com.mysql.cj.jdbc.Driver

seata:
  enabled: true
  service:
    vgroup-mapping:
      my_test_tx_group: default
  client:
    rm:
      report-retry-count: 5
      report-success-enable: false
    tm:
      commit-retry-count: 5
      rollback-retry-count: 5
    undo:
      log-serialization: jackson

2.4 代码示例：使用 @GlobalTransactional 注解

@Service
public class OrderService {

    @Autowired
    private OrderMapper orderMapper;

    @Autowired
    private InventoryService inventoryService;

    @GlobalTransactional(name = "create-order", timeoutMills = 30000, rollbackFor = Exception.class)
    public void createOrder(String userId, String productId, Integer count) {
        // 1. 创建订单
        Order order = new Order();
        order.setUserId(userId);
        order.setProductId(productId);
        order.setCount(count);
        order.setStatus("CREATED");
        orderMapper.insert(order);

        // 2. 扣减库存
        inventoryService.deduct(productId, count);

        // 3. 模拟异常测试
        if (count > 10) {
            throw new RuntimeException("库存不足");
        }
    }
}

🔍 注意事项：

  • @GlobalTransactional 必须作用于方法级别。
  • rollbackFor 明确指定哪些异常触发回滚。
  • 不建议将大事务放在 @GlobalTransactional 中，避免长时间锁资源。

2.5 优缺点分析

优点 缺点
✅ 对业务代码无侵入，只需加注解 ❌ 需要数据库支持 undo_log 表
✅ 自动化回滚，减少手动补偿逻辑 ❌ 只支持 MySQL、Oracle、PostgreSQL 等特定数据库
✅ 性能优于传统两阶段提交（2PC） ❌ 依赖 TC 服务，存在单点故障风险（需集群部署）
✅ 支持嵌套事务 ❌ 不适用于异步调用或消息队列场景

⚠️ 最佳实践建议：

  • 使用 @GlobalTransactional 时，尽量控制事务范围，避免跨多个远程调用。
  • 在高并发场景下，考虑使用 @Transactional + 本地事务 + 消息队列异步处理替代。
  • 建议 TC 服务使用 Nacos 或 Eureka 进行注册发现，并启用 HA 集群部署。

三、Saga 模式：基于事件驱动的长事务管理

3.1 Saga 模式基本思想

Saga 模式是一种补偿型事务模型，特别适用于长周期、多步骤的业务流程。它的核心理念是：不阻塞整个事务，而是通过“正向操作 + 补偿操作”来维持最终一致性。

Saga 分为两种实现方式：

  • Choreography（编排式）：各服务通过事件通信，自行决定下一步动作。
  • Orchestration（编排式）：由一个中心化的协调者（Orchestrator）控制流程。

我们以 Orchestration 模式 为例进行讲解。

3.2 工作流程

  1. 启动 Saga 流程：协调者接收请求，开始执行第一步。
  2. 执行本地操作：每个服务执行自己的业务逻辑，并发布一个“成功事件”。
  3. 监听事件：协调者监听事件，决定是否进入下一步。
  4. 失败处理：一旦某一步失败，协调者触发一系列逆向补偿操作（Compensation Actions），回滚前面已完成的操作。
  5. 最终一致：所有补偿完成后，系统达成一致状态。

3.3 实际案例：电商平台订单流程

假设订单流程如下：

  1. 创建订单（Order Service）
  2. 扣减库存（Inventory Service）
  3. 发起支付（Payment Service）
  4. 发货（Shipping Service）

若在第3步支付失败，则需要执行以下补偿操作：

  • 回滚支付 → 退款
  • 回滚库存 → 恢复库存
  • 回滚订单 → 删除订单

3.4 代码示例（基于 Spring + Kafka + 状态机）

1. 定义 Saga 事件

public enum OrderEvent {
    ORDER_CREATED,
    INVENTORY_Deducted,
    PAYMENT_SUCCESS,
    PAYMENT_FAILED,
    SHIPMENT_SENT,
    COMPENSATION_STARTED,
    COMPENSATION_COMPLETED
}

2. 创建 Saga 协调器

@Service
public class OrderSagaCoordinator {

    @Autowired
    private KafkaTemplate<String, Object> kafkaTemplate;

    @Autowired
    private OrderService orderService;

    @Autowired
    private InventoryService inventoryService;

    @Autowired
    private PaymentService paymentService;

    @Autowired
    private ShippingService shippingService;

    public void startOrderProcess(String orderId, String userId, String productId, Integer count) {
        try {
            // Step 1: 创建订单
            orderService.createOrder(orderId, userId, productId, count);
            publishEvent(OrderEvent.ORDER_CREATED, orderId);

            // Step 2: 扣减库存
            inventoryService.deduct(productId, count);
            publishEvent(OrderEvent.INVENTORY_Deducted, orderId);

            // Step 3: 发起支付
            boolean paymentSuccess = paymentService.charge(orderId, count * 100);
            if (!paymentSuccess) {
                throw new BusinessException("支付失败");
            }
            publishEvent(OrderEvent.PAYMENT_SUCCESS, orderId);

            // Step 4: 发货
            shippingService.ship(orderId);
            publishEvent(OrderEvent.SHIPMENT_SENT, orderId);

        } catch (Exception e) {
            // 触发补偿流程
            handleCompensation(orderId);
        }
    }

    private void handleCompensation(String orderId) {
        // 逆序执行补偿操作
        try {
            shippingService.cancelShipment(orderId); // 取消发货
            paymentService.refund(orderId);          // 退款
            inventoryService.restore(productId, count); // 恢复库存
            orderService.deleteOrder(orderId);       // 删除订单
        } catch (Exception ex) {
            log.error("补偿失败，订单ID={}", orderId, ex);
        }

        publishEvent(OrderEvent.COMPENSATION_COMPLETED, orderId);
    }

    private void publishEvent(OrderEvent event, String orderId) {
        kafkaTemplate.send("order-event-topic", Map.of(
            "eventId", event.name(),
            "orderId", orderId,
            "timestamp", System.currentTimeMillis()
        ));
    }
}

3. 消费者监听事件并执行相应操作

@Component
public class OrderEventHandler {

    @KafkaListener(topics = "order-event-topic", groupId = "order-saga-group")
    public void handleEvent(Map<String, Object> eventMap) {
        String eventId = (String) eventMap.get("eventId");
        String orderId = (String) eventMap.get("orderId");

        switch (OrderEvent.valueOf(eventId)) {
            case PAYMENT_FAILED:
                // 触发补偿
                orderSagaCoordinator.handleCompensation(orderId);
                break;
            case INVENTORY_Deducted:
                // 可用于监控或日志记录
                log.info("库存已扣除，订单ID={}", orderId);
                break;
            default:
                break;
        }
    }
}

3.5 优缺点分析

优点 缺点
✅ 适用于长事务、异步流程 ❌ 逻辑复杂，需要编写大量补偿逻辑
✅ 高可用性强，服务间松耦合 ❌ 无法保证实时一致性，存在中间状态
✅ 易于扩展，支持任意数量步骤 ❌ 补偿操作必须幂等，否则可能导致重复补偿
✅ 适合事件驱动架构 ❌ 依赖消息中间件，增加系统复杂度

✅ 最佳实践建议：

  • 所有补偿操作必须实现幂等性（Idempotency），防止重复执行导致错误。
  • 使用唯一标识（如 transactionId）追踪每个 Saga 流程。
  • 结合数据库状态字段（如 status）判断是否已执行过补偿。
  • 建议使用 @Transactional 保证本地操作的原子性。

四、TCC 模式：两阶段提交的显式控制

4.1 TCC 模式定义

TCC 是一种基于接口契约的分布式事务模式，全称是 Try-Confirm-Cancel。它将一个分布式事务划分为三个阶段：

  • Try：尝试执行业务资源预留（如冻结金额、锁定库存）。
  • Confirm：确认执行，真正完成业务操作。
  • Cancel：取消执行，释放预留资源。

TCC 模式要求服务提供者实现这三个接口，由事务协调器统一调度。

4.2 工作流程

  1. Try 阶段：
    • 各服务尝试执行资源预留（不提交事务）。
    • 成功则返回 true，失败返回 false。
  2. Confirm 阶段：
    • 所有服务 Try 成功后，协调器调用 Confirm 接口。
    • 正式执行业务，提交事务。
  3. Cancel 阶段：
    • 任一服务 Try 失败，协调器调用 Cancel 接口。
    • 释放预留资源，避免资源浪费。

4.3 代码示例：TCC 模式实现

1. 定义 TCC 接口

public interface TccService {
    boolean tryLock(String resourceId, int amount);
    boolean confirm(String resourceId, int amount);
    boolean cancel(String resourceId, int amount);
}

2. 实现库存服务（TCC 接口）

@Service
public class InventoryTccServiceImpl implements TccService {

    @Autowired
    private InventoryMapper inventoryMapper;

    @Override
    public boolean tryLock(String productId, int count) {
        // 查询当前库存
        Inventory inventory = inventoryMapper.selectByProductId(productId);
        if (inventory == null || inventory.getStock() < count) {
            return false; // 库存不足
        }

        // 冻结库存（预留）
        inventory.setFrozenStock(inventory.getFrozenStock() + count);
        inventoryMapper.update(inventory);

        return true;
    }

    @Override
    public boolean confirm(String productId, int count) {
        // 正式扣减库存
        Inventory inventory = inventoryMapper.selectByProductId(productId);
        if (inventory == null) return false;

        inventory.setStock(inventory.getStock() - count);
        inventory.setFrozenStock(inventory.getFrozenStock() - count);
        inventoryMapper.update(inventory);

        return true;
    }

    @Override
    public boolean cancel(String productId, int count) {
        // 释放冻结库存
        Inventory inventory = inventoryMapper.selectByProductId(productId);
        if (inventory == null) return false;

        inventory.setFrozenStock(inventory.getFrozenStock() - count);
        inventoryMapper.update(inventory);

        return true;
    }
}

3. 协调器实现（伪代码）

@Component
public class TccTransactionManager {

    @Autowired
    private InventoryTccServiceImpl inventoryService;

    @Autowired
    private PaymentTccServiceImpl paymentService;

    public boolean executeTccTransaction(String orderId, String productId, int count) {
        boolean trySuccess = true;

        // Step 1: Try
        trySuccess &= inventoryService.tryLock(productId, count);
        trySuccess &= paymentService.tryLock(orderId, count * 100);

        if (!trySuccess) {
            // 如果 Try 失败，立即 Cancel
            inventoryService.cancel(productId, count);
            paymentService.cancel(orderId, count * 100);
            return false;
        }

        // Step 2: Confirm
        boolean confirmSuccess = true;
        confirmSuccess &= inventoryService.confirm(productId, count);
        confirmSuccess &= paymentService.confirm(orderId, count * 100);

        if (!confirmSuccess) {
            // Confirm 失败，触发 Cancel
            inventoryService.cancel(productId, count);
            paymentService.cancel(orderId, count * 100);
            return false;
        }

        return true;
    }
}

4.4 优缺点分析

优点 缺点
✅ 事务粒度细，性能高 ❌ 业务代码侵入严重，需手动实现 Try/Confirm/Cancel
✅ 支持异步调用 ❌ 实现复杂，容易出错
✅ 适合高并发、高频交易场景 ❌ 无法自动处理异常，需自定义重试机制
✅ 无中间状态，更安全 ❌ 需要保证 Confirm 和 Cancel 的幂等性

✅ 最佳实践建议：

  • 所有 TCC 接口必须保证幂等性。
  • 使用 @Transactional 保证本地事务。
  • 加入定时任务扫描未完成的 TCC 事务，进行主动补救。
  • 使用 Redis 或数据库记录事务状态（如 tcc_transaction 表），避免重复执行。

五、三种模式深度对比与选型建议

维度 Seata（AT） Saga 模式 TCC 模式
侵入性 低（仅需注解） 中（需事件驱动） 高（需实现接口）
实现复杂度 低 中高 高
性能 较高 高 最高
一致性 强（最终一致性） 最终一致性 最终一致性
适用场景 中短事务、同步调用 长流程、异步流程 高并发、关键业务
容错能力 一般（依赖 TC） 强（事件驱动） 一般（需手动补偿）
技术栈要求 MySQL/Oracle 等 Kafka/RabbitMQ 自定义协调器

5.1 选型建议

场景 推荐方案
电商下单、转账等短事务 ✅ Seata AT 模式
订单审批、物流跟踪等长流程 ✅ Saga 模式（Orchestration）
支付、抢购、秒杀等高并发场景 ✅ TCC 模式
无法接受强一致性但需可靠补偿 ✅ Saga 模式
业务逻辑简单，希望快速接入 ✅ Seata AT 模式

💡 组合使用建议：

  • 可以在核心链路使用 TCC，外围使用 Saga。
  • Seata 与 Saga 结合：在关键路径使用 Seata，非关键路径使用事件驱动补偿。

六、总结与未来展望

分布式事务是微服务架构中的“必修课”。Seata、Saga 和 TCC 三种模式各有千秋，没有绝对的好坏之分，只有“适不适合”。

  • Seata 适合追求开发效率、对性能要求适中的项目；
  • Saga 适合复杂流程、异步通信的场景；
  • TCC 适合对性能敏感、资源竞争激烈的高并发系统。

未来趋势：

  • 更多平台将集成 分布式事务治理能力（如 Kubernetes Operator + Seata）；
  • AI 驱动的 自动事务分析与优化 将成为可能；
  • 无侵入式事务框架将进一步发展，降低开发门槛。

✅ 最终建议：

  • 优先评估业务需求，明确事务长度、一致性要求、并发压力；
  • 从小规模试点开始，逐步推广；
  • 建立完善的监控与报警机制，确保事务异常可追溯。

📚 参考资料：

  • Seata 官方文档
  • Martin Fowler: Saga Pattern
  • Alibaba Cloud: 《分布式事务解决方案白皮书》
  • DDD & Event Sourcing 相关书籍

本文共计约 6,200 字，涵盖技术原理、代码示例、对比分析与最佳实践，适用于微服务架构师、高级开发工程师进行技术决策参考。

本文来自极简博客，作者：风华绝代，转载请注明原文链接：微服务架构下的分布式事务处理技术预研：Seata、Saga与TCC模式深度对比分析

打赏

本文固定链接: https://www.cxy163.net/archives/7173 | 绝缘体-小明哥的技术博客

该日志由 绝缘体.. 于 2022年01月20日 发表在 kubernetes, mybatis, MySQL, redis, spring, 云计算, 后端框架, 数据库 分类下， 你可以发表评论，并在保留原文地址及作者的情况下引用到你的网站或博客。
原创文章转载请注明: 微服务架构下的分布式事务处理技术预研：Seata、Saga与TCC模式深度对比分析 | 绝缘体-小明哥的技术博客
关键字: , , , ,
【上一篇】
【下一篇】

您可能还会对这些文章感兴趣！

  1. CVE-2022-0543
  2. docker进阶_dockerswarm
  3. docker进阶_docker-compose
  4. docker基础_网络模式
  5. mysql中int(1)是长度为1的int型吗？
  6. laravel 缓存系统的使用
  7. 使用php编程的一些经验总结
  8. sqlmap Tamper脚本编写
  9. mysql 配置ssl ，java应用连接
  10. 蜜罐学习
  11. (转载)Go channel 的妙用
  12. MariaDB/MySQL配置文件my.cnf解读
  13. 如何在 Laravel 代码中正确地使用数据库事务
  14. utf8和utf8mb4的区别
  15. MySQL的语句执行顺序
  16. Mybatis、Mybatis Generator、Mybatis-Plus、

微服务架构下的分布式事务处理技术预研：Seata、Saga与TCC模式深度对比分析：等您坐沙发呢！

发表评论


快捷键：Ctrl+Enter