ReadPreference 是 MongoDB 的读请求路由策略，仅决定请求发往主/从/最近节点，不感知或控制复制延迟；maxStalenessSeconds 可限制滞后，但须 ≥90 秒且时钟同步。
ReadPreference 是什么，为什么它不解决复制延迟
ReadPreference 只是告诉 MongoDB 驱动往哪个节点发读请求（主节点、从节点、最近节点等），它本身不感知复制延迟，也不做延迟判断。即使你设成 secondaryPreferred，驱动照样把请求发给一个刚落后 3 秒的从节点——只要它在线、健康、在拓扑里被标记为 SECONDARY。
常见误解是“切到 secondary 就能自动避开延迟”，实际不是。延迟由 oplog 同步速度、网络、从节点负载共同决定，ReadPreference 只是路由策略。
- 主节点写入后，oplog 条目需经网络传输、解析、重放，这个过程不可控
- 从节点心跳响应时间（
pingMs）影响“最近节点”选择，但和数据新鲜度无关 - 驱动默认不校验从节点的最新
optime，除非你手动启用maxStalenessSeconds
maxStalenessSeconds 能拦住明显落后的从节点吗
可以，但有硬性前提：maxStalenessSeconds 必须 ≥ 90 秒，且集群所有节点时钟必须基本同步（误差
它的原理是：驱动定期向各节点发 isMaster 请求，拿到每个节点的 lastWrite.opTime.ts 和本地时间，算出该节点“最多落后多少秒”。若超过 maxStalenessSeconds，就从候选列表中剔除。
- 设
maxStalenessSeconds: 120，某从节点optime比主节点晚 150 秒 → 不参与读负载 - 设
maxStalenessSeconds: 60→ 驱动静默忽略，所有 secondary 全部可用 - 时钟不同步会导致误判：从节点时间比主节点快 40 秒，即使数据最新，也可能被判定为“超龄”
什么时候该用 primaryPreferred 而不是 secondaryPreferred
不是看“要不要分担读压力”，而是看“读结果是否允许短暂不一致”。如果业务逻辑依赖强一致性（比如查刚下的订单、改完立刻展示新状态），就必须走 primary；哪怕只差 100ms，secondary 也可能返回旧值。
- 用户登录态变更后立即查权限 → 用
primaryPreferred或直接primary - 商品详情页的浏览量、评论数（允许秒级延迟）→
secondaryPreferred安全 - 聚合报表类查询（数据源本身已滞后）→
nearest更合适，降低网络跳转开销 -
primaryPreferred在主挂掉时自动降级到 secondary，适合容忍短暂脏读的后台任务
真正缓解延迟影响的实操手段
靠 ReadPreference 调整只是表层，关键得配合应用层控制和运维干预：
- 对关键读操作显式指定
readConcern: "majority"（需副本集开启 journal），确保读到已多数提交的数据（但会增加延迟） - 写操作后加
writeConcern: { w: "majority" }，让写入阻塞到多数节点落盘，缩小后续读的窗口期 - 监控
repl Lag（通过rs.printSecondaryReplicationInfo()或 Cloud Manager），当持续 > 2 秒时告警并人工介入 - 避免在从节点上执行耗时聚合或大范围扫描，这类操作会拖慢 oplog 应用线程
复制延迟本质是分布式系统天然权衡，没有开关一按就消失。最常被忽略的是：应用没区分“最终一致”和“读己之写”场景，却统一配了 secondaryPreferred。
