Saga模式适用于跨服务/数据库/消息队列的最终一致性场景，如订单创建、退款流程；C#中推荐Orchestration协调式实现，用MassTransit等库配合状态机与持久化，补偿需幂等且配兜底人工干预。
什么是Saga模式在C#中的典型适用场景
Saga模式不是用来替代数据库事务的，而是当跨服务、跨数据库、跨消息队列的操作无法用ACID保证原子性时，用一系列本地事务 + 补偿操作来实现最终一致性。它常见于订单创建（库存扣减+支付+物流单生成）、退款流程（逆向扣减库存+原路退钱+取消物流）这类长周期、多参与者业务。
关键判断点：TransactionScope 在跨服务调用中会失效，SqlTransaction 无法跨越数据库实例，此时才需要 Saga；如果只是单库多表，优先用本地事务。
C#中实现Saga的两种主流方式对比
一种是“Choreography（编排式）”，靠事件驱动，各服务监听事件并触发下一步或补偿；另一种是“Orchestration（协调式）”，由一个中心协调器（如 SagaCoordinator）控制流程和重试逻辑。C#项目中更推荐后者，因为可追踪、易调试、补偿路径明确。
- Choreography：每个服务发布/订阅
OrderPlacedEvent、InventoryReservedEvent等，但失败时难以定位哪一步卡住 - Orchestration：用一个轻量协调类（如基于
StateMachine<ordersagastate></ordersagastate>的状态机），每步执行前持久化当前状态到数据库（如SagaInstance表），失败后可查表续跑 - 推荐库：
MassTransit内置Saga支持（基于 EF Core 或 MongoDB 持久化），Rebus也提供Saga扩展，避免手写状态恢复逻辑
用MassTransit实现Saga的关键步骤与坑
MassTransit 的 Saga 实质是事件驱动的状态机，核心是定义状态、事件映射、持久化策略和补偿动作。最容易出错的是状态变更顺序和并发冲突。
- 必须为每个 Saga 类型定义唯一
CorrelationId（通常来自初始命令的 ID），否则不同订单事件会混入同一 Saga 实例 - 补偿操作（
Compensate）必须幂等，比如RefundPayment要检查是否已退，不能重复调用第三方支付接口 - 状态持久化不能只依赖内存——必须配置
EntityFrameworkSagaRepository或类似，否则服务重启后 Saga 状态丢失 - 示例片段：
public class OrderSaga : MassTransit.SagaStateMachineInstance { public Guid CorrelationId { get; set; } public OrderSagaState CurrentState { get; set; } public DateTime? InventoryReservedAt { get; set; } public string OrderId { get; set; } }
补偿失败怎么办？Saga的边界与兜底设计
Saga 本身不解决“补偿也失败”的问题，它只把失败显式暴露出来。真实系统中必须配套人工干预通道和可观测性。
- 所有补偿失败需记录到独立表（如
SagaCompensationFailure），带完整上下文（Saga ID、失败步骤、异常堆栈） - 定期扫描失败记录，触发告警或推送到工单系统；不要指望自动重试解决所有问题
- 对强一致性要求极高的环节（如资金账户变更），仍应优先使用 TCC 模式或分布式锁 + 本地事务，Saga 更适合“业务上允许短暂不一致”的场景
- 注意：Saga 不等于“最终一定成功”，它只是把不一致的时间窗口从秒级拉长到分钟/小时级，并让这个过程可观察、可修复
真正难的不是写完 SagaStateMachine，而是定义清楚每一步的补偿边界、设计好失败后的可观测链路、以及让业务方接受“最终一致”背后的权衡。
