Hedged Reads不是加速器而是稳定器，通过并发发往多个副本集成员取最快响应来降低长尾延迟；仅secondaryPreferred、secondary、nearest和primaryPreferred（主不可用时）触发，primary模式不生效。
hedged reads 不是让查询变快的“加速器”，而是降低长尾延迟的“稳定器”——它在 MongoDB 5.0 中的行为逻辑与 4.4 一致，但兼容性更稳、监控路径更清晰。启用后，你不会看到平均延迟下降，但 P99/P999 延迟曲线会明显收窄。
哪些 readPreference 模式真正触发 hedged reads
只有非 primary 模式才可能发起对冲请求：
- secondaryPreferred：最常用，主不可用时 fallback 到 secondary，此时对冲生效
- secondary：强制读从节点，对冲必然触发（只要满足可达性）
- nearest：默认启用对冲，且会按延迟阈值选多个候选节点参与对冲
- primaryPreferred：主可用时不对冲；主短暂不可达切换到 secondary 后，后续请求才可能对冲
primary 模式下完全不触发，哪怕显式配置 hedge: { enabled: true } 也会被忽略。
为什么 mongod 日志里看不到对冲请求
对冲请求是否落地，取决于“主响应速度”和“网络往返时间”：
- 如果 primary 在 10–20ms 内返回，对冲请求很可能还没抵达 secondary 的 mongod 就被客户端取消
- 对冲请求只发给心跳检测中 stateStr === "SECONDARY" 且 lastHeartbeatRecv 在 10 秒内的节点；lag > 10s 的 secondary 被自动排除
- maxTimeMS 一设，hedge 自动禁用——因为超时逻辑与对冲的“谁先到谁胜出”冲突
所以别依赖日志查对冲是否发生，改用 db.currentOp({ "secs_running": { "$gt": 1 } }) 观察是否有并发同 queryHash 的读操作残留。
事务内或写关注不匹配时 hedge 失效的典型表现
- 任何带 session.startTransaction() 的读操作，即使配置了 hedge，也会直接报错：CommandNotSupportedOnServer
- 使用 readConcern: "local" 时，对冲可能返回不同版本文档（比如一个节点刚写入未同步，另一个已同步），这不是 bug，是行为预期
- 生产环境应搭配 readConcern: "majority" 或至少 "available"，否则一致性边界无法收敛
副本集配置不当导致 hedge 形同虚设
- 所有 secondary 节点若都设为 priority: 0 或 hidden: true，它们不会出现在 readPreference 的候选列表中，自然也不会被选为对冲目标
- members[n].votes: 0 不影响对冲读（只影响选举投票），但若同时设 priority: 0 + hidden: true，该节点就彻底“隐身”了
- 延迟节点（secondaryDelaySecs > 0）默认被排除在对冲之外——因为它既不可用于实时读，也不满足 lastAppliedWallTime 新鲜度要求
真正起作用的，永远是那个“在线、非隐藏、priority > 0、lag
