通过Entity Framework Core进行数据库事务管理与并发冲突处理

通过Entity Framework Core进行数据库事务管理与并发冲突处理：从基础到实战避坑指南

大家好，作为一名常年和数据库打交道的开发者，我深知事务和并发控制是构建健壮应用的两大基石。在使用 Entity Framework Core (EF Core) 时，这两者更是绕不开的话题。今天，我想结合自己的实战经验，和大家深入聊聊如何在 EF Core 中优雅地管理事务，并妥善处理那些令人头疼的并发冲突。我会分享一些标准做法，也会提到我踩过的一些“坑”，希望能帮你少走弯路。

一、理解EF Core的事务基础：不止一种选择

EF Core 默认情况下，对 SaveChanges 或 SaveChangesAsync 的每次调用都会自动创建一个事务，并在所有操作成功完成后提交。这对于单个 DbContext 实例内的简单操作足够了。但现实中的业务逻辑往往更复杂，比如需要跨多个 DbContext 实例，或者在一个逻辑单元里执行多个 SaveChanges。这时，我们就需要显式地控制事务。

EF Core 提供了两种主要的事务管理方式：

1. 默认事务： 如前所述，开箱即用，但范围有限。

2. 使用 TransactionScope： 这是一种分布式事务的轻量级方案，可以跨越多个数据库连接甚至资源管理器。但在现代云原生或微服务架构中，由于其依赖 MSDTC（微软分布式事务协调器），复杂性高且跨服务不可靠，我个人已很少在新项目中使用。

3. 使用 DbContext.Database.BeginTransaction： 这是我最推荐，也是最常用的方式。它允许你显式地开始一个事务，并在同一个数据库连接上执行多个操作，最后统一提交或回滚。

二、实战：使用 BeginTransaction 管理复杂业务逻辑

假设我们有一个经典的“银行转账”场景：从账户A扣款，向账户B加款。这两个操作必须作为一个原子单元。

// 示例使用 .NET 6+ 及 EF Core 6+
using var context = new BankDbContext();
// 1. 开始事务
using var transaction = await context.Database.BeginTransactionAsync();

try
{
    var accountA = await context.Accounts.FindAsync(1);
    var accountB = await context.Accounts.FindAsync(2);

    if (accountA.Balance >= 100m)
    {
        accountA.Balance -= 100m;
        accountB.Balance += 100m;

        // 2. 执行数据操作
        await context.SaveChangesAsync(); // 此时操作在事务中，但未提交

        // 3. 提交事务
        await transaction.CommitAsync();
        Console.WriteLine("转账成功！");
    }
    else
    {
        Console.WriteLine("余额不足！");
        // 可以不显式回滚，因为 using 块结束时会自动回滚未提交的事务。
        // 但显式调用可以让意图更清晰。
        await transaction.RollbackAsync();
    }
}
catch (Exception ex)
{
    // 4. 异常处理与回滚
    // 实际项目中，这里需要更精细的异常分类处理（如并发冲突、超时等）
    Console.WriteLine($"转账失败，已回滚: {ex.Message}");
    // Rollback 在发生异常时通常不是必须的（using 会处理），但加上是良好实践。
    await transaction.RollbackAsync();
    throw; // 或进行其他处理
}
// using 语句确保 transaction 和 context 被正确释放。

踩坑提示： 务必使用 using 语句或确保在 finally 块中正确处理事务和 DbContext 的生命周期。我曾遇到过因为异常导致事务未释放，进而引起数据库连接池耗尽的问题。另外，SaveChangesAsync 后如果不提交，数据并不会真正持久化到数据库。

三、并发冲突：乐观锁与悲观锁的抉择

当多个用户或进程同时尝试更新同一行数据时，并发冲突就发生了。EF Core 主要支持乐观并发控制。

乐观并发假定冲突不常发生，允许先读取和修改，在保存时检查数据是否被他人改动过。如果被改动，则抛出 DbUpdateConcurrencyException。

如何配置乐观并发？

最常用的方法是将一个属性标记为并发令牌（Concurrency Token）。EF Core 在 UPDATE 语句的 WHERE 子句中包含此令牌的值，如果受影响的行数为0，就知道数据已经变了。

public class Blog
{
    public int Id { get; set; }
    public string Title { get; set; }
    public string Content { get; set; }

    // 方法一：使用 [Timestamp] 属性（数据库 rowversion/timestamp 类型）
    [Timestamp]
    public byte[] RowVersion { get; set; }

    // 方法二：使用 IsConcurrencyToken 流畅API配置一个普通字段
    // 例如一个最后更新时间的字段
    // 在 OnModelCreating 中： builder.Property(e => e.LastUpdated).IsConcurrencyToken();
}

我更喜欢使用 byte[] RowVersion 配合 [Timestamp]，因为 SQL Server 的 rowversion 类型会在每次行更新时自动生成新值，非常可靠。

四、处理 DbUpdateConcurrencyException：一个完整的解决流程

检测到冲突只是第一步，如何处理它才是关键。通常有以下策略：

1. 客户端获胜（强制覆盖）： 不推荐，会导致他人修改丢失。

2. 数据库获胜（放弃当前更改）： 重新加载实体，用数据库的值覆盖当前值。

3. 合并获胜（自定义合并策略）： 这是最实用、最友好的方式。尝试合并当前更改和他人的更改。

public async Task UpdateBlogAsync(int blogId, string newTitle, string newContent)
{
    var blog = await _context.Blogs.FindAsync(blogId);
    if (blog == null) { /* 处理未找到 */ }

    blog.Title = newTitle;
    blog.Content = newContent;

    try
    {
        await _context.SaveChangesAsync();
    }
    catch (DbUpdateConcurrencyException ex)
    {
        // 重点：重新加载数据库当前值
        // ReloadAsync 会用数据库中的值覆盖 blog 实体的属性值（包括 RowVersion）
        await ex.Entries.Single().ReloadAsync();

        // 获取当前用户尝试保存的值（存在于原始值中）
        var entry = _context.Entry(blog);
        var databaseValues = await entry.GetDatabaseValuesAsync();
        if (databaseValues == null)
        {
            throw new Exception("要更新的记录已被删除！");
        }

        var databaseBlog = (Blog)databaseValues.ToObject();

        // 自定义合并逻辑：例如，标题以当前用户输入为准，内容合并
        blog.Title = newTitle; // 我们的标题优先级高
        blog.Content = $"{databaseBlog.Content}n--- 合并更新 ---n{newContent}"; // 合并内容

        // 再次尝试保存（此时 RowVersion 已更新，会生成新的 UPDATE）
        await _context.SaveChangesAsync();
        Console.WriteLine("数据已合并更新。");
    }
}

实战经验： 处理并发异常时，一定要调用 ReloadAsync() 或 GetDatabaseValuesAsync() 来获取最新的数据库状态。直接重试 SaveChanges 而不刷新实体是无效的，因为 WHERE 子句中的旧令牌值依然没变。合并策略需要根据具体业务来设计，可能需要向用户展示冲突并让其决定。

五、事务与并发控制的结合使用

在实际场景中，事务和并发控制常常需要一起工作。例如，在一个事务内处理多个实体的更新，而这些实体都可能面临并发冲突。

using var transaction = await _context.Database.BeginTransactionAsync();
try
{
    // ... 一些业务操作，修改多个实体
    await _context.SaveChangesAsync(); // 这里可能抛出 DbUpdateConcurrencyException

    // ... 可能还有其他的业务操作和 SaveChanges
    await transaction.CommitAsync();
}
catch (DbUpdateConcurrencyException ex)
{
    await transaction.RollbackAsync();
    // 这里可以调用上面提到的并发冲突处理逻辑
    // 并可能决定是否重试整个事务
    throw new RetryableException("并发冲突，请重试操作", ex);
}
catch (Exception ex)
{
    await transaction.RollbackAsync();
    throw;
}

重要提醒： 一旦在事务中捕获到并发异常并回滚，所有在该事务内修改的实体状态都会变得复杂。最佳实践是丢弃当前的 DbContext 实例，创建一个新的实例来重试整个业务逻辑单元。试图在同一个 DbContext 里继续操作很容易导致状态不一致。

总结与最佳实践

1. 明确范围： 对于单个 SaveChanges，相信 EF Core 的默认事务。对于跨多个操作或 DbContext 的复杂单元，使用 BeginTransaction。

2. 生命周期管理： 始终使用 using 或 try-finally 确保事务和上下文被妥善释放。

3. 拥抱乐观并发： 对于大多数 Web 应用，乐观并发是性能与正确性的最佳平衡。优先使用 rowversion 作为并发令牌。

4. 设计友好的冲突解决： 不要简单地覆盖或丢弃。实现合并逻辑或提供界面让用户选择，提升用户体验。

5. 隔离与重试： 发生并发冲突并回滚事务后，考虑使用新的 DbContext 进行重试。对于高并发场景，可以结合指数退避等重试策略。

事务和并发处理是数据库编程的深水区，但理解其原理并善用 EF Core 提供的工具，就能构建出既可靠又高效的数据访问层。希望这篇文章能帮助你更有信心地面对这些挑战。编码愉快！