1. Saga 模式的编排与协调中编排式（Choreography）vs 协调式（Orchestration）的适用场景、补偿事务的幂等性设计、与 Outbox 模式的组合保证最终一致性、长事务超时与部分失败的处理
请比较 Saga 模式的编排式（Choreography）与协调式（Orchestration）两种实现方式的适用场景，并说明补偿事务的幂等性设计、与 Outbox 模式组合保证最终一致性，以及长事务超时与部分失败的处理？
- Choreography 与 Orchestration 的拓扑、耦合度与故障处理差异
- 补偿事务必须具备幂等性与可逆性
- Saga 与 Outbox 组合解决分布式事务与消息可靠投递
Saga 是一种用一系列本地事务（Local Transaction）+ 补偿（Compensation）来替代分布式事务（2PC）的长期事务模式。Coordination 方式分两种：Choreography（编排式）通过事件在各服务间传递，每个服务在本地事务成功后发布事件，由下一个服务订阅并继续，优点是去中心化、无单点、耦合度低，缺点是流程隐式、难以跟踪、调试与回滚复杂；Orchestration（协调式）由一个中央协调器（Orchestrator）显式地调用各服务并记录状态，优点是流程集中、易于管理与回滚，缺点是协调器成为单点与性能瓶颈。补偿事务必须幂等（可重复执行不出错）且可逆（能够撤销已提交的副作用），否则发生部分失败时无法保证最终一致。与 Outbox 组合时，每个服务在本地数据库事务中同时写入业务数据和 Outbox 表，再由 Outbox 发布器可靠地投递事件，从而保证业务提交与消息发送原子一致，避免"双写不一致"。对于长事务超时，应设置超时预算与超时补偿，部分失败时执行补偿链回滚已提交步骤；同时要防止悬挂事务（suspended transaction），即补偿已执行但正向原事务仍在运行，可通过状态机与幂等键兜底。
Saga 的核心是"用本地事务 + 补偿"换取"无全局锁、无阻塞"，牺牲了 ACID 的隔离性（Isolation）与原子性（Atomicity 的强保证），换取可用性与性能。选择 Choreography 还是 Orchestration 取决于团队规模与流程复杂度：简单线性流程且事件语义清晰用 Choreography，复杂分支、需要集中审计与回滚用 Orchestration。幂等是补偿与消息处理的前提，Outbox 保证消息可靠。
// Orchestration 式 Saga 的协调器骨架（伪代码）
public class SagaCoordinator {
public void runOrderSaga() {
try {
orderService.createOrder(payload); // 本地事务
inventoryService.reserveStock(payload); // 本地事务
paymentService.charge(payload); // 本地事务
// 全部成功 -> 标记完成
} catch (ReserveFailedException e) {
// 已提交的步骤需要补偿
orderService.compensateOrder(orderId); // 幂等补偿
paymentService.refund(orderId); // 幂等补偿
}
}
}