在微服务架构下,跨服务的事务一致性是永恒的难题。传统 XA 分布式事务采用强一致性,存在性能差、阻塞时间长、无法适配长事务等短板。Saga 模式将一个全局长事务拆分为一系列独立本地事务,每个子事务配套补偿操作,失败时逆序执行补偿,最终达成数据一致。
理解 Saga 的三个基石:子事务、补偿操作、最终一致性。三者共同构成了"无全局锁、失败可回滚"的事务模型。
全局事务:创建订单 → 扣减库存 → 扣减账户余额。若执行到 T3 扣款失败,则逆序执行补偿:C3(无需执行)→ C2(恢复库存)→ C1(取消订单)。
协同式(Choreography)去中心化事件驱动,编排式(Orchestration)中心化调度控制。两种模式各有适用场景,选型决定了整个事务链路的维护成本。
| 维度 | 协同式 Saga | 编排式 Saga |
|---|---|---|
| 调度中心 | 无中心,消息驱动 | 中心调度器主动控制 |
| 流程定义 | 分散在各个服务 | 集中保存在调度器 |
| 维护成本 | 简单流程友好,复杂流程难以维护 | 复杂业务易于维护、可视化 |
| 技术依赖 | 可靠消息队列 | 流程调度引擎 |
| 单点风险 | 无 | 调度器需要集群保障高可用 |
XA、TCC、Saga 三种主流方案的横向对比。每种方案都有其适用边界,选型本质是在性能、一致性、开发成本三角中做取舍。
四类高频工程痛点,每一类都对应过真实的线上故障。Saga 不是银弹,落地前必须想清楚这些边界问题。
三个生产级可用的 Saga 框架,分别对应不同的生态与场景。选型时除功能外,还需考虑团队技术栈与社区活跃度。
Saga 模式是微服务长事务场景下首选的最终一致性方案,依靠"本地事务 + 补偿机制"规避 XA 锁竞争性能瓶颈。
分布式事务没有完美解。XA 牺牲性能换强一致,TCC 牺牲开发效率换隔离性,Saga 牺牲中间状态可见性换长事务的可行性。每一种方案都是在性能、一致性、开发成本三角中做取舍。
Saga 的核心价值在于:它让跨服务的长流程业务不再被全局锁束缚,通过"本地事务 + 补偿"的组合,把强一致性问题降维成最终一致性问题。这是电商订单、履约、供应链这类长链路业务能在微服务下跑起来的根本前提。
但请记住:选择 Saga,就意味着接受短暂不一致、承担补偿逻辑的开发成本、处理空补偿与悬挂问题。工程没有银弹,只有合适的取舍。