本文详解为何 `mgo.monotonic` 模式在实际应用中未能实现预期的读负载均衡，并指出根本原因在于会话复用导致写操作后会话永久绑定主节点；提供符合最佳实践的会话管理方案，确保读请求真正分发至 primary 和 secondary 节点。
在使用 mgo 驱动连接 MongoDB 副本集时，开发者常期望通过 mgo.Monotonic 读模式实现「读写分离 + 负载均衡」：即写操作走 Primary，读操作自动轮询 Primary 或任意可用 Secondary，从而分散 CPU 和网络压力。但如问题所示，实测中 Secondary 节点几乎无负载，Primary 却持续高占用——这并非 Monotonic 失效，而是会话（Session）生命周期管理不当所致。
根本原因：全局复用 Session 导致「写后锁主」
mgo.Monotonic 的语义是：会话首次执行读操作时可选 Secondary，但一旦发生写操作（如 Insert、Update），该会话将立即且永久切换至 Primary，并后续所有读也强制走 Primary。这是为保障单调读（monotonic read）一致性：避免“先读到旧值（Secondary），再读到新值（Primary）”的乱序现象。
而在原代码中，关键错误在于：
func prepareMartini() *martini.ClassicMartini {
m := martini.Classic()
sessionPerRequest := GetMgoSessionPerRequest() // ❌ 错误：仅启动时创建一次！
m.Get("/insert", func(w http.ResponseWriter, r *http.Request) {
// 使用 sessionPerRequest —— 第一次写后，它就永远绑定 Primary
})
m.Get("/get", func(w http.ResponseWriter, r *http.Request) {
// 同样使用 sessionPerRequest —— 此时已锁定 Primary，读不下发到 Secondary
})
}由于 sessionPerRequest 是在服务器启动时一次性生成并被所有 HTTP 处理器闭包共享，/insert 接口的首次写操作便使该会话「升主」；此后 /get 所有请求均复用此已升主的会话，自然全部打向 Primary，Secondary 彻底闲置。
正确做法：每次请求独立 Copy Session
解决方案非常明确：禁止跨请求复用 Session，每个 HTTP 请求必须调用 mainSessionForSave.Copy() 创建全新会话实例。这样，/get 请求的会话从未执行过写操作，始终保有选择 Secondary 的自由度；而 /insert 的会话虽升主，但其生命周期随请求结束而释放，不影响后续读请求。
修正后的处理器示例如下：
m.Get("/insert", func(w http.ResponseWriter, r *http.Request) {
session := mainSessionForSave.Copy() // ✅ 每次请求新建会话
defer session.Close() // ⚠️ 务必关闭，避免连接泄漏
coll := collection(session)
for i := 0; i < elementsCount; i++ {
e := Element{I: i}
if err := coll.Insert(&e); err != nil {
http.Error(w, "Insert failed: "+err.Error(), http.StatusInternalServerError)
return
}
}
w.Write([]byte("data inserted successfully"))
})
m.Get("/get", func(w http.ResponseWriter, r *http.Request) {
session := mainSessionForSave.Copy() // ✅ 独立会话，未写过，可读 Secondary
defer session.Close()
var element Element
const findI = 500
coll := collection(session)
if err := coll.Find(bson.M{"I": findI}).One(&element); err != nil {
http.Error(w, "Find failed: "+err.Error(), http.StatusInternalServerError)
return
}
w.Write([]byte("get data successfully"))
})? 验证提示：部署后再次用 vegeta 压测 /get，同时在三台 MongoDB 节点上运行 mongostat --host ipX:portX，可清晰观察到 query 指标在 Primary 和 Secondary 上均有稳定增量，CPU 负载趋于均衡。
注意事项与进阶建议
- Copy() 成本极低：mgo.Session.Copy() 仅复制会话元数据（如读偏好、超时设置），不建立新 TCP 连接，底层复用连接池，性能无负担。
- 必须调用 Close()：每个 Copy() 出来的会话都需显式 defer session.Close()，否则连接池耗尽将导致后续请求阻塞或超时。
- 慎用 SetSafe / SetSyncTimeout：若业务强依赖强一致性（如金融场景），应结合 mgo.Strong 模式（强制 Primary 读），而非依赖 Monotonic 的弱一致性保证。
- 警惕网络分区风险：如答案中引用的 Jepsen 分析 所示，即使配置正确，MongoDB 在极端网络分区下仍可能出现陈旧读（stale reads）或回滚写。对强一致性敏感的业务，应考虑 findAndModify 或事务（v4.0+）替代简单读写分离。
- 升级替代方案：mgo 已停止维护，生产环境推荐迁移到官方驱动 mongo-go-driver，其 ReadPreference API 更清晰（如 readpref.SecondaryPreferred()），且内置连接池与上下文取消支持，安全性与可观测性更优。
遵循「每次请求独立会话」原则，mgo.Monotonic 将真正发挥其设计价值：在最终一致性的合理边界内，高效分担读负载，让副本集资源物尽其用。
