微服务架构下的分布式事务最佳实践：Saga模式 vs TCC模式深度对比

引言

在微服务架构盛行的今天，企业级应用系统越来越多地采用拆分服务、独立部署的方式进行构建。这种架构虽然带来了开发效率提升、技术栈灵活选择等优势，但也带来了新的挑战——分布式事务管理。

当一个业务操作需要跨越多个服务时，如何保证数据的一致性成为了核心难题。传统的本地事务已无法满足需求，分布式事务解决方案应运而生。本文将深入探讨两种主流的分布式事务处理模式：Saga模式和TCC模式，并通过实际案例分析它们在不同业务场景下的适用性和实现细节。

分布式事务的核心挑战

微服务架构下的事务困境

微服务架构下，业务操作往往需要跨多个服务执行，每个服务都有自己的数据库。传统的ACID事务无法跨越服务边界，这就催生了分布式事务的解决方案。

典型的分布式事务场景包括：

订单创建 → 库存扣减 → 支付处理
用户注册 → 积分发放 → 邮件通知
资金转账 → 账户余额更新 → 交易记录生成

这些场景中的任何一个环节失败，都需要回滚前面已经完成的操作，确保数据一致性。

分布式事务的约束条件

分布式事务需要满足以下核心约束：

原子性：所有操作要么全部成功，要么全部失败
一致性：事务执行前后，系统状态保持一致
隔离性：并发执行的事务互不干扰
持久性：事务提交后数据持久化保存

Saga模式详解

基本原理

Saga模式是一种长事务的解决方案，它将一个大事务拆分为多个小事务，每个小事务都有对应的补偿操作。当某个步骤失败时，通过执行前面已成功步骤的补偿操作来回滚整个业务流程。

订单创建 → 库存扣减 → 支付处理
     ↓         ↓        ↓
   成功    成功    失败
     ↓         ↓        ↓
  补偿1   补偿2   无需补偿

Saga模式的两种实现方式

1. 协议式Saga（Choreography）

在协议式Saga中，每个服务都直接与其他服务交互，通过事件驱动的方式协调事务。

// 订单服务 - 发布订单创建事件
@Component
public class OrderService {
    
    @Autowired
    private EventPublisher eventPublisher;
    
    public void createOrder(OrderRequest request) {
        // 创建订单
        Order order = new Order();
        order.setId(UUID.randomUUID().toString());
        order.setStatus("CREATED");
        
        // 发布订单创建事件
        OrderCreatedEvent event = new OrderCreatedEvent();
        event.setOrderId(order.getId());
        event.setUserId(request.getUserId());
        event.setAmount(request.getAmount());
        eventPublisher.publish(event);
    }
}

// 库存服务 - 订阅订单创建事件
@Component
public class InventoryService {
    
    @EventListener
    public void handleOrderCreated(OrderCreatedEvent event) {
        try {
            // 扣减库存
            inventoryRepository.reduceStock(event.getProductId(), event.getQuantity());
            
            // 发布库存扣减成功事件
            InventoryReducedEvent reducedEvent = new InventoryReducedEvent();
            reducedEvent.setOrderId(event.getOrderId());
            eventPublisher.publish(reducedEvent);
        } catch (Exception e) {
            // 发布库存扣减失败事件
            InventoryReduceFailedEvent failedEvent = new InventoryReduceFailedEvent();
            failedEvent.setOrderId(event.getOrderId());
            eventPublisher.publish(failedEvent);
        }
    }
}

2. 协调式Saga（Orchestration）

在协调式Saga中，通过一个协调器来管理整个事务流程，每个服务只与协调器交互。

// Saga协调器
@Component
public class OrderSagaCoordinator {
    
    private final List<SagaStep> steps = new ArrayList<>();
    
    public void executeOrderProcess(OrderRequest request) {
        SagaContext context = new SagaContext();
        context.setOrderId(UUID.randomUUID().toString());
        
        try {
            // 执行订单创建步骤
            executeStep("create_order", () -> orderService.createOrder(request));
            
            // 执行库存扣减步骤
            executeStep("reduce_inventory", () -> inventoryService.reduceStock(request));
            
            // 执行支付处理步骤
            executeStep("process_payment", () -> paymentService.processPayment(request));
            
        } catch (Exception e) {
            // 回滚所有已执行的步骤
            rollbackSteps(context);
            throw new RuntimeException("Order process failed", e);
        }
    }
    
    private void executeStep(String stepName, Runnable action) {
        try {
            action.run();
            // 记录成功状态
            recordStepSuccess(stepName);
        } catch (Exception e) {
            // 记录失败状态并抛出异常
            recordStepFailure(stepName, e);
            throw e;
        }
    }
    
    private void rollbackSteps(SagaContext context) {
        // 逆序执行补偿操作
        for (int i = steps.size() - 1; i >= 0; i--) {
            steps.get(i).compensate();
        }
    }
}

Saga模式的优势与劣势

优势

实现简单：每个服务只需要关注自己的业务逻辑和补偿操作
可扩展性强：新增服务不影响现有流程
容错性好：单个服务失败不会影响整个事务
异步处理：支持事件驱动的异步处理模式

劣势

补偿逻辑复杂：需要为每个操作设计对应的补偿操作
数据一致性保证：最终一致性，可能在短时间内出现数据不一致
调试困难：分布式环境下问题定位复杂
事务状态管理：需要维护复杂的事务状态机

TCC模式深度解析

核心概念

TCC（Try-Confirm-Cancel）模式是一种补偿性事务模型，它将一个业务操作分为三个阶段：

Try阶段：尝试执行业务操作，预留资源
Confirm阶段：确认执行业务操作，正式提交
Cancel阶段：取消执行业务操作，释放资源

TCC模式实现原理

// TCC服务接口定义
public interface AccountTccService {
    
    /**
     * Try阶段 - 预留资源
     */
    void tryDeduct(String userId, BigDecimal amount);
    
    /**
     * Confirm阶段 - 确认执行
     */
    void confirmDeduct(String userId, BigDecimal amount);
    
    /**
     * Cancel阶段 - 取消执行
     */
    void cancelDeduct(String userId, BigDecimal amount);
}

// 账户服务实现
@Component
public class AccountTccServiceImpl implements AccountTccService {
    
    @Autowired
    private AccountRepository accountRepository;
    
    @Override
    public void tryDeduct(String userId, BigDecimal amount) {
        // 1. 检查余额是否充足
        Account account = accountRepository.findByUserId(userId);
        if (account.getBalance().compareTo(amount) < 0) {
            throw new InsufficientBalanceException("余额不足");
        }
        
        // 2. 预留资金（冻结部分金额）
        BigDecimal reservedAmount = account.getReservedAmount().add(amount);
        account.setReservedAmount(reservedAmount);
        accountRepository.save(account);
        
        // 3. 记录预留状态
        AccountReservation reservation = new AccountReservation();
        reservation.setUserId(userId);
        reservation.setAmount(amount);
        reservation.setStatus("RESERVED");
        reservationRepository.save(reservation);
    }
    
    @Override
    public void confirmDeduct(String userId, BigDecimal amount) {
        // 1. 确认扣减
        Account account = accountRepository.findByUserId(userId);
        account.setBalance(account.getBalance().subtract(amount));
        account.setReservedAmount(account.getReservedAmount().subtract(amount));
        accountRepository.save(account);
        
        // 2. 更新预留状态为已确认
        List<AccountReservation> reservations = reservationRepository.findByUserIdAndStatus(userId, "RESERVED");
        for (AccountReservation reservation : reservations) {
            if (reservation.getAmount().compareTo(amount) == 0) {
                reservation.setStatus("CONFIRMED");
                reservationRepository.save(reservation);
                break;
            }
        }
    }
    
    @Override
    public void cancelDeduct(String userId, BigDecimal amount) {
        // 1. 取消预留
        Account account = accountRepository.findByUserId(userId);
        account.setReservedAmount(account.getReservedAmount().subtract(amount));
        accountRepository.save(account);
        
        // 2. 更新预留状态为已取消
        List<AccountReservation> reservations = reservationRepository.findByUserIdAndStatus(userId, "RESERVED");
        for (AccountReservation reservation : reservations) {
            if (reservation.getAmount().compareTo(amount) == 0) {
                reservation.setStatus("CANCELLED");
                reservationRepository.save(reservation);
                break;
            }
        }
    }
}

// TCC协调器
@Component
public class TccCoordinator {
    
    @Autowired
    private AccountTccService accountTccService;
    
    @Autowired
    private InventoryTccService inventoryTccService;
    
    public void transfer(String fromUserId, String toUserId, BigDecimal amount) {
        try {
            // 1. Try阶段 - 预留资源
            accountTccService.tryDeduct(fromUserId, amount);
            inventoryTccService.tryReserve(toUserId, amount);
            
            // 2. Confirm阶段 - 确认执行
            accountTccService.confirmDeduct(fromUserId, amount);
            inventoryTccService.confirmReserve(toUserId, amount);
            
        } catch (Exception e) {
            // 3. Cancel阶段 - 取消执行
            try {
                accountTccService.cancelDeduct(fromUserId, amount);
                inventoryTccService.cancelReserve(toUserId, amount);
            } catch (Exception cancelException) {
                // 记录取消失败的日志，需要人工介入处理
                log.error("Cancel operation failed", cancelException);
            }
            throw e;
        }
    }
}

TCC模式的特点分析

优势

强一致性：通过三阶段提交保证数据一致性
业务透明：服务提供方需要实现完整的Try-Confirm-Cancel逻辑
性能可控：可以精确控制资源的预留和释放时机
容错性好：失败后有明确的回滚路径

劣势

实现复杂：每个服务都需要实现三个阶段的操作
业务侵入性强：需要修改原有业务逻辑
开发成本高：需要为每个操作编写补偿逻辑
资源锁定时间长：Try阶段会锁定资源，影响并发性能

两种模式的深度对比分析

技术实现复杂度对比

特性	Saga模式	TCC模式
实现难度	相对简单	复杂
业务侵入性	低	高
补偿逻辑复杂度	中等	高
资源管理复杂度	低	中等
状态管理复杂度	中等	高

性能表现分析

Saga模式性能特点

// Saga模式的异步处理优化
@Component
public class AsyncSagaProcessor {
    
    @Autowired
    private TaskExecutor taskExecutor;
    
    public void executeAsyncSaga(List<SagaStep> steps) {
        CompletableFuture<Void> future = CompletableFuture.runAsync(() -> {
            for (SagaStep step : steps) {
                try {
                    // 异步执行步骤
                    step.execute();
                } catch (Exception e) {
                    // 记录错误并继续执行其他步骤
                    log.error("Step execution failed", e);
                }
            }
        }, taskExecutor);
        
        // 可以设置超时处理
        future.orTimeout(30, TimeUnit.SECONDS)
              .exceptionally(throwable -> {
                  log.error("Saga execution timeout or failed", throwable);
                  return null;
              });
    }
}

TCC模式性能特点

// TCC模式的优化策略
@Component
public class OptimizedTccService {
    
    // 使用缓存减少数据库访问
    private final Map<String, Account> accountCache = new ConcurrentHashMap<>();
    
    @Transactional
    public void tryDeductWithOptimization(String userId, BigDecimal amount) {
        // 1. 先从缓存获取账户信息
        Account account = accountCache.get(userId);
        if (account == null) {
            account = accountRepository.findByUserId(userId);
            accountCache.put(userId, account);
        }
        
        // 2. 预留资源
        BigDecimal reservedAmount = account.getReservedAmount().add(amount);
        account.setReservedAmount(reservedAmount);
        
        // 3. 更新数据库
        accountRepository.save(account);
    }
    
    // 定期清理缓存
    @Scheduled(fixedRate = 300000) // 5分钟清理一次
    public void clearCache() {
        accountCache.clear();
    }
}

适用场景分析

Saga模式适用于以下场景：

最终一致性要求：业务对强一致性要求不高，可以接受短暂的数据不一致
复杂业务流程：涉及多个服务的长事务处理
高并发场景：需要良好的并发性能和可扩展性
事件驱动架构：已有完善的事件发布订阅机制

TCC模式适用于以下场景：

强一致性要求：必须保证数据的强一致性
资源锁定需求：需要精确控制资源的预留和释放
金融业务：支付、转账等对数据一致性要求极高的场景
事务补偿明确：每个操作都有清晰的补偿逻辑

实际应用案例分析

电商订单处理系统

系统架构设计

// 订单服务核心代码
@Service
public class OrderService {
    
    @Autowired
    private OrderRepository orderRepository;
    
    @Autowired
    private InventoryService inventoryService;
    
    @Autowired
    private PaymentService paymentService;
    
    // 使用Saga模式处理订单流程
    public String createOrder(OrderRequest request) {
        String orderId = UUID.randomUUID().toString();
        
        try {
            // 1. 创建订单
            Order order = new Order();
            order.setId(orderId);
            order.setUserId(request.getUserId());
            order.setAmount(request.getAmount());
            order.setStatus("PENDING");
            orderRepository.save(order);
            
            // 2. 扣减库存（异步处理）
            inventoryService.reduceStockAsync(orderId, request.getProductId(), request.getQuantity());
            
            // 3. 处理支付（异步处理）
            paymentService.processPaymentAsync(orderId, request.getAmount());
            
            return orderId;
            
        } catch (Exception e) {
            log.error("Order creation failed", e);
            throw new RuntimeException("订单创建失败", e);
        }
    }
    
    // 订单状态更新
    @EventListener
    public void handleOrderStatusUpdate(OrderStatusUpdateEvent event) {
        Order order = orderRepository.findById(event.getOrderId());
        if (order != null) {
            order.setStatus(event.getStatus());
            orderRepository.save(order);
        }
    }
}

完整的Saga流程

// 订单Saga流程管理器
@Component
public class OrderSagaManager {
    
    private static final Logger log = LoggerFactory.getLogger(OrderSagaManager.class);
    
    @Autowired
    private EventPublisher eventPublisher;
    
    @Autowired
    private OrderRepository orderRepository;
    
    @Autowired
    private InventoryService inventoryService;
    
    @Autowired
    private PaymentService paymentService;
    
    public void processOrder(String orderId) {
        SagaContext context = new SagaContext();
        context.setOrderId(orderId);
        
        try {
            // Step 1: 创建订单
            createOrderStep(context);
            
            // Step 2: 扣减库存
            reduceInventoryStep(context);
            
            // Step 3: 处理支付
            processPaymentStep(context);
            
            // Step 4: 更新订单状态
            updateOrderStatusStep(context, "COMPLETED");
            
        } catch (Exception e) {
            log.error("Order processing failed, rolling back", e);
            rollback(context);
            throw new RuntimeException("订单处理失败", e);
        }
    }
    
    private void createOrderStep(SagaContext context) {
        // 创建订单逻辑
        Order order = new Order();
        order.setId(context.getOrderId());
        order.setStatus("CREATED");
        orderRepository.save(order);
        
        // 记录步骤状态
        context.addStepStatus("CREATE_ORDER", "SUCCESS");
    }
    
    private void reduceInventoryStep(SagaContext context) {
        try {
            inventoryService.reduceStock(context.getOrderId(), 10);
            context.addStepStatus("REDUCE_INVENTORY", "SUCCESS");
        } catch (Exception e) {
            context.addStepStatus("REDUCE_INVENTORY", "FAILED");
            throw e;
        }
    }
    
    private void processPaymentStep(SagaContext context) {
        try {
            paymentService.processPayment(context.getOrderId(), new BigDecimal("100.00"));
            context.addStepStatus("PROCESS_PAYMENT", "SUCCESS");
        } catch (Exception e) {
            context.addStepStatus("PROCESS_PAYMENT", "FAILED");
            throw e;
        }
    }
    
    private void updateOrderStatusStep(SagaContext context, String status) {
        Order order = orderRepository.findById(context.getOrderId());
        if (order != null) {
            order.setStatus(status);
            orderRepository.save(order);
        }
    }
    
    private void rollback(SagaContext context) {
        // 按逆序执行补偿操作
        List<String> steps = new ArrayList<>(context.getStepStatus().keySet());
        Collections.reverse(steps);
        
        for (String step : steps) {
            try {
                executeCompensation(step, context);
            } catch (Exception e) {
                log.error("Compensation failed for step: " + step, e);
                // 记录补偿失败，需要人工处理
            }
        }
    }
    
    private void executeCompensation(String stepName, SagaContext context) {
        switch (stepName) {
            case "PROCESS_PAYMENT":
                paymentService.refund(context.getOrderId());
                break;
            case "REDUCE_INVENTORY":
                inventoryService.restoreStock(context.getOrderId(), 10);
                break;
            case "CREATE_ORDER":
                orderRepository.deleteById(context.getOrderId());
                break;
        }
    }
}

金融转账系统

TCC模式实现

// 转账服务TCC实现
@Service
public class TransferTccService {
    
    @Autowired
    private AccountRepository accountRepository;
    
    @Autowired
    private TransactionLogRepository transactionLogRepository;
    
    /**
     * Try阶段 - 预留转账金额
     */
    public void tryTransfer(String fromUserId, String toUserId, BigDecimal amount) {
        // 1. 检查转出账户余额
        Account fromAccount = accountRepository.findByUserId(fromUserId);
        if (fromAccount.getBalance().compareTo(amount) < 0) {
            throw new InsufficientBalanceException("余额不足");
        }
        
        // 2. 预留资金（冻结）
        BigDecimal reservedAmount = fromAccount.getReservedAmount().add(amount);
        fromAccount.setReservedAmount(reservedAmount);
        accountRepository.save(fromAccount);
        
        // 3. 记录转账尝试日志
        TransactionLog log = new TransactionLog();
        log.setTransactionId(UUID.randomUUID().toString());
        log.setFromUserId(fromUserId);
        log.setToUserId(toUserId);
        log.setAmount(amount);
        log.setStatus("TRY");
        transactionLogRepository.save(log);
    }
    
    /**
     * Confirm阶段 - 确认转账
     */
    public void confirmTransfer(String fromUserId, String toUserId, BigDecimal amount) {
        // 1. 执行实际转账
        Account fromAccount = accountRepository.findByUserId(fromUserId);
        Account toAccount = accountRepository.findByUserId(toUserId);
        
        fromAccount.setBalance(fromAccount.getBalance().subtract(amount));
        toAccount.setBalance(toAccount.getBalance().add(amount));
        
        // 2. 更新预留状态
        fromAccount.setReservedAmount(fromAccount.getReservedAmount().subtract(amount));
        
        accountRepository.save(fromAccount);
        accountRepository.save(toAccount);
        
        // 3. 更新转账日志
        TransactionLog log = transactionLogRepository.findByFromUserIdAndToUserIdAndAmount(fromUserId, toUserId, amount);
        if (log != null) {
            log.setStatus("CONFIRM");
            transactionLogRepository.save(log);
        }
    }
    
    /**
     * Cancel阶段 - 取消转账
     */
    public void cancelTransfer(String fromUserId, String toUserId, BigDecimal amount) {
        // 1. 解冻预留资金
        Account fromAccount = accountRepository.findByUserId(fromUserId);
        fromAccount.setReservedAmount(fromAccount.getReservedAmount().subtract(amount));
        accountRepository.save(fromAccount);
        
        // 2. 更新转账日志
        TransactionLog log = transactionLogRepository.findByFromUserIdAndToUserIdAndAmount(fromUserId, toUserId, amount);
        if (log != null) {
            log.setStatus("CANCEL");
            transactionLogRepository.save(log);
        }
    }
    
    /**
     * 转账主流程
     */
    public void transfer(String fromUserId, String toUserId, BigDecimal amount) {
        try {
            // 1. Try阶段
            tryTransfer(fromUserId, toUserId, amount);
            
            // 2. Confirm阶段
            confirmTransfer(fromUserId, toUserId, amount);
            
        } catch (Exception e) {
            // 3. Cancel阶段
            cancelTransfer(fromUserId, toUserId, amount);
            throw new RuntimeException("转账失败", e);
        }
    }
}

最佳实践与优化建议

状态管理策略

// 分布式事务状态管理器
@Component
public class DistributedTransactionStateManager {
    
    private final Map<String, TransactionStatus> transactionStates = new ConcurrentHashMap<>();
    private final ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1);
    
    public void updateTransactionStatus(String transactionId, String status) {
        TransactionStatus state = transactionStates.computeIfAbsent(transactionId, k -> new TransactionStatus());
        state.setStatus(status);
        state.setLastUpdated(new Date());
        
        // 启动定时清理任务
        scheduleCleanup(transactionId);
    }
    
    public TransactionStatus getTransactionStatus(String transactionId) {
        return transactionStates.get(transactionId);
    }
    
    private void scheduleCleanup(String transactionId) {
        scheduler.schedule(() -> {
            TransactionStatus status = transactionStates.get(transactionId);
            if (status != null && 
                System.currentTimeMillis() - status.getLastUpdated().getTime() > 3600000) { // 1小时
                transactionStates.remove(transactionId);
            }
        }, 3600, TimeUnit.SECONDS);
    }
}

// 事务状态实体类
public class TransactionStatus {
    private String status;
    private Date lastUpdated;
    private Map<String, String> stepStatus;
    
    // 构造函数、getter、setter省略
}

异常处理与重试机制

// 带重试机制的分布式事务执行器
@Component
public class RetryableSagaExecutor {
    
    private static final Logger log = LoggerFactory.getLogger(RetryableSagaExecutor.class);
    
    @Autowired
    private RetryTemplate retryTemplate;
    
    public void executeWithRetry(SagaExecutionCallback callback, int maxRetries) {
        retryTemplate.execute(context -> {
            try {
                callback.execute();
                return null;
            } catch (Exception e) {
                log.error("Saga execution failed, attempt: {}", context.getRetryCount(), e);
                if (context.getRetryCount() >= maxRetries) {
                    throw new RuntimeException("Max retries exceeded", e);
                }
                throw e;
            }
        });
    }
    
    // 重试配置
    @Bean
    public RetryTemplate retryTemplate() {
        RetryTemplate template = new RetryTemplate();
        
        // 设置重试策略
        SimpleRetryPolicy retryPolicy = new SimpleRetryPolicy();
        retryPolicy.setMaxAttempts(3);
        template.setRetryPolicy(retryPolicy);
        
        // 设置回退策略
        ExponentialBackOffPolicy backOffPolicy = new ExponentialBackOffPolicy();
        backOffPolicy.setInitialInterval(1000);
        backOffPolicy.setMultiplier(2.0);
        backOffPolicy.setMaxInterval(10000);
        template.setBackOffPolicy(backOffPolicy);
        
        return template;
    }
}

// 回调接口
public interface SagaExecutionCallback {
    void execute() throws Exception;
}

监控与日志

// 分布式事务监控器
@Component
public class DistributedTransactionMonitor {
    
    private static final Logger log = LoggerFactory.getLogger(DistributedTransactionMonitor.class);
    
    @Autowired
    private MeterRegistry meterRegistry;
    
    private final Counter transactionCounter;
    private final Timer transactionTimer;
    
    public DistributedTransactionMonitor(MeterRegistry meterRegistry) {
        this.meterRegistry = meterRegistry;
        this.transactionCounter = Counter.builder("distributed.transactions")
                .description("Number of distributed transactions")
                .register(meterRegistry);
        this.transactionTimer = Timer.builder("distributed.transaction.duration")
                .description("Duration of distributed transactions")
                .register(meterRegistry);
    }
    
    public void recordTransaction(String type, long duration, boolean success) {
        transactionCounter.increment();
        
        // 记录事务持续时间
        transactionTimer.record(duration, TimeUnit.MILLISECONDS);
        
        log.info("Transaction completed - Type: {}, Duration: {}ms, Success: {}", 
                type, duration, success);
    }
}

总结与展望

通过本文的深入分析，我们可以得出以下结论：

选择建议

选择Saga模式当：
- 对强一致性要求不高
- 业务流程复杂，涉及多个服务
- 需要良好的可扩展性和容错性
- 已有完善的事件驱动架构
选择TCC模式当：
- 必须保证强一致性
- 资源锁定和释放需要精确控制
- 金融类业务场景
- 对数据一致性要求极高的场景

未来发展趋势

无锁化事务：随着技术发展，可能会出现更高效的分布式事务解决方案
自动化补偿：通过AI技术实现自动化的补偿逻辑生成
云原生支持：更多云原生平台提供内置的分布式事务支持
标准化规范：行业标准将进一步完善，降低实现复杂度

实施建议

渐进式改造：不要一次性大规模改造，可以逐步引入新的事务处理机制
充分测试：分布式事务场景复杂，需要充分的测试覆盖
监控告警：建立完善的监控体系，及时发现和处理异常情况
文档化：详细记录事务流程和补偿逻辑，便于维护和团队协作

分布式事务管理是微服务架构中的核心挑战之一。通过合理选择和应用Saga模式或TCC模式，结合最佳实践和优化策略，我们可以有效解决复杂的业务场景数据一致性问题，构建高可用、高性能的分布式系统。

在实际项目中，建议根据具体的业务需求、性能要求和团队技术能力来选择合适的分布式事务处理方案，并在实践中不断完善和优化。

微服务架构下的分布式事务最佳实践：Saga模式 vs TCC模式深度对比，解决复杂业务场景的数据一致性难题