如何处理DbUpdateConcurrencyException？高并发场景解决方案咨询

一、当前重试逻辑失效的核心原因 #

• 实体复用+跟踪清理不彻底：重试时如果直接使用旧实体（未重新从数据库拉取最新版本），旧的ETag会再次触发冲突；若DbContext是单例/跨作用域使用，ChangeTracker.Clear()无法完全清理残留的跟踪状态。
• Polly异常匹配不精准：DbUpdateException包含多种错误类型，你需要只针对Cosmos返回的412前置条件失败异常触发重试，而非所有DbUpdateException。
• 固定重试间隔不适应高并发：250ms固定间隔在每小时1.5-2万请求的场景下，仍会有大量请求在同一时间窗口竞争同一文档，冲突概率居高不下。

二、高并发场景下的最佳处理方案 #

1. 精准配置Polly指数退避重试策略 #

替换固定间隔为指数退避，同时精准匹配Cosmos并发冲突异常：

var concurrencyRetryPolicy = Policy
    .Handle<DbUpdateException>(ex => 
        ex.InnerException is CosmosException cosmosEx 
        && cosmosEx.StatusCode == HttpStatusCode.PreconditionFailed)
    .WaitAndRetry(3, 
        retryAttempt => TimeSpan.FromMilliseconds(250 * Math.Pow(2, retryAttempt)), // 指数退避：250ms → 500ms → 1000ms
        (exception, timeSpan, retryCount, context) =>
        {
            _dbContext.ChangeTracker.Clear();
            _logger.LogWarning("并发冲突，第{RetryCount}次重试，间隔{TimeSpan}ms", retryCount, timeSpan.TotalMilliseconds);
        });

2. 重构更新逻辑：每次重试必须拉取最新实体 #

重试时不能复用旧实体，必须重新从数据库获取带最新ETag的版本：

// Repo.cs 更新方法示例
public async Task UpdateEntityAsync(string id, string partitionKey)
{
    // 每次更新重新拉取最新实体
    var entity = await _dbContext.Entities
        .FirstOrDefaultAsync(e => e.Id == id && e.PartitionKey == partitionKey);
    
    if (entity == null)
        throw new KeyNotFoundException($"实体 {id} 不存在");
    
    // 执行业务更新操作
    entity.LastUpdated = DateTime.UtcNow;
    entity.RequestCount += 1;
    
    await _dbContext.SaveChangesAsync();
}

• EF Core会自动将实体ETag与Cosmos文档ETag对比，不匹配则触发412异常，这是乐观并发校验的核心。

3. 确保实体类正确配置ETag #

必须为实体添加ETag属性，让EF Core自动处理并发校验：

public class YourEntity
{
    public string Id { get; set; }
    public string PartitionKey { get; set; }
    
    // 用Timestamp特性映射Cosmos的ETag
    [Timestamp]
    public byte[] ETag { get; set; }
    
    // 业务属性
    public DateTime LastUpdated { get; set; }
    public int RequestCount { get; set; }
}

• 未配置ETag的话，EF Core不会触发并发校验，也就不会抛出DbUpdateConcurrencyException。

4. 可选：异步批量处理（非实时场景） #

如果业务允许延迟更新，将请求放入消息队列（如Azure Service Bus），用有限并发的消费者处理更新，避免直接高并发冲突：

• 适合统计、计数类对实时性要求不高的场景，能大幅降低Cosmos的并发压力。

5. 调整Cosmos DB吞吐量配置 #

高并发下RU（请求单位）不足会导致请求排队，提升冲突概率：

• 开启自动缩放，让Cosmos根据负载自动调整RU；
• 临时手动提升RU，观察冲突率是否下降，确定最优配置。

三、关键排查点 #

• DbContext生命周期：必须使用作用域DbContext（每个请求一个实例），单例DbContext会导致跨请求的实体跟踪混乱，是并发问题的常见根源。
• 重试触发日志：在Polly的重试回调中添加日志，确认是否真的捕获到412异常并执行了重试。
• Cosmos监控：查看Cosmos的指标（如412状态码请求数、RU使用率），确认冲突的频率和负载情况。

典型错误栈参考：

Microsoft.EntityFrameworkCore.DbUpdateException: Conflicts were detected for item with id 'ABC123'.
 ---> Microsoft.Azure.Cosmos.CosmosException : Response status code does not indicate success: PreconditionFailed (412); Substatus: 0; ActivityId: xxx; Reason: (Conflicting request etag).

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