hedged reads是mongodb 4.4引入的并发读优化机制，通过向多个副本节点并行发送读请求、采用首个返回结果并取消其余请求，降低尾部延迟；它不改变一致性语义，依赖客户端显式配置、readpreference非primary、驱动及服务端版本达标等前提。
hedged reads 是什么，为什么 MongoDB 4.4 要加它
MongoDB 4.4 引入 hedged reads（对冲读取），本质是让一次读请求同时发给多个副本节点，谁先返回就用谁的结果，其余请求被自动取消。它不改变一致性语义（仍遵循 readConcern 和 readPreference），只优化“慢节点拖累整体延迟”的问题——尤其在跨机房、磁盘抖动或网络拥塞时，尾部延迟（p99/p999）常被单个慢副本拉高。
这不是重试机制，也不是负载均衡；它是并发发起 + 早返回 + 自动中止，底层依赖 WiredTiger 的可中断读操作。
如何开启 hedged reads：必须满足的三个前提
hedged reads 不是开关一开就生效，它依赖客户端、服务端和部署三者的协同：
-
readPreference必须设为nearest、secondaryPreferred或primaryPreferred（primary不支持，因为只有一份数据） - 客户端驱动版本 ≥ 4.2（Node.js 驱动需 3.6+，Python PyMongo 需 3.11+），且显式启用该特性
- 副本集所有成员必须运行 MongoDB 4.4+，且
enableMajorityReadConcern已开启（默认开启）
示例（Node.js）：
const client = new MongoClient(uri, {
readPreference: 'secondaryPreferred',
hedge: { enabled: true } // 关键：必须显式传入
});
注意：hedge: { enabled: true } 是客户端配置项，服务端无对应全局开关；没配这个，服务端压根不会发对冲请求。
Smart Ledger
下载
智能收支追踪器 — 通过自然语言快速记账，自动分类，生成日/周/月报告和趋势分析。 支持中文自然语言输入("今天午饭花了35元")，数据本地JSON存储保护隐私。 适用于个人财务管理、预算追踪和消费分析场景。
hedged reads 的实际行为与常见误判
它不会让你的查询变快，而是降低“偶尔特别慢”的概率。真实表现受以下因素直接影响：
- 并发请求数由驱动自动控制（目前固定为 2，即主请求 + 1 个对冲请求），不可调
- 对冲请求只发给符合
readPreference规则且通过心跳检测为“可达”的节点，不会发给 lag > 10s 的 secondary - 如果 primary 响应极快，secondary 的对冲请求可能还没到服务端就被 cancel —— 所以你未必能在 mongod 日志里看到它的痕迹
- 不兼容
maxTimeMS：一旦设置maxTimeMS，hedge自动禁用（因逻辑冲突）
常见误判现象：
- 看监控发现延迟没降：可能你的 workload 本来就没有明显尾部，或网络/磁盘足够稳，对冲没触发收益
- 查看
db.currentOp()没看到多条相同 op：正常，对冲请求被快速 cancel 后不会长期滞留 - 在
primary上查慢日志发现大量 “read”：说明对冲没生效，检查客户端是否漏配hedge或readPreference是否为primary
生产环境要注意的隐蔽限制
hedged reads 在副本集里有效，但在分片集群中仅作用于单个 shard 内部（即每个 shard 自己做对冲），shard router（mongos）不参与、也不感知。这意味着：
- 如果慢点出在 mongos 到 shard 的链路上，对冲无效
- 使用
readConcern: "majority"时，对冲请求仍会等 majority commit，但只要有一个节点完成即可返回，所以仍能缓解 slow majority 节点的影响 - 开启后，secondary 节点的读 QPS 会上浮约 10–20%（取决于流量分布），要提前评估 CPU 和网络带宽余量
真正容易被忽略的一点：它无法绕过逻辑锁或长事务阻塞。如果某 secondary 正在回放一个大 oplog，或者被本地长时间写操作 hold 住读锁，对冲请求同样会卡住 —— 这时候需要结合 slowms 和 currentOp 排查，而不是指望对冲来兜底。
