sync.RWMutex不能解决数据库读写分离，因其仅用于内存变量同步，不参与SQL路由；真正的读写分离需在数据访问层将SELECT发从库、增删改发主库。
为什么 sync.RWMutex 不能直接解决数据库读写分离
很多人看到“读写分离”就下意识用 sync.RWMutex，但它只管内存里的共享变量同步，和数据库层面的读库/写库路由完全无关。真正的读写分离是数据访问层的事——你要把 SELECT 发给从库，INSERT/UPDATE/DELETE 发给主库，而 sync.RWMutex 压根不参与 SQL 路由决策。
真正要控制的，并发场景下的关键矛盾是：多个 goroutine 同时读从库时是否需要互斥？答案通常是不需要；但当主库写入后触发从库延迟或一致性校验逻辑时，可能得阻塞部分读请求。这时候才轮到并发控制机制介入。
- 读操作（尤其最终一致性场景）可完全并发，无需锁
- 写操作必须串行化或至少保证事务边界内独占，避免主库写乱序
- 如果业务要求“写后立即可读”，需额外加
sync.WaitGroup或 channel 协调，而不是靠RWMutex
如何用 context.Context 控制读写请求的超时与取消
读写分离架构下，主库响应快但从库可能因复制延迟或负载高而变慢。硬编码超时或忽略 cancel 容易拖垮整个请求链路。用 context.WithTimeout 或 context.WithCancel 是更可控的做法。
示例：对从库查询加 500ms 超时，主库写入加 2s 超时
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
// 读从库 ctxRead, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond) defer cancel() rows, err := slaveDB.QueryContext(ctxRead, "SELECT * FROM users WHERE id = ?", id) <p>// 写主库 ctxWrite, cancel := context.WithTimeout(context.Background(), 2*time.Second) defer cancel() _, err := masterDB.ExecContext(ctxWrite, "UPDATE users SET name=? WHERE id=?", name, id)
- 别在 handler 外层用
context.Background()直接传进 DB 操作，丢失 cancel 信号 - 从库超时阈值通常比主库低，因为读失败可降级（如返回缓存或空结果），而写失败一般不可降级
- 注意
database/sql的QueryContext/ExecContext是 Go 1.8+ 才支持，低于此版本需升级或手动控制
如何用 sync.Pool 缓存从库连接避免高频新建
读多写少场景下，频繁建连从库会吃掉大量 fd 和 goroutine。虽然 database/sql 自带连接池，但它的 SetMaxOpenConns 是全局的，无法区分主从。你真正想复用的，是那些已认证、已设置时区/字符集、且处于 idle 状态的从库连接。
sync.Pool 更适合缓存轻量对象，比如封装了从库连接的 *sql.Conn 或自定义的 SlaveSession 结构体：
var slaveConnPool = sync.Pool{
New: func() interface{} {
conn, _ := slaveDB.Conn(context.Background())
return conn
},
}
<p>// 使用
conn := slaveConnPool.Get().(*sql.Conn)
defer slaveConnPool.Put(conn)
rows, _ := conn.QueryContext(context.Background(), "SELECT ...")
- 不要缓存
*sql.DB实例本身——它已是线程安全连接池，缓存它反而绕过内置池管理 -
sync.Pool中的对象可能被 GC 回收，所以每次 Get 后必须检查是否有效（例如调用conn.PingContext） - 若从库有多个实例（比如按地域分片），每个实例应配独立的
sync.Pool，避免混用连接
为什么 atomic.Value 适合缓存读写分离的路由策略
读写分离配置（比如主库地址、从库列表、权重、健康状态）常需要热更新，又不能每次查询都加锁读取。这时 atomic.Value 提供无锁读、低频写的安全方案。
例如把当前生效的从库节点列表存在 atomic.Value 里：
var slaveNodes atomic.Value // 类型为 []string
<p>// 初始化
slaveNodes.Store([]string{"10.0.1.10:3306", "10.0.1.11:3306"})</p><p>// 运行时更新（极少发生）
slaveNodes.Store(newList)</p><p>// 任意 goroutine 并发读取，零开销
nodes := slaveNodes.Load().([]string)
- 写操作必须整块替换，不能做 slice append ——
atomic.Value不支持原子修改内部字段 - 类型断言必须严谨，建议包装成带类型检查的方法，避免 panic
- 它只解决“配置读取”的并发安全，不解决“SQL 路由逻辑”本身——后者仍需你自己实现负载均衡或延迟感知算法
真正难的不是并发原语怎么选，而是怎么定义“读”和“写”的边界：有些 UPDATE 实际上只是幂等状态刷新，完全可以走从库回写；有些 SELECT 因关联了未提交事务，必须强制走主库。这些业务语义，没有标准库能替你判断。
