ASP.NET端点用EF同步集合时，如何优雅处理竞争异常？

针对你遇到的并行请求创建重复Tag导致的唯一约束冲突问题，符合乐观并发规范的解决方案是捕获唯一约束冲突异常并重试完整流程，核心是确保重试时能获取到最新的数据库状态，而非依赖旧的DbContext缓存。

核心思路 #

1. 数据库层面必须保留Tag名称的唯一约束（这是最后一道防线）。
2. 捕获DbUpdateException中包含的SQL Server唯一约束冲突错误（错误码2601/2627）。
3. 重试时使用新的DbContext（避免旧上下文缓存的过期数据），重新执行Tag查询和资源创建逻辑。

手动实现重试逻辑示例 #

private async Task<IActionResult> CreateItemAsync(NewItemInfo newItemInfo)
{
    const int maxRetryTimes = 3;
    int retryCount = 0;

    while (retryCount < maxRetryTimes)
    {
        // 每次重试都创建新的DbContext，避免缓存干扰
        using var ctx = new YourDbContext();
        try
        {
            var item = newItemInfo.ToItem();
            var tagSet = ctx.Set<Tag>();

            foreach (var tag in newItemInfo.Tags)
            {
                // 重新查询当前数据库中的Tag状态
                var tagSameNameEntity = await tagSet.SingleOrDefaultAsync(t => t.Value == tag.Value);

                if (tagSameNameEntity == null)
                {
                    tagSameNameEntity = tag.ToTag();
                    await tagSet.AddAsync(tagSameNameEntity);
                }

                var connection = new ItemTag
                {
                    Id = Guid.NewGuid(),
                    TagId = tagSameNameEntity.Id,
                    ItemId = item.Id
                };

                item.ItemTags.Add(connection);
            }

            await ctx.Set<Item>().AddAsync(item);
            await ctx.SaveChangesAsync(true);

            return Ok(item);
        }
        catch (DbUpdateException ex)
        {
            // 仅处理SQL Server唯一约束冲突的异常
            if (ex.InnerException is SqlException sqlEx && (sqlEx.Number == 2601 || sqlEx.Number == 2627))
            {
                retryCount++;
                await Task.Delay(100 * retryCount); // 指数退避延迟，减少冲突概率
                continue;
            }
            // 其他异常直接抛出
            throw;
        }
    }

    return StatusCode(500, "重试多次后仍无法创建资源，请稍后再试");
}

用Polly库简化重试逻辑（推荐） #

Polly是.NET生态中成熟的容错库，能更简洁地实现重试策略：

1. 安装Polly NuGet包：Install-Package Polly
2. 实现代码：

// 定义重试策略：捕获唯一约束异常，最多重试3次，每次延迟递增
private readonly AsyncRetryPolicy _tagCreateRetryPolicy = Policy
    .Handle<DbUpdateException>(ex => 
        ex.InnerException is SqlException sqlEx && (sqlEx.Number == 2601 || sqlEx.Number == 2627))
    .WaitAndRetryAsync(3, retryAttempt => TimeSpan.FromMilliseconds(100 * retryAttempt));

public async Task<IActionResult> YourCreateEndpoint(NewItemInfo newItemInfo)
{
    return await _tagCreateRetryPolicy.ExecuteAsync(async () =>
    {
        using var ctx = new YourDbContext();
        var item = newItemInfo.ToItem();
        var tagSet = ctx.Set<Tag>();

        foreach (var tag in newItemInfo.Tags)
        {
            var tagSameNameEntity = await tagSet.SingleOrDefaultAsync(t => t.Value == tag.Value);

            if (tagSameNameEntity == null)
            {
                tagSameNameEntity = tag.ToTag();
                await tagSet.AddAsync(tagSameNameEntity);
            }

            var connection = new ItemTag
            {
                Id = Guid.NewGuid(),
                TagId = tagSameNameEntity.Id,
                ItemId = item.Id
            };

            item.ItemTags.Add(connection);
        }

        await ctx.Set<Item>().AddAsync(item);
        await ctx.SaveChangesAsync(true);

        return Ok(item);
    });
}

关键说明 #

• 为什么之前的重试无效：你之前的重试没有使用新的DbContext，旧上下文的缓存不会自动刷新，导致重试时依然查不到其他请求刚插入的Tag，重复触发冲突。
• 乐观并发优势：只有当实际发生冲突时才会重试，大部分请求无需等待，性能远优于信号量的悲观锁方案。
• 数据库约束不可少：代码层面的Tag查询只是优化，无法完全避免并发冲突，数据库的唯一约束是必须的最终保障。

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