Apr 19 2023

微服务架构下的分布式事务解决方案技术预研：Seata、Saga与TCC模式对比分析

作者： 绝缘体..   发布： 2023-04-19 16:55   分类： ios, MySQL, oracle, spring, 后端框架, 数据库, 移动开发   阅读：   抢沙发  
 
更多

微服务架构下的分布式事务解决方案技术预研：Seata、Saga与TCC模式对比分析

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

随着企业数字化转型的深入，微服务架构已成为构建复杂业务系统的核心技术范式。其核心优势在于将大型单体应用拆分为多个独立部署、可独立伸缩的服务模块，从而提升系统的灵活性、可维护性和开发效率。然而，这种“分而治之”的设计理念也带来了新的技术挑战——分布式事务管理。

在传统单体架构中，所有业务逻辑和数据操作都集中在一个数据库实例内，事务的ACID（原子性、一致性、隔离性、持久性）特性可以通过本地事务轻松保障。但在微服务架构中，一个完整的业务流程往往跨越多个服务，每个服务可能拥有独立的数据库或数据存储系统。此时，若某一步骤失败，如何保证整个流程的“要么全部成功，要么全部回滚”？这就是分布式事务要解决的核心问题。

分布式事务的本质与痛点

分布式事务的本质是：跨多个资源管理器（如不同数据库、消息队列、缓存等）的事务操作，必须保持全局一致性。由于网络延迟、节点故障、数据不一致等问题的存在，传统的本地事务机制无法满足这一需求。

常见的分布式事务场景包括：

  • 订单创建与库存扣减：用户下单后需同时更新订单表和扣减库存，若其中任一环节失败，应取消整个流程。
  • 账户转账：从A账户向B账户转账，涉及两个独立的账户服务，必须确保金额转移的原子性。
  • 支付与发货协同：支付成功后触发物流发货，若发货失败，应自动回滚支付状态。

这些场景共同特征是：多个服务之间存在强依赖关系，且对数据一致性要求高。

三大主流解决方案概述

目前业界针对分布式事务提出了多种解决方案，其中最为成熟和广泛采用的是以下三种：

  1. Seata（Simple Extensible Autonomous Transaction Architecture）

    • 基于XA协议改进的二阶段提交（2PC）框架，支持AT（自动补偿）、TCC（Try-Confirm-Cancel）和SAGA模式。
    • 由阿里巴巴开源，具备良好的社区支持和生产级稳定性。

  2. Saga 模式

    • 一种基于事件驱动的长事务处理机制，通过正向操作+补偿机制实现最终一致性。
    • 适用于长时间运行的业务流程，尤其适合金融、电商等高并发场景。

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

    • 一种由开发者显式定义的两阶段提交模型，强调“预留资源”与“确认/取消”逻辑分离。
    • 适合对性能要求高、能接受一定开发成本的场景。

本文将围绕这三种方案展开深度剖析，从原理机制、适用场景、实现复杂度、代码示例、优缺点对比等多个维度进行系统性研究，为企业在微服务架构中选择合适的分布式事务方案提供决策依据。

Seata：轻量级分布式事务中间件

核心原理与架构设计

Seata 是一款开源的分布式事务解决方案，旨在简化微服务环境下跨服务事务的一致性问题。它采用 Client-Server 架构，主要包括以下几个核心组件：

  • TC（Transaction Coordinator）：事务协调者，负责管理全局事务的生命周期，协调各分支事务的提交或回滚。
  • TM（Transaction Manager）：事务管理器，位于应用客户端，负责开启、提交或回滚全局事务。
  • RM（Resource Manager）：资源管理器，对接具体的数据源（如MySQL），负责注册分支事务并执行本地SQL。

Seata 支持三种模式：AT（Automatic Transaction）、TCC 和 SAGA。我们重点介绍 AT 模式，因其最易用、最贴近传统事务使用习惯。

AT 模式详解

AT 模式是 Seata 的默认模式，其核心思想是：通过代理数据源，在执行 SQL 时自动记录前后镜像（before/after image），并在回滚时利用镜像数据自动反向执行 SQL。

工作流程

  1. 全局事务开启：TM 向 TC 发起全局事务请求，获取全局唯一的 XID。
  2. 分支事务注册：每个服务在执行本地事务前，RM 向 TC 注册分支事务，并记录当前数据快照（before image）。
  3. 业务执行：应用执行业务逻辑（如 UPDATE orders SET status = 'paid' WHERE id = ?）。
  4. 数据变更记录：Seata 代理层捕获 SQL 执行前后数据差异，生成 after image 并保存至 undo_log 表。
  5. 全局提交/回滚：
    • 若所有分支事务成功，TM 发送提交请求，TC 通知各 RM 提交事务。
    • 若任一分支失败，TC 触发回滚，RM 读取 undo_log 中的 before image，执行反向 SQL 进行恢复。

✅ 关键优势：无需修改业务代码即可实现自动回滚，对开发者透明。

实践案例：订单与库存同步

假设有一个电商平台，用户下单时需要同时更新订单和扣减库存。以下是使用 Seata AT 模式的完整实现。

1. 环境准备

  • 数据库：MySQL 8.0
  • 服务：order-service 和 inventory-service
  • 依赖引入（Maven）：
<dependency>
    <groupId>io.seata</groupId>
    <artifactId>seata-spring-boot-starter</artifactId>
    <version>1.7.0</version>
</dependency>

2. 配置文件（application.yml）

server:
  port: 8081

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

seata:
  enabled: true
  tx-service-group: my_tx_group
  service:
    vgroup-mapping:
      my_tx_group: default
    grouplist:
      default: 127.0.0.1:8091
  registry:
    type: nacos
    nacos:
      server-addr: 127.0.0.1:8848
      namespace: public
      group: SEATA_GROUP

⚠️ 注意：需提前启动 Nacos 注册中心，并配置好 registry.conf 文件。

3. 创建 Undo Log 表

Seata 要求每个参与事务的数据库都必须创建 undo_log 表：

CREATE TABLE `undo_log` (
  `id` BIGINT NOT NULL AUTO_INCREMENT,
  `branch_id` BIGINT NOT NULL,
  `xid` VARCHAR(100) NOT NULL,
  `context` VARCHAR(128) NOT NULL,
  `rollback_info` LONGBLOB NOT NULL,
  `log_status` INT 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;

4. 服务端代码实现

订单服务（OrderService）
@Service
public class OrderService {

    @Autowired
    private OrderMapper orderMapper;

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

        // 2. 调用库存服务扣减库存
        inventoryClient.deduct(productId, count);

        // 3. 模拟异常测试回滚
        if (count > 5) {
            throw new RuntimeException("库存不足，强制抛异常！");
        }
    }
}
库存服务（InventoryService）
@Service
public class InventoryService {

    @Autowired
    private InventoryMapper inventoryMapper;

    @Transactional(rollbackFor = Exception.class)
    @GlobalTransactional(name = "deduct-inventory", timeoutMills = 30000, rollbackFor = Exception.class)
    public void deduct(Long productId, Integer count) {
        Inventory inventory = inventoryMapper.selectById(productId);
        if (inventory.getStock() < count) {
            throw new RuntimeException("库存不足");
        }

        inventory.setStock(inventory.getStock() - count);
        inventoryMapper.updateById(inventory);
    }
}
调用方接口
@RestController
@RequestMapping("/api/orders")
public class OrderController {

    @Autowired
    private OrderService orderService;

    @PostMapping("/create")
    public String createOrder(@RequestParam Long userId, @RequestParam Long productId, @RequestParam Integer count) {
        try {
            orderService.createOrder(userId, productId, count);
            return "订单创建成功";
        } catch (Exception e) {
            return "订单创建失败：" + e.getMessage();
        }
    }
}

5. 测试验证

  • 正常情况：调用 /api/orders/create?userId=1&productId=1001&count=2 → 成功创建订单并扣减库存。
  • 异常情况：调用 /api/orders/create?userId=1&productId=1001&count=10 → 抛出异常，Seata 自动回滚，订单未创建，库存未减少。

🔍 日志观察：可在 undo_log 表中看到对应的反向 SQL，如 UPDATE inventory SET stock = stock + 10 WHERE id = 1001。

优点与局限性分析

优点 局限
✅ 对业务代码侵入小，仅需添加注解 ❌ 不支持跨库事务（如 Oracle + MySQL）
✅ 自动回滚，无需编写补偿逻辑 ❌ 仅支持 JDBC 数据源，不支持 NoSQL
✅ 支持多数据源、多服务协作 ❌ 存在锁竞争风险，大事务可能导致性能下降
✅ 社区活跃，文档完善 ❌ 需额外部署 TC 服务，增加运维成本

📌 最佳实践建议：

  • 使用连接池（如 HikariCP）以提升性能；
  • 设置合理的超时时间（timeoutMills）避免长时间阻塞；
  • 在关键路径上启用 @GlobalTransactional，避免误用导致性能瓶颈。

Saga 模式：事件驱动的长事务处理

基本思想与适用场景

Saga 模式是一种用于处理长时间运行的分布式事务的解决方案，其核心思想是：将一个长事务分解为一系列本地事务，每个本地事务完成后发布一个事件，后续步骤监听该事件并执行下一步操作；若某步失败，则触发一系列补偿事件来撤销之前的操作。

🔄 本质：最终一致性（Eventual Consistency），而非强一致性。

两种实现方式

  1. Choreography（编排型）

    • 各服务自行监听事件，决定下一步动作。
    • 无中心协调器，松耦合但难以调试。

  2. Orchestration（编排型）

    • 由一个中心化的协调器（如 Workflow Engine）控制流程。
    • 易于管理和监控，但引入单点故障风险。

实现架构图

[Client]
   ↓
[Workflow Engine] ←→ [Event Bus / Kafka]
   ↓           ↓
[Order Service]  [Inventory Service]
   ↓           ↓
[Payment Service]  [Shipping Service]

代码示例：电商下单流程

1. 事件定义

public class OrderCreatedEvent {
    private Long orderId;
    private Long userId;
    private List<OrderItem> items;
    // getter/setter
}

public class StockDeductedEvent {
    private Long orderId;
    private Long productId;
    private Integer count;
    // getter/setter
}

public class PaymentConfirmedEvent {
    private Long orderId;
    private BigDecimal amount;
    // getter/setter
}

public class ShippingScheduledEvent {
    private Long orderId;
    private String address;
    // getter/setter
}

2. 服务实现

订单服务（OrderService）
@Service
public class OrderService {

    @Autowired
    private OrderRepository orderRepo;

    @Autowired
    private EventPublisher eventPublisher;

    @Transactional
    public void createOrder(OrderCreateRequest request) {
        Order order = new Order();
        order.setUserId(request.getUserId());
        order.setItems(request.getItems());
        order.setStatus("CREATED");
        orderRepo.save(order);

        // 发布事件
        eventPublisher.publish(new OrderCreatedEvent(order.getId(), request.getUserId(), request.getItems()));
    }
}
库存服务（InventoryService）
@Service
public class InventoryService {

    @Autowired
    private InventoryRepository inventoryRepo;

    @Autowired
    private EventPublisher eventPublisher;

    @EventListener
    public void handleStockDeductEvent(StockDeductedEvent event) {
        Inventory inventory = inventoryRepo.findById(event.getProductId()).orElseThrow();
        if (inventory.getStock() < event.getCount()) {
            // 发布补偿事件
            eventPublisher.publish(new StockRedoEvent(event.getOrderId(), event.getProductId(), event.getCount()));
            throw new BusinessException("库存不足");
        }

        inventory.setStock(inventory.getStock() - event.getCount());
        inventoryRepo.save(inventory);

        // 成功后发布下一个事件
        eventPublisher.publish(new PaymentRequiredEvent(event.getOrderId()));
    }

    // 补偿方法
    @EventListener
    public void handleStockRedoEvent(StockRedoEvent event) {
        Inventory inventory = inventoryRepo.findById(event.getProductId()).orElseThrow();
        inventory.setStock(inventory.getStock() + event.getCount());
        inventoryRepo.save(inventory);
    }
}
支付服务（PaymentService）
@Service
public class PaymentService {

    @Autowired
    private PaymentRepository paymentRepo;

    @Autowired
    private EventPublisher eventPublisher;

    @EventListener
    public void handlePaymentRequiredEvent(PaymentRequiredEvent event) {
        // 模拟支付流程
        Payment payment = new Payment();
        payment.setOrderId(event.getOrderId());
        payment.setAmount(calculateTotal(event.getOrderId()));
        payment.setStatus("PENDING");

        paymentRepo.save(payment);

        // 模拟支付成功
        try {
            Thread.sleep(2000); // 模拟异步支付
            payment.setStatus("SUCCESS");
            paymentRepo.save(payment);

            eventPublisher.publish(new PaymentConfirmedEvent(event.getOrderId(), payment.getAmount()));
        } catch (InterruptedException e) {
            payment.setStatus("FAILED");
            paymentRepo.save(payment);
            eventPublisher.publish(new PaymentFailedEvent(event.getOrderId()));
        }
    }

    @EventListener
    public void handlePaymentFailedEvent(PaymentFailedEvent event) {
        // 触发补偿：退回库存
        eventPublisher.publish(new StockRedoEvent(event.getOrderId(), /* productId */, /* count */));
    }
}
物流服务（ShippingService）
@Service
public class ShippingService {

    @Autowired
    private ShippingRepository shippingRepo;

    @Autowired
    private EventPublisher eventPublisher;

    @EventListener
    public void handleShippingScheduledEvent(ShippingScheduledEvent event) {
        Shipping shipping = new Shipping();
        shipping.setOrderId(event.getOrderId());
        shipping.setAddress(event.getAddress());
        shipping.setStatus("SCHEDULED");
        shippingRepo.save(shipping);
    }

    @EventListener
    public void handlePaymentFailedEvent(PaymentFailedEvent event) {
        // 未支付则不发货
        System.out.println("支付失败，取消发货任务");
    }
}

优点与局限性分析

优点 局限
✅ 适合长事务、高并发场景 ❌ 逻辑分散，调试困难
✅ 服务间松耦合，可独立部署 ❌ 补偿逻辑需手动编写，易出错
✅ 无锁机制，性能表现优异 ❌ 不保证强一致性，可能出现短暂不一致
✅ 易于扩展，支持复杂流程 ❌ 需要强大的事件总线支持（如 Kafka）

📌 最佳实践建议：

  • 使用 Kafka 或 RabbitMQ 作为事件总线；
  • 为每个事件添加唯一 ID 和版本号，防止重复消费；
  • 实现幂等性处理，避免事件重复触发；
  • 引入可观测性工具（如 ELK、Prometheus）监控事件链路。

TCC 模式：显式两阶段提交

原理与核心思想

TCC 模式（Try-Confirm-Cancel）是一种由开发者显式定义的分布式事务模型，强调“预留资源”与“确认/取消”逻辑分离。其工作流程如下：

  1. Try 阶段：尝试执行业务操作，预留所需资源（如锁定库存、冻结资金），但不真正提交。
  2. Confirm 阶段：所有服务的 Try 成功后，正式执行业务操作（如扣除库存、生成订单）。
  3. Cancel 阶段：任一服务的 Try 失败，触发 Cancel 操作，释放已预留的资源。

💡 关键点：Try 是非阻塞的，Confirm 和 Cancel 必须幂等。

适用场景

  • 对一致性要求高，且能接受开发成本；
  • 业务逻辑复杂，需精细化控制资源状态；
  • 高并发、低延迟场景（如秒杀、抢购）。

代码示例：TCC 实现订单与库存

1. 定义 TCC 接口

public interface OrderTccService {
    boolean tryCreateOrder(Long orderId, Long productId, Integer count);
    void confirmCreateOrder(Long orderId);
    void cancelCreateOrder(Long orderId);
}

2. 服务实现

订单服务
@Service
public class OrderTccServiceImpl implements OrderTccService {

    @Autowired
    private OrderMapper orderMapper;

    @Autowired
    private TccTransactionManager tccTxManager;

    @Override
    public boolean tryCreateOrder(Long orderId, Long productId, Integer count) {
        // 1. 检查库存是否足够
        Inventory inventory = inventoryMapper.selectById(productId);
        if (inventory.getStock() < count) {
            return false; // Try 失败
        }

        // 2. 预留订单状态
        Order order = new Order();
        order.setId(orderId);
        order.setProductId(productId);
        order.setCount(count);
        order.setStatus("TRYING"); // 临时状态
        orderMapper.insert(order);

        // 3. 记录事务信息（交给 TCC 框架管理）
        tccTxManager.registerBranch("order", orderId, "try");

        return true;
    }

    @Override
    public void confirmCreateOrder(Long orderId) {
        Order order = orderMapper.selectById(orderId);
        order.setStatus("CONFIRMED");
        orderMapper.updateById(order);
    }

    @Override
    public void cancelCreateOrder(Long orderId) {
        Order order = orderMapper.selectById(orderId);
        order.setStatus("CANCELLED");
        orderMapper.updateById(order);
    }
}
库存服务
@Service
public class InventoryTccServiceImpl implements InventoryTccService {

    @Autowired
    private InventoryMapper inventoryMapper;

    @Autowired
    private TccTransactionManager tccTxManager;

    @Override
    public boolean tryDeduct(Long productId, Integer count) {
        Inventory inventory = inventoryMapper.selectById(productId);
        if (inventory.getStock() < count) {
            return false;
        }

        // 预留库存：设置为负数表示已锁定
        inventory.setStock(inventory.getStock() - count);
        inventoryMapper.updateById(inventory);

        tccTxManager.registerBranch("inventory", productId, "try");

        return true;
    }

    @Override
    public void confirmDeduct(Long productId) {
        // 正式扣减库存（已完成）
    }

    @Override
    public void cancelDeduct(Long productId) {
        Inventory inventory = inventoryMapper.selectById(productId);
        inventory.setStock(inventory.getStock() + 1); // 回退
        inventoryMapper.updateById(inventory);
    }
}

3. 调用流程

@RestController
public class TccOrderController {

    @Autowired
    private OrderTccService orderTccService;

    @Autowired
    private InventoryTccService inventoryTccService;

    @PostMapping("/tcc/create")
    public String createTccOrder(@RequestParam Long userId, @RequestParam Long productId, @RequestParam Integer count) {
        Long orderId = System.currentTimeMillis();

        boolean orderTry = orderTccService.tryCreateOrder(orderId, productId, count);
        boolean inventoryTry = inventoryTccService.tryDeduct(productId, count);

        if (!orderTry || !inventoryTry) {
            // 任一失败，立即触发 Cancel
            orderTccService.cancelCreateOrder(orderId);
            inventoryTccService.cancelDeduct(productId);
            return "创建失败";
        }

        // 两个 Try 都成功，进入 Confirm
        orderTccService.confirmCreateOrder(orderId);
        inventoryTccService.confirmDeduct(productId);

        return "创建成功";
    }
}

优点与局限性分析

优点 局限
✅ 一致性强，可精确控制资源状态 ❌ 开发成本高，需编写大量业务逻辑
✅ 无锁，性能优异 ❌ 事务边界清晰，难以灵活调整
✅ 适合复杂业务流程 ❌ 易出错，需严格测试补偿逻辑
✅ 可结合本地事务使用 ❌ 缺乏统一框架支持（相比 Seata）

📌 最佳实践建议：

  • 所有 Confirm 和 Cancel 方法必须幂等；
  • 使用分布式锁防止重复执行；
  • 加入日志记录与重试机制；
  • 采用 @Transactional 保护本地事务。

三者对比总结与选型建议

维度 Seata（AT） Saga 模式 TCC 模式
一致性 强一致性（2PC） 最终一致性 强一致性
侵入性 低（仅加注解） 中（需事件驱动） 高（需实现接口）
开发成本 低 中 高
性能 中等（有锁） 高（无锁） 极高（无锁）
可靠性 高（成熟框架） 依赖事件总线 依赖补偿逻辑
适用场景 短事务、通用业务 长流程、高并发 高性能、强一致
是否推荐 ✅ 推荐（初学者首选） ✅ 推荐（复杂流程） ✅ 推荐（性能优先）

选型决策树

是否需要强一致性？
├── 是 → 是否能接受开发成本？
│     ├── 是 → 选择 TCC
│     └── 否 → 选择 Seata AT
└── 否 → 是否为长事务？
      ├── 是 → 选择 Saga
      └── 否 → 选择 Seata AT

最佳实践汇总

  1. 优先选用 Seata AT 模式：对于大多数中小型项目，它是最佳起点。
  2. 复杂流程用 Saga：如供应链、审批流、订单全生命周期管理。
  3. 高并发场景用 TCC：如秒杀、抢购、金融交易。
  4. 统一日志与监控：无论哪种模式，都应接入链路追踪（如 SkyWalking）和日志系统。
  5. 测试补偿逻辑：特别是 Saga 和 TCC，必须模拟失败场景验证回滚能力。

结语：走向更可靠的分布式系统

分布式事务并非“银弹”，而是权衡的结果。Seata、Saga 和 TCC 各有千秋，没有绝对最优解。企业在选型时应结合自身业务特点、团队能力、性能要求与运维水平综合判断。

未来趋势显示，事件驱动架构 + Saga 模式将成为主流，尤其是在云原生和 Serverless 场景下。而 Seata 仍将是多数企业的首选，尤其在快速迭代的 SaaS 产品中。

🌟 记住：好的分布式事务设计，不是追求完美一致性，而是构建可容忍错误、可恢复、可观测的系统。

通过深入理解这三种模式的技术细节与实际应用场景，我们不仅能解决当前的问题，更能为未来的系统演进打下坚实基础。

本文来自极简博客，作者：深海探险家，转载请注明原文链接：微服务架构下的分布式事务解决方案技术预研：Seata、Saga与TCC模式对比分析

打赏

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

该日志由 绝缘体.. 于 2023年04月19日 发表在 ios, MySQL, oracle, spring, 后端框架, 数据库, 移动开发 分类下， 你可以发表评论，并在保留原文地址及作者的情况下引用到你的网站或博客。
原创文章转载请注明: 微服务架构下的分布式事务解决方案技术预研：Seata、Saga与TCC模式对比分析 | 绝缘体-小明哥的技术博客
关键字: , , , ,
【上一篇】
【下一篇】

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

  1. mysql中int(1)是长度为1的int型吗？
  2. 使用php编程的一些经验总结
  3. sqlmap Tamper脚本编写
  4. BUUCTF-[WebLogic]CVE-2018-2894（任意
  5. BUUCTF-[WebLogic]CVE-2017-10271（反
  6. mysql 配置ssl ，java应用连接
  7. 蜜罐学习
  8. MariaDB/MySQL配置文件my.cnf解读
  9. 如何在 Laravel 代码中正确地使用数据库事务
  10. utf8和utf8mb4的区别
  11. MySQL的语句执行顺序
  12. CentOS 上部署达梦数据库
  13. 使用Spring Boot Actuator实现应用监控
  14. 程序开发中的自动化运维工具推荐
  15. Java 21虚拟线程性能优化实测：对比传统线程模型
  16. Spring Boot快速入门与实践

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

发表评论


快捷键：Ctrl+Enter