什么是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，而是定义清楚每一步的补偿边界、设计好失败后的可观测链路、以及让业务方接受“最终一致”背后的权衡。
