Secondary读取延迟无法靠ReadPreference自动规避，它只管路由，不管数据新不新；真正能约束延迟的只有maxStalenessSeconds，但必须≥90秒且依赖时钟同步。
Secondary读取延迟无法靠ReadPreference自动规避，它只管路由，不管数据新不新；真正能约束延迟的只有maxStalenessSeconds，但必须≥90秒且依赖时钟同步。
为什么secondaryPreferred会返回明显过期的数据
因为secondaryPreferred只是告诉驱动：“优先发给从节点，没从节点再找主节点”，它完全不检查那个从节点的数据是否落后。哪怕某secondary节点的lastWrite.opTime.ts比主节点晚了5秒，只要它心跳正常、拓扑里标着SECONDARY，驱动就照发不误。
常见错误现象：
- 用户刚提交订单，立刻查“我的订单”列表却看不到——用了
secondaryPreferred但没配maxStalenessSeconds - 监控显示从节点
optime只差200ms，但应用实际读到的数据滞后2秒以上——网络抖动或oplog重放卡顿未被ReadPreference感知 - 阿里云MongoDB控制台显示“复制延迟0ms”，但应用仍读到旧值——控制台延迟是平均值，单次查询可能命中刚同步中断的节点
maxStalenessSeconds不是万能开关，有硬性限制
maxStalenessSeconds确实能筛掉明显落后的节点，但它不是“越小越好”：
- 值必须≥90秒，设成
60会被驱动静默忽略，所有secondary照常参与读负载 - 依赖各节点本地时间准确，若从节点系统时间比主节点快40秒，即使数据最新，也会被判定为“超龄”而剔除
- 驱动靠定期发
isMaster请求获取lastWrite时间戳，两次探测之间存在窗口，无法实时反映当前延迟 - 在多机房部署中，
nearest模式选的是网络延迟最低的节点，和maxStalenessSeconds无关——可能选到一个快但旧的节点
什么场景该用primary而不是secondary
不是看QPS压不压得动主节点，而是看业务能否容忍“写后读不到”：
- 账户余额、库存数量、订单状态变更后的立即校验——必须用
readPreference=primary，哪怕只差100ms也不行 - 事务内所有读操作强制走
primary，否则直接报错；readConcern=majority可配合使用，但它只保证已提交到多数节点，不解决“刚写完还没传播”的问题 - 后台报表、日志归档、历史数据导出——可用
secondary，但要确认业务方接受分钟级延迟 - 混合流量下，别全局设
secondaryPreferred，而是在具体查询时临时指定：collection.find(query).readPreference('secondary')
生产环境配置建议
不要只改连接字符串里的readPreference参数，要结合运行时可观测性和降级逻辑：
- 连接字符串示例：
mongodb://host1:27017,host2:27017/db?replicaSet=rs0&readPreference=secondaryPreferred&maxStalenessSeconds=120 - Node.js驱动中显式设置更可控：
readPreference: ReadPreference.SECONDARY_PREFERRED+maxStalenessSeconds: 120 - 所有
secondary类策略下，必须预设降级路径：从节点全不可用时，是报错还是切回primary？驱动默认报错，需代码层捕获NotReadablePrimary并重试 - 阿里云MongoDB中，注意“只读节点”（Read-only Node）是独立于副本集
secondary的特殊类型，readPreference不对其生效，需单独配置路由
真正难的不是配对参数，而是厘清每条查询背后的数据一致性契约——延迟本身不可怕，可怕的是你不知道它会发生在哪里、持续多久、影响谁。
