17370845950

Dapper本身不支持读写分离和多数据源管理，需通过上层代码控制连接字符串分发：写操作用主库，读操作按需路由至从库；可采用仓储层显式指定、接口抽象+DI注入、策略模式实现负载均衡与故障转移，并注意事务一致性、强一致性场景直连主库等关键事项。

Dapper 本身不内置读写分离或多数据源管理能力，它只是一个轻量级的 ORM 工具，负责将 SQL 查询结果映射到 .NET 对象。读写分离和多数据源配置需要在 Dapper 上层通过代码逻辑或结合依赖注入、策略路由等方式实现。核心在于：**控制连接字符串的分发逻辑，让写操作走主库（Master），读操作按需走从库（Slave）**。

基于仓储层手动区分读写连接

最直接的方式是在仓储（Repository）方法中显式指定使用哪个数据库连接。适合中小项目，结构清晰、易于调试。

• 定义两个连接字符串：一个指向主库（支持读写），一个或多个指向从库（只读）
• 在仓储类中注入 IDbConnection 工厂或连接字符串，读操作用从库连接，增删改用主库连接
• 示例伪代码：
  var masterConn = new SqlConnection(_masterConnStr);
  var slaveConn = new SqlConnection(_slaveConnStr);
  // 写
  await masterConn.ExecuteAsync("INSERT ...");
  // 读
  var list = await slaveConn.QueryAsync("SELECT * FROM Users WHERE ...");

通过接口抽象 + 依赖注入动态切换

定义 IReadConnection 和 IWriteConnection 接口，配合 DI 容器绑定不同连接实例，实现解耦。

• 注册时区分作用域：如 AddScoped() 和 AddScoped()
• 仓储构造函数分别接收两个接口，方法内调用对应连接
• 可进一步封装为 DbSession 类，内部持有一个读连接池 + 一个写连接，统一管理生命周期

借助策略模式实现负载均衡与故障转移

当有多个从库时，需考虑轮询、权重、健康检查等。Dapper 不提供这些，但可以自己扩展：

• 维护一个从库连接字符串列表，用简单轮询（Round-Robin）或随机选取
• 添加轻量心跳检测：首次使用前尝试 Open()，失败则剔除并记录日志
• 配合配置中心（如 AppSettings.json 或 Consul）动态刷新从库列表
• 避免在单次请求中混用多个从库连接——应在一个请求上下文内固定使用同一个从库，防止读取到不一致的数据（因主从延迟）

注意事项与常见陷阱

读写分离不是加个从库就万事大吉，几个关键点必须注意：

• 事务内禁止读从库：一旦开启事务（如 BeginTransaction），所有操作必须走同一连接（即主库），否则会报错或丢失一致性
• 强一致性场景强制走主库：例如“注册后立即查询用户”，应跳过读策略，直连主库查，避免查不到刚插入的数据
• 连接字符串管理别硬编码：推荐用 IConfiguration 读取，支持环境区分（开发/测试/生产）
• 别忽略连接泄漏：Dapper 不自动管理连接生命周期，务必确保 using 或 await using 正确释放

基本上就这些。Dapper 的灵活性恰恰在于它不做约定，把决策权交还给开发者——读写分离不是框架功能，而是架构选择；多数据源也不是配置项，而是连接分发策略。只要理清“谁在什么时候用哪个连接”，剩下的就是组合与封装。