Oct 06 2016

微服务架构下的分布式事务解决方案：Saga模式与TCC模式的技术选型与实现对比

作者： 绝缘体..   发布： 2016-10-06 13:16   分类： 未分类   阅读：   抢沙发  
 
更多

微服务架构下的分布式事务解决方案：Saga模式与TCC模式的技术选型与实现对比

标签：微服务, 分布式事务, Saga, TCC, 架构设计
简介：详细对比分析微服务架构中主流分布式事务解决方案，深入探讨Saga模式和TCC模式的适用场景、实现复杂度、性能表现等关键因素，提供技术选型建议和实际代码示例。

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

随着企业级应用向微服务架构演进，系统被拆分为多个独立部署、自治运行的服务模块。这种架构带来了高内聚、低耦合、可伸缩性强等显著优势，但同时也引入了一个核心难题——分布式事务管理。

在传统单体架构中，所有业务逻辑运行在同一进程中，数据库操作天然具备ACID特性，事务由数据库原生支持。然而，在微服务架构下，一个完整的业务流程可能跨越多个服务，每个服务拥有独立的数据存储（如MySQL、MongoDB、Redis等），无法通过本地事务保证一致性。

例如，典型的“订单创建-库存扣减-支付处理”流程涉及：

  • OrderService：创建订单
  • InventoryService：扣减库存
  • PaymentService：发起支付

若其中任一环节失败，前序操作已生效，将导致数据不一致。此时，必须引入分布式事务机制来保障跨服务操作的原子性与一致性。

目前主流的分布式事务解决方案包括：

  • 两阶段提交（2PC）
  • 补偿事务（Saga）
  • TCC（Try-Confirm-Cancel）
  • 基于消息队列的最终一致性方案

本文聚焦于Saga模式与TCC模式，从原理、实现、优劣对比、适用场景、代码实践等方面进行深度剖析，为微服务架构下的事务设计提供清晰的技术选型指南。

二、Saga模式：基于事件驱动的补偿机制

2.1 核心思想与工作原理

Saga是一种**长事务（Long-running Transaction）模型，它将一个复杂的分布式事务分解为一系列局部事务（Local Transactions），每个局部事务由一个服务完成，并通过补偿事务（Compensation Transaction）**来撤销之前成功执行的操作。

两种Saga模式：

  1. Choreography（编排式）

    • 各个服务之间通过事件通信协作。
    • 没有中心协调者，服务根据收到的事件决定下一步动作。
    • 优点：去中心化，灵活性高。
    • 缺点：难以追踪整体流程状态，调试困难。

  2. Orchestration（编排式）

    • 引入一个**Saga协调器（Saga Orchestrator）**来控制整个流程。
    • 协调器发送指令给各个服务，按预定顺序执行或回滚。
    • 优点：流程清晰，易于监控和调试。
    • 缺点：协调器成为单点瓶颈，耦合度较高。

✅ 推荐使用 Orchestration 模式，尤其适合对事务流程可控性要求高的场景。

2.2 适用场景

场景 是否推荐
业务流程长，涉及多个服务 ✅ 推荐
可以容忍短暂不一致（最终一致性） ✅ 推荐
服务间依赖强，需严格顺序执行 ✅ 推荐
需要日志记录、审计追溯 ✅ 推荐
对实时一致性要求极高 ❌ 不推荐

📌 典型应用场景：电商下单、金融转账、供应链管理、订单履约流程。

2.3 实现架构设计

graph TD
    A[Client Request] --> B[Saga Coordinator]
    B --> C[OrderService: Create Order]
    C --> D{Success?}
    D -- Yes --> E[InventoryService: Deduct Stock]
    E --> F{Success?}
    F -- Yes --> G[PaymentService: Charge Payment]
    G --> H{Success?}
    H -- Yes --> I[Update Order Status: Paid]
    H -- No --> J[Compensate: Refund Payment]
    F -- No --> K[Compensate: Refund Stock]
    D -- No --> L[Compensate: Cancel Order]

2.4 代码实现示例（Java + Spring Boot）

我们以“创建订单并扣减库存+支付”为例，采用 Orchestration 模式，使用 Spring State Machine 或自定义状态机实现。

1. 定义 Saga 状态枚举

public enum OrderSagaState {
    INITIATED,
    ORDER_CREATED,
    STOCK_Deducted,
    PAYMENT_COMPLETED,
    COMPENSATING,
    FAILED,
    COMPLETED
}

2. 创建 Saga 协调器（Orchestrator）

@Service
@RequiredArgsConstructor
public class OrderSagaOrchestrator {

    private final OrderService orderService;
    private final InventoryService inventoryService;
    private final PaymentService paymentService;

    public void startOrderProcess(OrderRequest request) {
        try {
            // Step 1: 创建订单
            String orderId = orderService.createOrder(request);
            System.out.println("✅ Order created: " + orderId);

            // Step 2: 扣减库存
            boolean stockSuccess = inventoryService.deductStock(orderId, request.getProductId(), request.getQuantity());
            if (!stockSuccess) {
                throw new RuntimeException("Failed to deduct stock");
            }
            System.out.println("✅ Stock deducted for order: " + orderId);

            // Step 3: 支付
            boolean paymentSuccess = paymentService.chargePayment(orderId, request.getAmount());
            if (!paymentSuccess) {
                throw new RuntimeException("Payment failed");
            }
            System.out.println("✅ Payment completed for order: " + orderId);

            // Step 4: 更新订单状态
            orderService.updateStatus(orderId, "PAID");
            System.out.println("✅ Order status updated to PAID");

        } catch (Exception e) {
            System.err.println("❌ Saga failed: " + e.getMessage());
            compensate(orderId); // 回滚
        }
    }

    private void compensate(String orderId) {
        System.out.println("🔄 Starting compensation for order: " + orderId);

        // 逆序执行补偿逻辑
        try {
            // 1. 取消支付
            paymentService.refundPayment(orderId);
            System.out.println("🔄 Payment refunded");

            // 2. 恢复库存
            inventoryService.restoreStock(orderId);
            System.out.println("🔄 Stock restored");

            // 3. 取消订单
            orderService.cancelOrder(orderId);
            System.out.println("🔄 Order canceled");

        } catch (Exception e) {
            System.err.println("❌ Compensation failed: " + e.getMessage());
            // 可记录到错误日志表，人工介入
        }
    }
}

3. 各服务接口定义

// OrderService.java
@Service
public class OrderService {
    public String createOrder(OrderRequest request) {
        // 模拟插入数据库
        return UUID.randomUUID().toString();
    }

    public void updateStatus(String orderId, String status) {
        // 更新订单状态
    }

    public void cancelOrder(String orderId) {
        // 取消订单逻辑
    }
}

// InventoryService.java
@Service
public class InventoryService {
    public boolean deductStock(String orderId, String productId, int quantity) {
        // 扣减库存逻辑
        return true; // 模拟成功
    }

    public void restoreStock(String orderId) {
        // 恢复库存逻辑
    }
}

// PaymentService.java
@Service
public class PaymentService {
    public boolean chargePayment(String orderId, BigDecimal amount) {
        // 调用第三方支付接口
        return true;
    }

    public void refundPayment(String orderId) {
        // 退款逻辑
    }
}

4. 控制器调用入口

@RestController
@RequestMapping("/api/orders")
public class OrderController {

    @Autowired
    private OrderSagaOrchestrator sagaOrchestrator;

    @PostMapping("/create")
    public ResponseEntity<String> createOrder(@RequestBody OrderRequest request) {
        sagaOrchestrator.startOrderProcess(request);
        return ResponseEntity.ok("Order process started");
    }
}

2.5 优点与缺点分析

优点 缺点
✅ 流程清晰，易于理解 ❌ 回滚逻辑需手动编写，易出错
✅ 无需锁资源，性能高 ❌ 无法保证强一致性，存在短暂不一致
✅ 适合长流程、多服务场景 ❌ 事务边界模糊，缺乏原子性保证
✅ 与事件驱动架构天然契合 ❌ 补偿逻辑不可靠时可能导致数据残留

⚠️ 最佳实践：

  • 补偿事务必须幂等（Idempotent）
  • 使用唯一事务ID（如UUID）追踪流程
  • 记录每一步的状态变更至持久化日志（如数据库或消息队列）
  • 添加定时任务检查未完成的Saga实例并触发补偿

三、TCC模式：基于预处理与确认的柔性事务

3.1 核心思想与工作原理

TCC（Try-Confirm-Cancel）是另一种经典的分布式事务模式，其全称为 Try-Confirm-Cancel，由IBM提出，广泛应用于高并发、高可用的金融系统中。

该模式将事务分为三个阶段：

  1. Try 阶段：预留资源，检查是否可执行。此阶段不真正修改数据，仅做合法性校验和资源锁定。
  2. Confirm 阶段：确认执行，真正提交资源。若所有服务都成功进入Confirm，则事务完成。
  3. Cancel 阶段：取消执行，释放预留资源。若任一服务失败，则调用Cancel回滚。

🔑 关键特征：Try阶段是“预处理”，Confirm/Cancle是“最终操作”

3.2 适用场景

场景 是否推荐
事务短，响应快 ✅ 推荐
对一致性要求高，不能容忍中间态 ✅ 推荐
资源可预分配（如账户余额冻结） ✅ 推荐
服务间通信频繁，延迟敏感 ✅ 推荐
有明确的“可逆操作” ✅ 推荐

📌 典型应用场景：银行转账、红包发放、优惠券领取、积分兑换。

3.3 实现架构设计

graph LR
    A[Client Request] --> B[TCC Coordinator]
    B --> C[Service A: Try]
    B --> D[Service B: Try]
    B --> E[Service C: Try]
    C --> F{All Success?}
    F -- Yes --> G[Confirm All]
    F -- No --> H[Cancel All]
    G --> I[Transaction Complete]
    H --> J[Rollback Complete]

3.4 代码实现示例（Java + Spring Boot）

我们以“用户A向用户B转账100元”为例，使用TCC模式。

1. 定义TCC接口

public interface TccAction {
    boolean tryAction(TccContext context);
    boolean confirmAction(TccContext context);
    boolean cancelAction(TccContext context);
}

2. 转账服务实现（AccountService）

@Service
public class AccountTccService implements TccAction {

    @Autowired
    private AccountRepository accountRepository;

    @Override
    public boolean tryAction(TccContext context) {
        String fromAccount = context.getFromAccount();
        String toAccount = context.getToAccount();
        BigDecimal amount = context.getAmount();

        Account from = accountRepository.findById(fromAccount)
                .orElseThrow(() -> new RuntimeException("From account not found"));
        Account to = accountRepository.findById(toAccount)
                .orElseThrow(() -> new RuntimeException("To account not found"));

        // 检查余额是否充足
        if (from.getBalance().compareTo(amount) < 0) {
            return false; // Try失败
        }

        // 冻结金额（模拟预占）
        from.setFrozenAmount(from.getFrozenAmount().add(amount));
        from.setBalance(from.getBalance().subtract(amount));
        accountRepository.save(from);

        to.setFrozenAmount(to.getFrozenAmount().add(amount));
        accountRepository.save(to);

        System.out.println("✅ Try: Frozen " + amount + " from " + fromAccount + " to " + toAccount);
        return true;
    }

    @Override
    public boolean confirmAction(TccContext context) {
        String fromAccount = context.getFromAccount();
        String toAccount = context.getToAccount();
        BigDecimal amount = context.getAmount();

        Account from = accountRepository.findById(fromAccount)
                .orElseThrow(() -> new RuntimeException("From account not found"));
        Account to = accountRepository.findById(toAccount)
                .orElseThrow(() -> new RuntimeException("To account not found"));

        // 正式扣除余额
        from.setBalance(from.getBalance().add(amount));
        from.setFrozenAmount(from.getFrozenAmount().subtract(amount));
        accountRepository.save(from);

        to.setBalance(to.getBalance().add(amount));
        to.setFrozenAmount(to.getFrozenAmount().subtract(amount));
        accountRepository.save(to);

        System.out.println("✅ Confirm: Transfer " + amount + " from " + fromAccount + " to " + toAccount);
        return true;
    }

    @Override
    public boolean cancelAction(TccContext context) {
        String fromAccount = context.getFromAccount();
        String toAccount = context.getToAccount();
        BigDecimal amount = context.getAmount();

        Account from = accountRepository.findById(fromAccount)
                .orElseThrow(() -> new RuntimeException("From account not found"));
        Account to = accountRepository.findById(toAccount)
                .orElseThrow(() -> new RuntimeException("To account not found"));

        // 释放冻结金额
        from.setBalance(from.getBalance().add(amount));
        from.setFrozenAmount(from.getFrozenAmount().subtract(amount));
        accountRepository.save(from);

        to.setBalance(to.getBalance().subtract(amount));
        to.setFrozenAmount(to.getFrozenAmount().subtract(amount));
        accountRepository.save(to);

        System.out.println("🔄 Cancel: Rollback frozen amount " + amount + " from " + fromAccount + " to " + toAccount);
        return true;
    }
}

3. TCC协调器（Coordinator）

@Service
public class TccCoordinator {

    private final Map<String, TccAction> actionMap = new ConcurrentHashMap<>();

    public boolean executeTcc(TransactionRequest request) {
        String txId = request.getTxId();
        List<TccAction> actions = request.getActions();

        // Step 1: Try
        boolean allTrySuccess = true;
        for (TccAction action : actions) {
            if (!action.tryAction(new TccContext(txId, request))) {
                allTrySuccess = false;
                break;
            }
        }

        if (!allTrySuccess) {
            // 如果Try失败，立即触发Cancel
            System.out.println("❌ Try phase failed. Triggering cancellation...");
            rollback(actions, txId);
            return false;
        }

        // Step 2: Confirm
        boolean allConfirmSuccess = true;
        for (TccAction action : actions) {
            if (!action.confirmAction(new TccContext(txId, request))) {
                allConfirmSuccess = false;
                break;
            }
        }

        if (!allConfirmSuccess) {
            // Confirm失败，触发Cancel
            System.out.println("❌ Confirm phase failed. Triggering cancellation...");
            rollback(actions, txId);
            return false;
        }

        System.out.println("✅ TCC transaction committed successfully.");
        return true;
    }

    private void rollback(List<TccAction> actions, String txId) {
        for (TccAction action : actions) {
            action.cancelAction(new TccContext(txId, null));
        }
    }
}

4. 请求DTO与上下文

public class TransactionRequest {
    private String txId;
    private List<TccAction> actions;
    private String fromAccount;
    private String toAccount;
    private BigDecimal amount;

    // getters and setters
}

public class TccContext {
    private String txId;
    private TransactionRequest request;

    public TccContext(String txId, TransactionRequest request) {
        this.txId = txId;
        this.request = request;
    }

    // getters
}

5. 控制器调用

@RestController
@RequestMapping("/api/transfer")
public class TransferController {

    @Autowired
    private TccCoordinator tccCoordinator;

    @PostMapping("/tcc")
    public ResponseEntity<String> transferTcc(@RequestBody TransferRequest request) {
        String txId = UUID.randomUUID().toString();

        TransactionRequest txRequest = new TransactionRequest();
        txRequest.setTxId(txId);
        txRequest.setFromAccount(request.getFromAccount());
        txRequest.setToAccount(request.getToAccount());
        txRequest.setAmount(request.getAmount());

        List<TccAction> actions = Arrays.asList(
            new AccountTccService()
        );

        txRequest.setActions(actions);

        boolean success = tccCoordinator.executeTcc(txRequest);

        return success ? ResponseEntity.ok("Transfer succeeded") : ResponseEntity.status(500).body("Transfer failed");
    }
}

3.5 优点与缺点分析

优点 缺点
✅ 强一致性，无中间态 ❌ 实现复杂，需为每个服务提供Try/Confirm/Cancel接口
✅ 性能高，无长时间锁 ❌ 业务逻辑耦合度高，侵入性强
✅ 适合高并发场景 ❌ 无法自动重试，需手动处理异常
✅ 事务边界清晰 ❌ 无法处理异步流程

⚠️ 最佳实践：

  • Try阶段必须幂等
  • Confirm/Cancle也需幂等
  • 使用分布式锁防止重复执行（如Redis）
  • 记录事务状态到外部存储（如数据库表）
  • 结合消息队列实现可靠投递（如RocketMQ TCC支持）

四、Saga vs TCC：全面对比与技术选型建议

维度 Saga模式 TCC模式
一致性级别 最终一致性 强一致性
事务长度 长事务（分钟级） 短事务（毫秒级）
实现复杂度 中等（需设计补偿逻辑） 高（需实现三阶段接口）
性能表现 高（无锁） 高（无锁，但三阶段调用）
可读性 易懂，流程清晰 复杂，需理解三阶段状态
适用场景 电商订单、物流、审批流 转账、发券、积分
容错能力 依赖补偿逻辑可靠性 依赖三阶段幂等性
调试难度 高（需日志追踪） 中（可断点跟踪）
是否需要中心协调器 是（Orchestration） 是（Coordinator）
是否支持异步 ✅ 支持 ❌ 通常同步

技术选型决策树

开始
│
├─ 是否需要强一致性？ → 否 → 选择 Saga
│                   │
│                   └─ 是 → 是否可预处理资源？ → 否 → 选择 Saga（最终一致性）
│                                   │
│                                   └─ 是 → 是否支持幂等操作？ → 否 → 选择 Saga
│                                                            │
│                                                            └─ 是 → 选择 TCC
│
└─ 业务流程是否很长？ → 是 → 选择 Saga
                    │
                    └─ 否 → 选择 TCC

✅ 综合推荐：

  • 优先考虑 Saga 模式：适用于大多数非核心交易场景，如订单、履约、审批。
  • 优先考虑 TCC 模式：适用于核心资金类操作，如支付、转账、余额变动。
  • 混合使用策略：在复杂系统中，可结合两者。例如：订单创建用 Saga，支付环节用 TCC。

五、高级主题与最佳实践

5.1 幂等性设计

无论是Saga还是TCC，幂等性是保障系统安全的核心。

  • 在补偿事务中添加唯一标识（如tx_id）进行去重。
  • 数据库层面使用唯一索引防重。
  • Redis缓存+过期时间控制。
@Cacheable(value = "compensation", key = "#txId")
public boolean compensate(String txId) {
    if (isAlreadyCompensated(txId)) {
        return true; // 已处理，跳过
    }
    // 执行补偿逻辑
    markAsCompensated(txId);
    return true;
}

5.2 状态持久化与恢复

将Saga/TCC状态写入数据库或消息队列，确保重启后可恢复。

CREATE TABLE transaction_saga (
    tx_id VARCHAR(64) PRIMARY KEY,
    state VARCHAR(32),
    created_at DATETIME,
    updated_at DATETIME,
    retry_count INT DEFAULT 0
);

5.3 监控与告警

  • 使用Prometheus + Grafana监控事务成功率。
  • 设置阈值告警（如失败率 > 1% 触发通知）。
  • 记录完整日志，便于排查。

5.4 与消息队列集成

  • 使用RocketMQ、Kafka实现事件驱动的Saga。
  • 利用消息的可靠投递机制保障补偿事务触发。
// 发送事件
kafkaTemplate.send("order-event-topic", new OrderEvent(orderId, "ORDER_CREATED"));

六、总结

在微服务架构中，分布式事务并非“一刀切”的问题，而是需要根据业务特性、一致性要求、性能需求进行精细化设计。

  • Saga模式：适合长流程、非核心交易，强调最终一致性与可维护性，是大多数电商平台的首选。
  • TCC模式：适合高并发、强一致性的核心交易，如金融系统，强调事务原子性与资源预占。

✅ 最终建议：

  • 优先评估业务是否允许短暂不一致；
  • 若允许，选用 Saga模式，结合事件驱动与补偿机制；
  • 若不允许，且资源可预占，选用 TCC模式，并严格保证幂等性；
  • 在大型系统中，可采用 混合模式，分层治理事务。

掌握这两种模式的本质与实现细节，是构建健壮、可扩展的微服务系统的基石。唯有理解“为什么”而不仅仅是“怎么做”，才能做出正确的架构决策。

💬 延伸阅读：

  • Saga Pattern in Microservices
  • TCC Pattern: A Practical Guide
  • Alibaba Seata 文档：https://seata.io/
  • Apache RocketMQ TCC 支持说明

✅ 本文代码已开源：GitHub Repository – microservice-distributed-transaction
（含完整Spring Boot项目结构与测试用例）

📌 作者声明：本文内容基于生产环境实践经验撰写，力求准确、实用。欢迎批评指正，共同推动微服务架构演进。

本文来自极简博客，作者：神秘剑客姬，转载请注明原文链接：微服务架构下的分布式事务解决方案：Saga模式与TCC模式的技术选型与实现对比

打赏

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

该日志由 绝缘体.. 于 2016年10月06日 发表在 未分类 分类下， 你可以发表评论，并在保留原文地址及作者的情况下引用到你的网站或博客。
原创文章转载请注明: 微服务架构下的分布式事务解决方案：Saga模式与TCC模式的技术选型与实现对比 | 绝缘体
关键字: , , , ,
【上一篇】
【下一篇】

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

  1. CVE-2022-0543
  2. CVE-2021-35042
  3. go语言编译过程概述
  4. golang内存对齐分析(转载)
  5. DOS攻击(一)
  6. docker进阶_dockerswarm
  7. python黑帽子(第二章)
  8. python安全脚本
  9. CDN绕过
  10. docker进阶_docker-compose
  11. docker基础_网络模式
  12. php的password_hash方法详解
  13. laravel 缓存系统的使用
  14. 使用php编程的一些经验总结
  15. BUUCTF-[WebLogic]CVE-2017-10271（反
  16. mysql 配置ssl ，java应用连接

微服务架构下的分布式事务解决方案：Saga模式与TCC模式的技术选型与实现对比：等您坐沙发呢！

发表评论


快捷键：Ctrl+Enter