Secondary读必然延迟，因oplog同步链路存在固有耗时；监控lag为0不等于实时，maxStalenessSeconds仅过滤候选节点且最小90秒；账户余额、库存等强一致性场景必须primary读；slaveDelay是人为设定的备份滞后，非故障延迟。
有延迟，而且这个延迟不是“偶尔出现”，而是副本集架构的固有特性——只要用secondary或secondaryPreferred读，就必然面临数据滞后风险。
为什么 secondary 读一定会延迟
Secondary 节点靠重放主节点的oplog同步数据，整个链路包含：主节点写入 → oplog落盘 → 网络传输 → 从节点拉取 → 解析执行。每一步都耗时，哪怕只有几十毫秒，也足以让“刚写完就查”失败。
- 监控显示
lag (secs)为 0，并不等于实时——那是平均值或快照，单次查询可能命中刚卡住的节点 -
rs.printSlaveReplicationInfo()输出的延迟是估算值，实际落后可能更大（比如网络抖动、oplog重放被长查询阻塞） - 阿里云控制台标“复制延迟0ms”，只代表心跳正常，不代表你发过去的那条
find()能读到最新_id
maxStalenessSeconds 不是“延迟开关”，而是“筛选阈值”
maxStalenessSeconds不会让 secondary 变快，它只在驱动选节点时过滤掉明显落后的成员——但有硬约束：
- 值必须 ≥90 秒，设成
30或60会被驱动静默忽略，所有 secondary 照常接流量 - 依赖各节点本地时间准确，若 secondary 系统时间比 primary 快 40 秒，即使数据最新，也会被踢出候选池
- 驱动靠周期性
isMaster请求获取lastWrite时间戳，两次探测之间存在窗口，无法实时感知当前 lag -
nearest模式选的是网络延迟最低的节点，和maxStalenessSeconds无关——可能选到一个快但旧的节点
哪些场景必须用 primary 读
不是看“能不能扛住读 QPS”，而是看业务是否允许“写后读不到”：
- 账户余额变更、库存扣减、订单状态更新后的立即校验——必须用
readPreference=primary，100ms 延迟也不行 - 事务内所有读操作强制走
primary，否则直接报错；readConcern=majority只能保证已提交到多数节点，不解决“刚写完还没传播”的问题 - 混合流量下，别全局设
secondaryPreferred，而是在具体查询时临时指定：collection.find(query).readPreference('secondary')
延迟节点（slaveDelay）和读延迟不是一回事
配置了slaveDelay: 3600的节点，是**故意设计成滞后一小时**的备份节点，它和普通 secondary 的“意外延迟”完全不同：
- 必须配合
hidden: true和votes: 0，否则可能被误选为 primary，导致写入直接发生在这个延迟节点上 - 不能用
rs.reconfig()动态修改已有节点的slaveDelay，MongoDB 会拒绝，必须rs.remove()再rs.add()重建 - 真实延迟 = 网络传输 + oplog 回放耗时 +
slaveDelay值，所以实际滞后通常略大于设定值
真正难处理的，是那些没配maxStalenessSeconds、又没意识到secondaryPreferred完全不管数据新旧的业务查询——它们在压测时一切正常，上线后用户刚下单就查不到，问题藏得深，复现靠运气。
