C#怎么实现读写分离_C# EF Core读写分离配置方法教程【高级】

时间：2026-07-20

EF Core 本身并不支持读写分离，这一点很多人一开始就踩了坑。硬切连接字符串或全局拦截 SQL 的做法，看似简单，实则隐患重重——事务一致性容易破坏，连接复用异常频繁发生，主从延迟问题也时不时冒出来。真正靠谱的方案，其实是在 DbContext 实例化的那一刻，就把读写路由确定下来，而不是在运行时动态修改 Connection.ConnectionString。

为什么不能在 DbContext 创建后切换 ConnectionString

原因在于，EF Core 的 DbContext 在首次访问 Database.GetDbConnection() 或执行命令时，会缓存连接对象。后续再修改 ConnectionString，旧连接不会自动关闭，新连接池的复用逻辑也不会触发。典型的表现就是：第一次查询走了从库，第二次却还是用主库连接，日志里一看，连接池 ID 根本没变；或者 Sa veChanges() 时抛出 Invalid operation on a closed connection 的异常，因为手动关闭后没正确重新打开；更头疼的是，在 ASP.NET Core 的 Scoped 生命周期中，AsyncLocal 标记失效，导致读操作误走主库。归根结底，EF Core 的设计哲学是，一个 DbContext 实例对应一个稳定的数据源，它压根就没打算让你换库。

注册两个独立的 DbContext 类型（推荐）

最可控、也最易调试的方式，就是定义 WriteDbContext 和 ReadDbContext 两个类，都继承自同一基类（比如 AppDbContextBase），共享 OnModelCreating 配置，但各自绑定固定的连接字符串。这样做的好处是，读写分离的边界在代码层面就清晰了，不会出现模棱两可的情况。

关键点在于：

在 Program.cs 中分别注册，生命周期统一为 Scoped：
builder.Services.AddScoped(sp => new WriteDbContext(builder.Configuration.GetConnectionString("MasterDb")))
builder.Services.AddScoped(sp => new ReadDbContext(builder.Configuration.GetConnectionString("Sla veDb")))
仓储接口必须拆开：IUserWriteRepository 依赖 WriteDbContext，IUserReadRepository 依赖 ReadDbContext，从源头上杜绝开发人员误用从库执行 Add() 操作的可能性。
千万不要共用同一个 DbSet 实例——两个上下文里的 Users 属性只是同名，底层连接完全隔离，互不干扰。

用 IDbContextFactory 动态选库（适合多从库或灰度场景）

当需要根据用户地域、租户 ID 或负载情况选择不同从库时，IDbContextFactory 比硬编码两个类型更灵活，也更容易扩展。

实操要点如下：

工厂实现里不做 SQL 解析，而是基于调用上下文判断：
— 若当前方法标记了 [Write] 特性 → 返回主库配置的上下文
— 若请求头含 X-Force-Master: true → 强制返回主库
— 否则随机选一个从库连接字符串构造上下文
务必禁用 DbContext 的默认 DI 注册，否则工厂和容器注入会冲突，导致意想不到的行为。
连接字符串要带明确超时与重试策略：Sla veDb 可设 Command Timeout=30，MasterDb 设 Command Timeout=60 并启用 EnableRetryOnFailure()，确保在数据库压力下也能稳定运行。