Saga模式在C#中落地需以状态机管理流程、异步幂等补偿；TCC则要求Try预留资源、Confirm/Cancel严格幂等且隔离；推荐MassTransit+EF Core组合，辅以结构化日志与死信兜底。
Saga 模式在 C# 中怎么落地：核心是状态机 + 补偿动作
Saga 不是 .NET 内置特性，得靠自己建模或借助框架。关键不是“怎么写一个 Saga”，而是“怎么保证每步失败后能可靠回退”。Saga 本质是一系列本地事务组成的长活事务，每步成功就推进状态，失败就按反向顺序调用 Compensate() 方法。
常见错误是把补偿逻辑写成同步 HTTP 调用，结果补偿服务不可用导致整个 Saga 卡死。正确做法是：所有补偿操作必须幂等、异步触发、带重试和死信兜底。
- 用
StateMachine（如 Stateless 或 Automatonymous）管理状态流转，避免 if-else 堆砌 - 每个步骤的业务逻辑封装进
IHandler，补偿逻辑单独实现ICompensable - 持久化 Saga 实例必须用支持事务的存储（如 SQL Server），否则状态更新和消息发送不一致会丢补偿
- 推荐用
MassTransit：它内置SagaRepository和基于消息的补偿调度，RequestClient发起请求时自动关联CorrelationId，避免状态错乱
public class OrderSaga : SagaStateMachineInstance
{
public Guid CorrelationId { get; set; }
public OrderState CurrentState { get; set; }
public string OrderId { get; set; }
public DateTime? PaymentCompletedAt { get; set; }
}
// 在状态机定义里显式声明 Compensate()
During(OrderState.Created,
When(OrderSubmitted)
.Then(ctx => ctx.Instance.OrderId = ctx.Data.OrderId)
.TransitionTo(OrderState.Paid)
.Publish(ctx => new PaymentRequested { OrderId = ctx.Instance.OrderId }),
When(PaymentFailed)
.Compensate(x => x.Send(new CancelOrder { OrderId = x.Instance.OrderId }))
.TransitionTo(OrderState.Failed));
TCC 模式在 C# 中怎么写：Try/Confirm/Cancel 必须拆成三个独立可重入方法
TCC 的难点不在接口定义，而在 Confirm 和 Cancel 的幂等性与隔离性控制。很多团队误以为只要加个 [TransactionScope] 就行，但 TCC 是应用层事务，数据库事务范围只到本地 Try 阶段。
典型陷阱是：Try 阶段扣减库存用了 UPDATE stock SET quantity = quantity - @n WHERE id = @id AND quantity >= @n，但 Confirm 时没校验“是否已被其他订单占用”，导致超卖。
-
Try必须预留资源并冻结（比如冻结账户额度、标记库存为“预占”），不能直接扣减 -
Confirm只做最终提交：把“预占”转为“已占”，且要检查原始 Try 是否成功、是否被重复 Confirm -
Cancel必须释放预留资源，且允许被多次调用（例如网络重发导致 Cancel 到达两次） - 建议用分布式锁（如 Redis 的
SET key value EX 30 NX）保护 Confirm/Cancel 入口，防止并发冲突
public interface IInventoryService
{
Task TryReserveAsync(string sku, int quantity);
Task ConfirmReserveAsync(string sku, int quantity); // 检查 reserve_id 是否存在且未 confirm
Task CancelReserveAsync(string sku, int quantity); // 删除 reserve 记录即可，幂等
} MassTransit + Entity Framework 是目前最稳的 C# Saga/TCC 组合
别自己手撸事务协调器。MassTransit 提供了开箱即用的 Saga 持久化、消息去重、重试策略和可观测性钩子；EF Core 则能保证本地事务与 Saga 状态更新原子提交。
性能影响集中在两点：一是 Saga 状态表频繁读写，需对 CorrelationId 加唯一索引；二是 Confirm/Cancel 失败后进入死信队列，若没配置告警会悄无声息丢失事务一致性。
- 用
EntityFrameworkSagaRepository替代内存版，避免进程重启后 Saga 状态丢失 - 所有
Compensate消息必须设置TimeToLive（如 15 分钟），防止陈旧补偿污染业务 - TCC 的
Confirm接口建议加[HttpPost("/inventory/confirm")]并走 API 网关，便于限流和熔断 - 不要在 Saga 中调用外部 HTTP API 做核心判断（比如调用户中心查余额），应通过事件驱动解耦
最容易被忽略的点：Saga/TCC 日志必须包含完整上下文和时间戳
出问题时，你不会看到 “TCC Confirm 失败”，只会看到一条孤立的 InvalidOperationException。没有 CorrelationId、没有 StepName、没有 OriginalRequest 的日志，等于没日志。
调试时发现补偿失败，90% 情况是因为日志里没记清楚当时 Try 预留了什么值、Confirm 时查到了什么状态、Cancel 调用传入的参数是否和 Try 匹配。
- 所有 Saga 状态变更必须写入结构化日志（如 Serilog），字段包括：
CorrelationId、Step、Input、Output、Timestamp - TCC 的每个方法入口第一行打日志：
Log.Information("TryReserve {@Request} at {Timestamp}", request, DateTime.UtcNow) - 禁止在补偿逻辑里吞异常，
catch后必须重新抛出或记录明确错误码（如COMPENSATE_FAILED_LOCK_TIMEOUT）
