直接回答

SOA/分布式环境中，长事务意味着长时间持有跨服务的锁和资源，而服务间通过网络通信、各自自治，无法保证及时提交——一个服务慢或挂掉就会让其他服务的连接和行锁被无限占用，吞吐雪崩、可用性归零；2PC 等分布式事务还引入协调者单点和阻塞问题。Saga 模式因此成为替代：把长事务拆成一串本地事务，每步独立提交，失败时按相反顺序执行补偿操作完成语义回滚。

展开解析

Saga 的优势是可用性和松耦合：每步本地提交，不跨服务持锁，单服务故障只影响当前步骤。代价是放弃隔离性——中间状态对其他事务可见（可能读到"已扣款但订单未确认"），需用状态机字段、语义锁或版本号缓解；补偿也不是万能的，已发的邮件、已打的款只能做"反向业务操作"而非真正撤销。实现方式两种：编排式（中心协调器驱动，流程清晰）和编舞式（事件驱动，去中心但链路隐晦）。设计要点：每步幂等、补偿逻辑与正向逻辑一并建模、持久化 Saga 状态以便恢复。追问：与 TCC 的区别（TCC 在资源层预留-确认-取消）、补偿本身失败怎么办（重试+人工兜底）。