并发冲突是 EF Core 里最容易被忽视、出了事又最难排查的问题之一。这篇文章聊聊它的机制、怎么配置乐观锁、冲突异常怎么处理。
问题背景
真实场景:电商平台秒杀活动,同一件商品被多个请求并发扣减库存。业务日志里一切正常,但库存对不上——扣了 100 件,实际库存只减少了 60 件。
排查后发现:
- 多个请求几乎同时读取了库存为 200 的记录
- 各自在内存里把数量减掉后写回
- 数据库里最后一个写入覆盖了前面所有写入的结果
- EF Core 没有报任何错误,因为没有配置并发控制
这就是典型的"丢失更新"(Lost Update)。
原理解析
EF Core 的并发控制模型
EF Core 支持乐观并发,不在读取时加锁,而是在写入时检测:
提交更新时,把当前数据库中读取到的"令牌值"放进 WHERE 条件,如果这行在读取之后被别人改动过,令牌不匹配,受影响行数为 0,EF Core 就会抛出
DbUpdateConcurrencyException。
生成的 SQL 大概长这样:
UPDATE Products
SET Stock = @newStock
WHERE Id = @id AND RowVersion = @originalRowVersion
如果 RowVersion 被别人改过,WHERE 匹配不到,更新语句影响 0 行,EF Core 检测到后抛异常。
两种并发令牌配置方式
方式一:[Timestamp] / IsRowVersion()(推荐)
数据库自动维护,每次行更新时自增,不需要应用层干预:
public sealed class Product
{public int Id { get; set; }public string Name { get; set; } = string.Empty;public int Stock { get; set; }[Timestamp]public byte[] RowVersion { get; set; } = [];
}
或者在 OnModelCreating 里配置:
modelBuilder.Entity<Product>().Property(p => p.RowVersion).IsRowVersion();
方式二:[ConcurrencyCheck](字段级令牌)
不需要专门的版本字段,直接把某个业务字段标为并发令牌:
public sealed class Seat
{public int Id { get; set; }[ConcurrencyCheck]public string? OccupiedBy { get; set; }
}
适合"只要这个字段没被改就允许写"的场景,但精度不如 RowVersion——其他字段改了不会触发冲突检测。
DbUpdateConcurrencyException 的结构
冲突发生时,异常里携带了足够的信息用于决策:
catch (DbUpdateConcurrencyException ex)
{foreach (var entry in ex.Entries){var proposedValues = entry.CurrentValues; // 应用层想写入的值var originalValues = entry.OriginalValues; // 应用层读取时的快照var databaseValues = await entry.GetDatabaseValuesAsync(); // 数据库现在的值}
}
三组值拿到手,才能做出合理的冲突解决策略。
示例代码
基础配置与迁移
public sealed class AppDbContext : DbContext
{public DbSet<Product> Products => Set<Product>();protected override void OnModelCreating(ModelBuilder modelBuilder){modelBuilder.Entity<Product>().Property(p => p.RowVersion).IsRowVersion();}
}
生成迁移后,SQL Server 会把 RowVersion 字段类型映射为 rowversion,PostgreSQL 对应 xmin 系统列(用法略有差异)。
冲突重试:客户端值优先
最常见的处理策略——应用层值直接覆盖数据库值,适合"最后写入者获胜"的运营后台场景:
public async Task UpdateStockAsync(int productId, int newStock, CancellationToken ct)
{const int maxRetries = 3;for (var attempt = 0; attempt < maxRetries; attempt++){try{var product = await db.Products.FindAsync([productId], ct)?? throw new InvalidOperationException($"Product {productId} not found.");product.Stock = newStock;await db.SaveChangesAsync(ct);return;}catch (DbUpdateConcurrencyException ex){if (attempt == maxRetries - 1) throw;// 刷新原始值快照,下一轮用新的 RowVersion 重试foreach (var entry in ex.Entries)await entry.ReloadAsync(ct);}}
}
冲突拒绝:数据库值优先
读取到冲突直接告知调用方,让用户重新决策,适合需要用户确认的场景:
public async Task<ConflictResult?> TryDeductStockAsync(int productId, int quantity, byte[] expectedRowVersion, CancellationToken ct)
{var product = await db.Products.FindAsync([productId], ct)?? throw new InvalidOperationException($"Product {productId} not found.");if (!product.RowVersion.SequenceEqual(expectedRowVersion))return new ConflictResult(product.Stock, product.RowVersion);if (product.Stock < quantity)throw new InvalidOperationException("库存不足");product.Stock -= quantity;try{await db.SaveChangesAsync(ct);return null; // 成功}catch (DbUpdateConcurrencyException){var dbValues = await db.Products.AsNoTracking().FirstAsync(p => p.Id == productId, ct);return new ConflictResult(dbValues.Stock, dbValues.RowVersion);}
}public record ConflictResult(int CurrentStock, byte[] CurrentRowVersion);
冲突合并:自定义字段级融合
拿到三组值后,按业务规则逐字段决策:
catch (DbUpdateConcurrencyException ex)
{foreach (var entry in ex.Entries){var proposed = entry.CurrentValues;var database = await entry.GetDatabaseValuesAsync();if (database is null)throw new InvalidOperationException("记录已被删除,无法合并。");// 用数据库里最新的 Stock,保留应用层改动的 Nameproposed["Stock"] = database["Stock"];// 把原始值快照更新为数据库当前值,下次提交时令牌匹配entry.OriginalValues.SetValues(database);}await db.SaveChangesAsync(ct);
}
总结
EF Core 的乐观并发基于"令牌比对"——写入时把读取时的快照值塞进 WHERE 条件,数据库决定这次更新是否有效。
认识这个机制的关键点有三个:
RowVersion是最省心的配置方式,让数据库自动维护版本DbUpdateConcurrencyException里有三组值,决定了你能做什么样的冲突处理- 冲突策略(重试、拒绝、合并)要结合业务场景选择,没有通用最优解
并发冲突不是 EF Core 的问题,是分布式写入的本质问题。搞清楚它,才能在出事时不慌。
