SemaphoreSlim与Hangfire选型：如何避免订单重复处理的并发问题？

问题背景 #

我有一个处理订单履约请求的服务，规则是仅当订单状态为Paid时才执行处理逻辑，订单其他状态包括Fulfilled（已履约）和Pending（待支付）。当前的核心逻辑代码如下：

var orderDetails = await _dbContext.Orders.FirstOrDefaultAsync(s => s.Id == orderId);

string errMsg = string.Empty;

if (orderDetails == null)
{
    errMsg = "Invalid order";
    // 处理无效订单ID的情况
    return new ServiceTypeResponse<SimpleOrderDetailsResponseModel>
    {
        Data = null,
        Errors = new List<string> { errMsg },
        ResponseMessage = errMsg,
        StatusCode = 400,
        Success = false
    };
}

if (orderDetails.Status == OrderStatus.Fullfilled)
{
    // 处理已履约订单的情况
    errMsg = "This order has already been fulfilled";
    return new ServiceTypeResponse<SimpleOrderDetailsResponseModel>
    {
        Data = new SimpleOrderDetailsResponseModel(orderDetails),
        Errors = null,
        ResponseMessage = errMsg,
        StatusCode = 200,
        Success = true
    };
}

if (orderDetails.Status == OrderStatus.Paid)
{
    // 1. 执行订单处理逻辑（比如调用第三方服务给用户发权益）
    // 2. 将订单状态更新为Fulfilled
}
return;

现在面临的问题是多线程并发请求会导致竞态条件：比如两个线程同时读取到订单状态为Paid，其中一个线程还没来得及把状态改成Fulfilled，另一个线程已经执行了第三方服务调用，造成重复履约。

我考虑过几种方案：

• SemaphoreSlim 做本地锁
• 使用Hangfire进行请求排队
• 数据库乐观并发锁（已排除，因为它只能阻止重复更新，但无法阻止其他线程读取Paid状态并执行处理逻辑）

想知道结合性能和最佳实践，哪种方案是避免订单重复处理的最优选择？

最优方案分析与选择 #

1. SemaphoreSlim：仅适合单实例场景，不推荐分布式部署 #

SemaphoreSlim是进程内的本地锁，只能管控当前服务实例内的线程并发。如果你的服务是多实例部署（比如集群、K8s容器），不同实例的线程完全感知不到彼此的锁，照样会出现重复处理的问题。除非能确保服务永远单实例运行，否则这个方案基本没用。

2. Hangfire：异步处理场景的最优解 #

Hangfire是成熟的后台任务调度框架，天然支持分布式任务排队与幂等性控制，完美匹配订单履约的异步场景：

• 可以把订单处理请求转化为后台任务，通过DisableConcurrentExecution特性或者自定义入队前检查，确保同一订单的任务不会并发执行
• 支持分布式部署，不管多少服务实例，任务都会被统一调度，全局唯一
• 自带重试、监控、失败告警机制，能处理第三方服务调用失败的情况，比自己写锁逻辑健壮得多

唯一需要注意的是：如果你的接口需要同步返回处理结果（比如用户发起请求后要立刻知道是否成功），Hangfire的异步任务模式需要额外做状态查询逻辑；如果是异步处理场景，Hangfire是首选。

3. 补充：数据库悲观锁（SELECT ... FOR UPDATE）：同步场景的轻量方案 #

既然乐观锁无法阻止提前读取，那可以用数据库悲观锁——在读取订单时直接加排他锁，阻止其他线程读取该订单，直到当前处理完成并释放锁。用EF Core实现的示例代码如下：

// 用SELECT ... FOR UPDATE加排他锁，确保只有当前线程能读取并修改该订单
var orderDetails = await _dbContext.Orders
    .FromSqlRaw("SELECT * FROM Orders WHERE Id = {0} FOR UPDATE", orderId)
    .FirstOrDefaultAsync();

// 后续状态检查与处理逻辑和原代码一致
if (orderDetails?.Status == OrderStatus.Paid)
{
    // 执行第三方服务调用等处理逻辑
    orderDetails.Status = OrderStatus.Fulfilled;
    await _dbContext.SaveChangesAsync();
}

这个方案的优势：

• 不需要引入额外框架，直接用数据库原生能力
• 支持分布式场景，数据库锁是全局生效的
• 性能开销可控——只要锁的粒度是单条订单记录，且处理逻辑耗时不长，对数据库的影响可以忽略

缺点是如果处理逻辑耗时过长（比如第三方服务响应慢），会导致数据库行锁持有时间过长，可能影响其他对该订单的查询操作。

最终结论 #

• 异步处理场景：优先选Hangfire，扩展性、健壮性拉满，后期维护成本低。
• 同步处理场景：用数据库悲观锁（SELECT ... FOR UPDATE），直接解决读取+修改的原子性问题，避免竞态条件。
• 绝对不要用SemaphoreSlim做分布式场景的并发控制，它只适合单实例的简单场景。

内容的提问来源于stack exchange，提问作者Josh