Saga模式为何缺乏隔离性？请求结合实例讲解

Saga本质是分布式事务的一种实现方案，它将一个全局事务拆分为多个独立的本地事务，每个本地事务执行完毕后立即提交——这就是它缺乏隔离性的根源：没有全局锁或统一的事务上下文来屏蔽未完成的中间状态，每个本地事务的修改都会立刻对外可见，其他事务可以直接读写这些未最终确认的数据，进而引发隔离异常。

下面用两个实际场景带你理解：

场景1：电商下单的库存超卖风险 #

假设我们的电商系统用Saga处理下单流程，包含3个本地事务：

1. 创建订单（状态标记为「待支付」）
2. 扣减对应商品的库存
3. 完成支付（更新订单为「已完成」）

现有最后1件库存的商品P001，用户X和Y同时发起下单请求：

• T1：用户X的Saga执行「创建订单」，提交后订单X（待支付）写入数据库，对外可见。
• T2：用户Y的Saga执行「创建订单」，提交后订单Y（待支付）也写入数据库，对外可见。
• T3：用户X的Saga执行「扣减库存」，库存从1变为0，提交成功。
• T4：用户Y的Saga执行「扣减库存」，发现库存不足，触发回滚逻辑：删除订单Y。

问题出在T2到T4的时间窗口：这段时间内，订单Y已经存在，订单查询、销量统计等服务会读到这个「待支付」订单，甚至可能把它计入有效订单数，但最终这个订单会被删除——这就是典型的幻读/不可重复读异常：其他事务读取到了Saga未完成的中间状态数据，而这些数据最终并未被确认。

场景2：跨账户转账的中间状态不一致 #

假设用Saga处理用户A给用户B转100元的流程，包含2个本地事务：

1. 从A的账户扣除100元
2. 给B的账户增加100元

执行过程中：

• T1：A的账户扣减100元的本地事务提交，A的余额从500变为400，数据对外可见。
• T2：此时系统突发短暂延迟，B的账户加100元的事务还未执行。
• T3：有一个账户对账服务读取A和B的余额，发现总金额比转账前少了100元（A:400，B:300，总700；转账前总800）。

这个对账服务读到的就是Saga未完成的中间状态，属于脏读的一种——虽然最终B的账户会加上100元，总金额恢复正常，但中间时刻读取到了不一致的数据，可能导致错误的对账结果。

核心总结 #

Saga为了适配分布式系统的可用性、性能需求，放弃了单库ACID事务的强隔离性：它没有全局的事务快照或锁机制，每个本地事务的修改会立即持久化并暴露给外部。这种设计带来了最终一致性，但过程中必然会出现各类隔离异常，通常需要通过业务补偿、幂等性设计、乐观锁等手段来缓解。

内容的提问来源于stack exchange，提问作者srinivas chaitanya