c# 如何用 c# 实现分布式事务 Saga 模式和 TCC 模式

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）