Saga
长事务的补偿模式。把一个跨服务的业务流程拆成一串本地事务，每步配一个反向补偿动作。
又称Saga 模式长事务
架构
是什么
Saga 是一种最终一致性方案。一个跨多个服务的业务流程，被拆成若干本地事务 $T_1, T_2, \dots, T_n$，每个 $T_i$ 配一个补偿动作 $C_i$。全部成功则流程完成；若 $T_k$ 失败，则按倒序执行 $C_{k-1}, \dots, C_1$ 把已经造成的变更撤销。
两种协调方式
| 编排（Orchestration） | 协同（Choreography） | |
|---|---|---|
| 控制方式 | 中央协调器发命令 | 各服务订阅事件自行推进 |
| 优点 | 流程显式可读，易监控和补偿 | 无单点，服务解耦彻底 |
| 缺点 | 协调器容易长成上帝类 | 流程散落，排障困难 |
银行核心这类流程长、监管要求可追溯的场景，基本都选编排式。
与 2PC 的取舍
2PC 追求强一致，但在微服务下会长时间锁资源，且协调者故障即阻塞。Saga 放弃隔离性（中间状态对外可见），换来可用性。设计时必须处理隔离性缺失：例如转账 saga 的中间态会让用户看到「已扣款未入账」，需要用预留/冻结语义来规避。
补偿不是回滚
数据库回滚能抹掉一切，补偿是业务动作：扣款 100 元的补偿是「冲正 100 元」，会产生新的流水记录。因此补偿动作必须幂等，且要能处理「补偿也失败」的情况（重试 + 人工兜底）。
提及本词的文章
- 聚合根与领域事件：DDD 战术建模从一致性边界到事件驱动，拆解聚合根的设计原则、领域事件的发布与消费，以及在银行核心系统里的落地坑点。
- CQRS 与 Saga：复杂业务的读写分离与最终一致读写模型分家之后，复杂长事务如何用 Saga 串起来，又如何在不牺牲对账能力的前提下接受最终一致。
- 分布式事务在金融场景的取舍对比 2PC、TCC、Saga 与本地消息表在金融场景的适用边界，并说明为什么对账才是最终防线。
- 关于专注分布式核心系统与银行业务，探索 AI 在银行领域的落地。