1. 分布式事务的困境与Saga的诞生
在微服务架构中，最让人头疼的问题之一就是如何保证跨服务的数据一致性。想象一下，你在电商平台下单时，需要同时扣减库存、创建订单、扣款三个操作。如果库存扣减成功了，但扣款失败，这时候该怎么办？传统ACID事务在单体架构中能很好解决这个问题，但在分布式环境下却显得力不从心。
我第一次遇到这个问题是在2018年做一个金融系统重构时。当时我们尝试用两阶段提交（2PC），结果发现性能差到令人发指，系统吞吐量直接下降了70%。正是在这种背景下，Saga模式进入了我的视野——它用最终一致性的思想，通过补偿机制解决了分布式事务难题。
2. Saga模式核心原理拆解
2.1 什么是Saga模式
Saga本质上是一种长事务解决方案，它将一个分布式事务拆分为多个本地事务，每个本地事务都有对应的补偿操作。当某个步骤失败时，系统会逆向执行已成功步骤的补偿操作，使系统回到初始状态。
举个实际例子：酒店预订系统包含"预订房间→创建订单→支付"三个步骤。对应的Saga实现可能是：
- T1: 预订房间（补偿C1: 取消预订）
- T2: 创建订单（补偿C2: 删除订单）
- T3: 执行支付（补偿C3: 退款）
2.2 两种实现方式对比
协同式Saga：
- 通过事件驱动架构实现
- 每个服务完成后发布事件
- 下个服务监听并处理事件
- 适合事件溯源架构
- 典型框架：Axon Framework
编排式Saga：
- 有中央协调器（Orchestrator）
- 协调器调用各服务并处理补偿
- 流程控制集中在协调器
- 更适合复杂业务流程
- 典型实现：Camunda、Zeebe
重要提示：选择哪种方式取决于团队技术栈。事件驱动架构经验丰富的团队适合协同式，传统服务团队可能更适合编排式。
3. 实战：基于Spring实现编排式Saga
3.1 基础环境搭建
我们先建立一个酒店预订系统的Demo：
java复制// 订单服务
@PostMapping("/orders")
public Order createOrder(@RequestBody Order order) {
return orderRepository.save(order);
}
@DeleteMapping("/orders/{id}")
public void cancelOrder(@PathVariable Long id) {
orderRepository.deleteById(id);
}
// 库存服务
@PostMapping("/inventory")
public Inventory reserveInventory(@RequestBody InventoryRequest request) {
// 预留库存逻辑
}
@DeleteMapping("/inventory/{id}")
public void releaseInventory(@PathVariable Long id) {
// 释放库存逻辑
}
3.2 Saga协调器实现
核心协调器代码结构：
java复制public class BookingSaga {
private final OrderService orderService;
private final InventoryService inventoryService;
private final PaymentService paymentService;
@Transactional
public void createBooking(BookingRequest request) {
// 步骤1：预留库存
Inventory inventory = inventoryService.reserve(request);
try {
// 步骤2：创建订单
Order order = orderService.create(request);
// 步骤3：执行支付
paymentService.charge(request);
} catch (Exception e) {
// 补偿逻辑
inventoryService.release(inventory.getId());
if (order != null) {
orderService.cancel(order.getId());
}
throw new SagaException("Booking failed", e);
}
}
}
3.3 关键设计考量
- 幂等性设计：
java复制@PostMapping("/inventory")
public Inventory reserveInventory(@RequestBody InventoryRequest request) {
// 通过业务ID保证幂等
return inventoryRepository.findByOrderId(request.getOrderId())
.orElseGet(() -> {
Inventory inventory = new Inventory();
// 设置属性...
return inventoryRepository.save(inventory);
});
}
- 补偿事务注意事项：
- 补偿操作必须同样幂等
- 补偿可能需要额外业务数据（如原始请求参数）
- 补偿不总是能100%回滚（如已发送的邮件通知）
4. 生产环境中的进阶实践
4.1 超时与重试机制
在分布式系统中，网络问题可能导致操作超时。我们需要为Saga步骤添加合理的重试策略：
java复制@Retryable(maxAttempts=3, backoff=@Backoff(delay=1000))
public void chargePayment(PaymentRequest request) {
// 支付逻辑
}
@Recover
public void handlePaymentFailure(PaymentRequest request) {
// 标记支付失败
paymentRepository.markAsFailed(request.getId());
throw new PaymentException("Payment failed after retries");
}
4.2 可视化与监控
使用Spring Actuator暴露Saga执行指标：
yaml复制management:
endpoints:
web:
exposure:
include: health,metrics,sagas
metrics:
tags:
application: ${spring.application.name}
关键监控指标：
- 每个Saga的成功/失败率
- 各步骤平均耗时
- 补偿操作触发频率
- 重试次数统计
5. 常见问题与避坑指南
5.1 典型问题排查表
| 问题现象 | 可能原因 | 解决方案 |
|---|---|---|
| 补偿操作未触发 | 异常被捕获未传播 | 确保异常抛出到协调器 |
| 部分补偿失败 | 补偿操作不幂等 | 为补偿添加幂等控制 |
| Saga执行卡住 | 某个服务无响应 | 添加合理的超时设置 |
| 最终不一致 | 补偿无法完全回滚 | 设计人工干预流程 |
5.2 性能优化技巧
- 并行执行：对于无先后依赖的步骤可以并行化
java复制CompletableFuture<Inventory> inventoryFuture = CompletableFuture
.supplyAsync(() -> inventoryService.reserve(request));
CompletableFuture<Order> orderFuture = CompletableFuture
.supplyAsync(() -> orderService.create(request));
// 等待两者完成
CompletableFuture.allOf(inventoryFuture, orderFuture).join();
-
批量补偿：当需要补偿大量操作时，考虑批量处理
-
状态快照：定期保存Saga执行状态，避免从头开始补偿
6. Saga模式的适用场景分析
6.1 最适合的场景
- 长周期业务流程：如电商订单、酒店预订、保险理赔等
- 跨多服务操作：涉及3个以上服务的业务流
- 对实时一致性要求不高：允许秒级最终一致
6.2 不推荐的场景
- 高频交易系统：如股票交易，需要强一致性
- 无法提供补偿的操作：如发送短信、邮件通知
- 服务边界不清晰：服务间耦合度高的情况
在实际项目中，我们曾将Saga应用于一个跨境支付系统，将原本2PC方案的吞吐量从200 TPS提升到了1500 TPS，同时将平均延迟从800ms降到了200ms。关键是要为每个业务场景设计合适的补偿策略——比如对于外汇兑换操作，我们的补偿不是简单回滚，而是执行反向兑换操作并记录汇率差。