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