asp.net core efcode 如何解决并发冲突问题

在某些保存数据比较频繁的时候，加上又是使用异步的时候，加上编写SQL不严谨就很容易产生并发冲突的问题。首先在产生这种问题的时候我们第一时间检查自己的代码，有的时候我们只要理顺了代码把一些不合理的EfCode代码做出修改就可以解决很多的问题。另外在一些频率比较高的查询上建议New 一个DbContext，这样也会好很多。

另外我们就是使用锁来避免并发问题，EF Core 主要提供了乐观并发和悲观并发两种策略来应对并发问题。下面是一个对比表格，帮助你快速了解这两种策略的核心区别：

特性	乐观并发控制	悲观并发控制
基本原理	假设冲突不常发生，更新时检查数据是否被修改过	假设冲突经常发生，操作时直接锁定资源
实现方式	使用并发令牌（如时间戳/RowVersion）或属性标记	使用数据库锁（如 `UPDLOCK`）
性能影响	冲突较少时性能较好，冲突较多时重试或异常处理开销大	保证数据强一致性，但可能引发线程阻塞和性能下降
适用场景	读多写少，数据冲突概率较低的应用	写操作非常频繁，且数据竞争激烈的场景
EF Core支持	原生支持	需通过原生SQL或事务手动实现

乐观并发的核心在于，它在执行更新操作时，会检查要更新的记录自从被读取后，是否已被其他操作修改过（通过并发令牌比对）。如果已被修改，则意味着发生了冲突，EF Core 会抛出 DbUpdateConcurrencyException 异常。

如何实现乐观并发

实现乐观并发，主要方式是使用并发令牌（Concurrency Token）。EF Core 提供了两种主要方式：

[ConcurrencyCheck] 特性：在模型类的属性上标注 [ConcurrencyCheck]，该属性就会被用作并发检查的依据。
IsRowVersion 方法：配置一个字节数组 (byte[]) 属性作为行版本（RowVersion）或时间戳。这是推荐的方式，因为数据库会在每次更新行时自动生成新的行版本值。

下面是配置并发令牌的示例：

// 在模型类中定义 RowVersion 属性
public class House
{
    public int Id { get; set; }
    public string Owner { get; set; }
    [Timestamp] // 使用 Data Annotations 标记
    public byte[] RowVersion { get; set; }
}

// 或者在 DbContext 的 OnModelCreating 中配置（Fluent Api 方式）
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<House>(b =>
    {
        b.ToTable("T_Houses");
        b.Property(b => b.RowVersion).IsRowVersion(); // 设置为行版本
        // 或者对普通字段进行并发令牌标记
        // b.Property(p => p.Owner).IsConcurrencyToken();
    });
}

配置后，EF Core 在更新实体时会自动在 WHERE 子句中包含并发令牌的旧值。SQL 语句类似于：

UPDATE [T_Houses] SET [Owner] = @p0 WHERE [Id] = @p1 AND [RowVersion] = @p2;

如果此 UPDATE 语句影响的行数为 0（因为 RowVersion 已变），EF Core 就会抛出 DbUpdateConcurrencyException 异常。

处理并发冲突

发生并发冲突时，你需要捕获异常并决定如何处理

try
{
    Await _context.SaveChangesAsync();
    // 保存成功处理
}
catch (DbUpdateConcurrencyException ex)
{
    // 1. 获取引发异常的实体条目
    Var entry = ex.Entries.First();
    // 2. 获取当前数据库中的值（其他人已提交的值）
    var databaseValues = await entry.GetDatabaseValuesAsync();
    if (databaseValues == null)
    {
        // 记录已被删除
        Console.WriteLine("该记录已被删除。");
    }
    else
    {
        // 3. 获取数据库中的当前值
        string currentOwnerInDb = databaseValues.GetValue<string>(nameof(House.Owner));
        
        // 4. 可选择的方式：刷新实体，提示用户，或自定义合并逻辑
        // 方式A：用数据库的新值覆盖当前实体
        entry.OriginalValues.SetValues(databaseValues);
        // 或者方式B：重新加载实体
        // entry.Reload();

        Console.WriteLine($"并发冲突！记录已被 {currentOwnerInDb} 抢先修改。");
        // 这里可以根据业务逻辑决定是重试、报错还是合并数据
    }
}

悲观并发通过直接在数据库层面加锁（如 UPDLOCK）来防止其他操作修改数据，适用于数据竞争非常激烈的场景，但可能带来性能问题和死锁风险。EF Core 本身不直接支持悲观并发，通常需要通过执行原始 SQL 语句来实现

// 示例：在事务中使用 UPDLOCK 查询并更新:cite[1]
using (var transaction = _context.Database.BeginTransaction())
{
    // 使用原生 SQL 查询并加锁
    var house = _context.Houses
        .FromSqlRaw("SELECT * FROM T_Houses WITH (UPDLOCK) WHERE Id = {0}", id)
        .FirstOrDefault();

    if (house != null)
    {
        // ... 执行你的业务逻辑和更新 ...
        house.Owner = newOwner;
        _context.SaveChanges();
    }
    transaction.Commit();
}

其他优化建议

及时处理 DbContext：DbContext 非线程安全。在多线程或异步环境中（如 ASP.NET Core Web API），务必确保每个操作使用独立的 DbContext 实例。通常通过依赖注入（AddDbContextPool）容器注册为 Scoped 生命周期即可，每个 HTTP 请求都会获得一个自己的实例。
考虑使用异步操作：使用 SaveChangesAsync() 等方法可以提高高并发场景下的应用响应能力和吞吐量。
评估批量操作：对于大量数据的更新或插入，考虑使用批量操作来减少数据库往返次数，提升性能。

总结

选择哪种并发控制策略，主要取决于你的具体业务场景和对数据一致性的要求程度。

首选乐观并发：对于大多数 Web 应用，乐观并发通常是更合适的选择。它扩展性更好，避免了长期持有数据库锁，适合低冲突概率的场景。
慎用悲观并发：仅在数据争用异常激烈、且乐观并发的重试/冲突处理逻辑无法满足严格的业务一致性要求时才考虑。使用时需注意其性能开销和死锁风险。

希望这些信息能帮助你更好地在 ASP.NET Core 应用中处理并发问题。