Saga 模式在 C# 中怎么落地：核心是状态机 + 补偿动作
Saga 不是 .NET 内置特性，得靠自己建模或借助框架。关键不是“怎么写一个 Saga”，而是“怎么保证每步失败后能可靠回退”。
Saga本质是一系列本地事务组成的长活事务，每步成功就推进状态，失败就按反向顺序调用
Compensate()方法。
常见错误是把补偿逻辑写成同步 HTTP 调用，结果补偿服务不可用导致整个 Saga 卡死。正确做法是：所有补偿操作必须幂等、异步触发、带重试和死信兜底。
用StateMachine<orderstate ordercommand></orderstate>（如 Stateless 或 Automatonymous）管理状态流转，避免 if-else 堆砌 每个步骤的业务逻辑封装进
IHandler<trequest></trequest>，补偿逻辑单独实现
ICompensable<trequest></trequest>持久化 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; }
}
<p>// 在状态机定义里显式声明 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<bool> TryReserveAsync(string sku, int quantity);
Task<bool> ConfirmReserveAsync(string sku, int quantity); // 检查 reserve_id 是否存在且未 confirm
Task<bool> 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、
TimestampTCC 的每个方法入口第一行打日志：
Log.Information("TryReserve {@Request} at {Timestamp}", request, DateTime.UtcNow)
禁止在补偿逻辑里吞异常，catch后必须重新抛出或记录明确错误码（如
COMPENSATE_FAILED_LOCK_TIMEOUT）
