分布式事务决策框架：从 2PC 到 Saga 的方案对比与工程实践-开发者社区

分布式事务决策框架：从 2PC 到 Saga 的方案对比与工程实践

系统从单体迁移到微服务后，订单服务、库存服务、支付服务、通知服务需要同时成功或同时失败。这时候，分布式事务成了绕不开的难题。2PC、TCC、Saga、本地消息表……方案很多，但每个方案都有其适用场景和代价。选择错误的方案，可能导致性能瓶颈、数据不一致、甚至系统崩溃。分布式事务不是"用哪种方案"的简单题，而是需要深入理解业务需求、技术约束、团队能力的系统性决策。

二、分布式事务的核心挑战与解决方案分类

分布式事务的核心挑战是网络分区、节点故障、数据不一致。CAP 定理告诉我们，分布式系统无法同时满足一致性、可用性、分区容错性。分布式事务的解决方案，本质上是在这三个属性之间做权衡。

graph TB A[分布式事务解决方案] --> B[强一致性<br/>2PC/3PC] A --> C[最终一致性<br/>Saga/TCC] A --> D[最大努力通知<br/>本地消息表] A --> E[无事务<br/>补偿机制] B --> B1[优点: 强一致<br/>缺点: 性能差/单点] C --> C1[优点: 性能好/无单点<br/>缺点: 复杂度高] D --> D1[优点: 简单/可扩展<br/>缺点: 一致性弱] E --> E1[优点: 最简单<br/>缺点: 需要业务补偿] style B fill:#ffebee style C fill:#e8f5e9 style D fill:#fff3e0

**2PC（两阶段提交）**是最经典的强一致性方案。它通过协调者（Coordinator）统一提交或回滚所有参与者（Participant）。

准备阶段（Prepare）：协调者询问所有参与者是否可以提交。
提交阶段（Commit）：如果所有参与者都同意，协调者通知所有参与者提交；否则回滚。

2PC 的问题：

同步阻塞：所有参与者锁定资源，等待协调者决策。
单点故障：协调者宕机，整个事务阻塞。
数据不一致：协调者在提交阶段宕机，部分参与者已提交，部分未提交。

**3PC（三阶段提交）**在 2PC 基础上引入超时机制和 CanCommit 阶段，减少阻塞时间，但仍无法完全解决单点故障。

**TCC（Try-Confirm-Cancel）**是业务层面的分布式事务。

Try 阶段：预留资源（如冻结库存）。
Confirm 阶段：确认执行（如扣减库存）。
Cancel 阶段：取消执行（如解冻库存）。

TCC 的优点：性能好（无全局锁）；缺点：业务侵入性强，需要实现三个接口，且必须幂等。

Saga 模式将分布式事务拆分为一系列本地事务，每个本地事务有对应的补偿事务。

编排（Choreography）：各服务通过事件驱动，无需中心协调者。
编制（Orchestration）：由中心协调器统一调度。

Saga 的优点：性能好、无单点；缺点：补偿逻辑复杂，且只能保证最终一致性。

本地消息表通过本地事务 + 消息队列实现最终一致性。

业务操作和消息发送放在同一个本地事务中。
消息队列异步投递给下游服务。
下游服务幂等消费。

优点：简单、可靠；缺点：一致性较弱（消息可能丢失或重复）。

三、Saga 模式的生产级实现

Saga 模式是微服务架构中最实用的分布式事务方案。以下是一个基于编制的 Saga 实现：

Saga 协调器

// Saga 状态机 public enum SagaState { STARTED, ORDER_CREATED, INVENTORY_RESERVED, PAYMENT_PROCESSED, NOTIFICATION_SENT, COMPLETED, FAILED, COMPENSATING } // Saga 执行器 @Service public class OrderSagaOrchestrator { @Autowired private SagaStateRepository stateRepository; @Autowired private EventPublisher eventPublisher; @Transactional public void executeSaga(OrderRequest request) { String sagaId = UUID.randomUUID().toString(); SagaStateMachine stateMachine = new SagaStateMachine(sagaId); stateRepository.save(stateMachine); try { // 步骤1: 创建订单 eventPublisher.publish(new CreateOrderCommand(sagaId, request)); stateMachine.transitionTo(SagaState.ORDER_CREATED); // 步骤2: 冻结库存 eventPublisher.publish(new ReserveInventoryCommand(sagaId, request)); stateMachine.transitionTo(SagaState.INVENTORY_RESERVED); // 步骤3: 处理支付 eventPublisher.publish(new ProcessPaymentCommand(sagaId, request)); stateMachine.transitionTo(SagaState.PAYMENT_PROCESSED); // 步骤4: 发送通知 eventPublisher.publish(new SendNotificationCommand(sagaId, request)); stateMachine.transitionTo(SagaState.NOTIFICATION_SENT); stateMachine.transitionTo(SagaState.COMPLETED); } catch (Exception e) { // 执行补偿事务 compensate(sagaId, stateMachine.getCurrentState()); stateMachine.transitionTo(SagaState.FAILED); } stateRepository.save(stateMachine); } private void compensate(String sagaId, SagaState failedAt) { log.info("开始补偿事务，sagaId: {}, failedAt: {}", sagaId, failedAt); switch (failedAt) { case NOTIFICATION_SENT: eventPublisher.publish(new RefundPaymentCommand(sagaId)); // fall through case PAYMENT_PROCESSED: eventPublisher.publish(new ReleaseInventoryCommand(sagaId)); // fall through case INVENTORY_RESERVED: eventPublisher.publish(new CancelOrderCommand(sagaId)); // fall through default: break; } } } // Saga 状态机实现 @Entity public class SagaStateMachine { @Id private String sagaId; @Enumerated(EnumType.STRING) private SagaState currentState; @ElementCollection private List<String> executedSteps = new ArrayList<>(); @ElementCollection private List<String> compensatedSteps = new ArrayList<>(); @Column(columnDefinition = "TEXT") private String context; // 保存上下文（如订单ID、支付ID） public void transitionTo(SagaState newState) { this.currentState = newState; this.executedSteps.add(newState.name()); } // 构造函数、getter、setter 省略 }

事件驱动的 Saga 实现（编排模式）

// 订单服务：监听库存预留结果 @EventListener public void handleInventoryReserved(InventoryReservedEvent event) { String sagaId = event.getSagaId(); SagaStateMachine stateMachine = stateRepository.findById(sagaId); if (event.isSuccess()) { // 继续执行下一步：处理支付 paymentService.processPayment(sagaId, event.getOrderRequest()); stateMachine.transitionTo(SagaState.INVENTORY_RESERVED); } else { // 执行补偿：取消订单 orderService.cancelOrder(sagaId); stateMachine.transitionTo(SagaState.FAILED); } stateRepository.save(stateMachine); } // 支付服务：监听支付结果 @EventListener public void handlePaymentProcessed(PaymentProcessedEvent event) { String sagaId = event.getSagaId(); SagaStateMachine stateMachine = stateRepository.findById(sagaId); if (event.isSuccess()) { // 继续执行下一步：发送通知 notificationService.sendNotification(sagaId, event.getOrderRequest()); stateMachine.transitionTo(SagaState.PAYMENT_PROCESSED); } else { // 执行补偿：释放库存 + 取消订单 inventoryService.releaseInventory(sagaId, event.getOrderRequest()); orderService.cancelOrder(sagaId); stateMachine.transitionTo(SagaState.FAILED); } stateRepository.save(stateMachine); }

Saga 模式的关键工程细节

幂等性保证：所有参与服务必须支持幂等（相同请求多次执行结果一致）。通常通过唯一事务 ID + 状态检查实现。

// 幂等性检查 @Service public class InventoryService { @Autowired private InventoryRepository repository; @Transactional public void reserveInventory(String sagaId, OrderRequest request) { // 检查是否已经处理过 if (repository.existsBySagaId(sagaId)) { log.info("Saga {} 已经处理过，跳过", sagaId); return; } // 执行预留逻辑 // ... // 记录已处理 repository.save(new InventoryReservation(sagaId, request.getOrderId())); } }

空补偿（Empty Compensate）：如果 Try 阶段失败，Cancel 阶段可能不需要做任何事情，但必须实现空补偿接口。

public interface SagaParticipant { void tryExecute(SagaContext context); void confirm(SagaContext context); void cancel(SagaContext context); // 必须实现，即使什么都不做 }

悬挂处理：如果 Try 执行超时，补偿请求先到，需要确保后续 Try 不再执行。

// 在 cancel 方法中记录状态，try 方法检查状态 public void cancel(SagaContext context) { String sagaId = context.getSagaId(); compensatedSagas.add(sagaId); // 记录已补偿 // 执行补偿逻辑 // ... } public void tryExecute(SagaContext context) { String sagaId = context.getSagaId(); if (compensatedSagas.contains(sagaId)) { log.info("Saga {} 已补偿，不再执行 Try", sagaId); return; } // 执行 Try 逻辑 // ... }

四、分布式事务的性能优化与监控

分布式事务的性能瓶颈通常在于网络延迟和协调开销。优化策略：

优化一：并行执行

分析 Saga 步骤的依赖关系，无依赖的步骤可以并行执行。

// 订单创建和积分预扣可以并行 @Async public CompletableFuture<Void> createOrderAsync(String sagaId, OrderRequest request) { orderService.createOrder(sagaId, request); return CompletableFuture.completedFuture(null); } @Async public CompletableFuture<Void> reservePointsAsync(String sagaId, OrderRequest request) { pointsService.reservePoints(sagaId, request); return CompletableFuture.completedFuture(null); } // 等待所有并行任务完成 CompletableFuture.allOf( createOrderAsync(sagaId, request), reservePointsAsync(sagaId, request) ).get();

优化二：异步补偿

主事务失败时，补偿事务可以异步执行，加速失败响应。

@EventListener public void handleSagaFailed(SagaFailedEvent event) { // 异步执行补偿 CompletableFuture.runAsync(() -> { compensateSaga(event.getSagaId(), event.getFailedAt()); }); // 立即响应用户 response.setStatus("FAILED"); }

优化三：超时优化

合理设置各步骤超时时间，避免无限等待。

# 配置超时时间 saga: timeouts: create-order: 5s reserve-inventory: 3s process-payment: 10s send-notification: 2s

监控关键指标

@Component public class SagaMetrics { private final MeterRegistry meterRegistry; public SagaMetrics(MeterRegistry meterRegistry) { this.meterRegistry = meterRegistry; } public void recordSagaCompletion(String sagaType, boolean success, long durationMs) { Tags tags = Tags.of("saga_type", sagaType, "success", String.valueOf(success)); meterRegistry.counter("saga.completion.count", tags).increment(); meterRegistry.timer("saga.duration", tags).record(durationMs, TimeUnit.MILLISECONDS); } public void recordCompensation(String sagaType, String failedStep) { Tags tags = Tags.of("saga_type", sagaType, "failed_step", failedStep); meterRegistry.counter("saga.compensation.count", tags).increment(); } }

五、分布式事务的代价与工程决策

分布式事务不是银弹，它引入的复杂度往往被低估。

代价一：系统复杂度指数级上升

引入分布式事务后，需要额外处理：状态管理、幂等性、补偿逻辑、监控告警。团队需要投入大量时间学习和实施。

代价二：一致性延迟

最终一致性意味着用户可能看到中间状态。例如，订单已创建但库存未冻结，用户可能重复下单。需要设计相应的用户体验（如加载状态、提示信息）。

代价三：调试和排查困难

分布式事务涉及多个服务，排查问题需要跨服务日志关联。如果没有完善的链路追踪，排查问题如同大海捞针。

工程决策框架

场景	推荐方案	理由
强一致性要求（金融转账）	TCC 或 2PC	业务可容忍性能损失
最终一致性可接受（电商下单）	Saga	性能好，无单点
简单场景（发送通知）	本地消息表	实现简单
高并发场景（秒杀）	无事务 + 补偿	避免过度设计