mongos与shard跨机房rtt高导致路由延迟翻倍，根本原因是每次查询需完整往返（mongos→shard→mongos），网络rtt为硬性下限；实测rtt超15ms必须干预，应将同组mongos与shard部署于同一可用区、使用内网ip直连、禁用bindipall，并对地理数据采用范围分片键前缀以减少跨机房访问。
mongos 与 shard 跨机房 RTT 高，路由延迟直接翻倍
mongos 每次查询都要走“解析路由 → 转发请求 → 等待 shard 响应 → 汇总结果”完整链路，其中网络往返（RTT）是硬性下限。若 mongos 在北京，shard 在广州，实测 ping RTT 稳定在 35ms，那单次简单查询光网络就至少耗掉 70ms——这还没算服务端处理时间。很多团队误以为调大 maxConnsPerHost 或加索引就能解决，其实只是在掩盖物理距离带来的根本瓶颈。
实操建议：
- 用
mtr -r shard-host或ping -c 10 shard-host实测每个 mongos 到各 shard 的稳定 RTT；超过 5ms 就该警惕，超过 15ms 必须干预 - 把同一组 mongos 和它主要服务的 shard 放在同一可用区（AZ），禁止跨 AZ 部署；云厂商内网虽标称“低延迟”，但跨 AZ 实际 RTT 常超预期
- 在
sharding.config.shards中填 shard 的**内网 IP**，而非域名或公网 IP；同时在 shard 的bindIp配置中禁用0.0.0.0，只绑定内网地址，避免流量绕行公网网关 - 若业务已全局分布（如用户分属中美欧），不要强求单集群覆盖，改用多区域独立集群 + 应用层路由（如按用户 region header 分流），比硬扛跨机房延迟更可控
配置服务器（config server）跨机房响应慢拖累整个路由决策
mongos 启动、分片迁移、chunk 拆分等操作都依赖 config server 返回元数据。如果 config server 副本集节点分散在三个不同城市，一次 sh.status() 可能因某个节点响应慢而卡住数秒——这不是 mongos 故障，而是它在等最慢的那个 config 节点返回一致视图。
实操建议：
- config server 副本集必须部署在同一低延迟网络域内（如同一机房或同 AZ），严禁跨地域部署；其副本集优先级、投票权应严格对齐，避免因网络抖动引发不必要的选举
- 检查 mongos 日志是否频繁出现
Failed to refresh metadata from config server或Timed out waiting for config server response；这类错误直指 config server 网络路径异常 - 用
db.adminCommand({ "connPoolStats": 1 })查 mongos 到 config server 的连接状态，确认是否存在长期未释放的 idle 连接或重试堆积
分片键设计放大跨机房读写放大效应
哈希分片键虽能均匀分布数据，但会破坏地理局部性。例如用户 A（上海）和用户 B（旧金山）的订单被哈希后落到同一个 shard（假设在东京），结果两地应用都得跨洋访问东京节点，写入延迟高、读取一致性难保障。这不是分片键“错”，而是没匹配业务访问模式。
当代理已经知道网站路由或内容URL，并且在启动前需要有效的sitemap XML、sitemap索引或robots.txt引用时，请使用sitemap。这是一个发布构件技能，而不是爬虫或SEO平台。
实操建议：
- 若数据天然带地理属性（如
region、country_code），优先用该字段做范围分片键前缀，例如{ region: 1, _id: 1 }，让同一区域数据尽量落在同 shard - 避免纯哈希分片键（如
{ _id: "hashed" }）用于跨地域集群；它均匀但无序，强制所有查询变成广播式 scatter-gather，跨机房开销成倍增加 - 对已有集合重新分片（MongoDB 5.0+ 支持），执行
sh.updateShardKey("db.col", { region: 1, _id: 1 })，注意该操作期间集合不可写，需安排维护窗口
readPreference + readConcern 组合不当加剧跨机房负载不均
设为 secondaryPreferred 并不能缓解跨机房压力，反而会让远端 Secondary 承担本不该由它处理的读流量。比如北京 mongos 把读请求发给广州 shard 的 Secondary，不仅没降低延迟，还占用了该节点本该用于拉取 oplog 的 I/O 和 CPU，导致复制延迟飙升，进而影响故障切换可靠性。
实操建议：
- 跨机房场景下，**禁用**
secondaryPreferred和nearest；统一使用primary，确保写一致性和读最新性，再通过应用层就近部署 mongos 来压低 RTT - 必须显式指定
readConcern: "majority"，防止 mongos 因网络分区误连到“假主”后返回未同步数据；w: "majority"写入也必须配套，否则语义矛盾 - 若真需读从节点，改用
readConcern: "available"+readPreference: "secondary"，它允许读取尚未提交 majority 的数据，但不会干扰 oplog 复制通道——这是唯一能兼顾低延迟与复制稳定的组合
跨机房延迟优化中最容易被跳过的动作，是验证 mongos 是否真的连到了预期的 shard IP。很多配置写了内网地址，但 DNS 缓存、容器网络插件或云厂商安全组策略可能悄悄把流量导向了公网出口。上线前务必用 db.currentOp({ "secs_running": { "$gt": 2 } }) 结合 netstat -tnp | grep mongos 抓实时连接目标，眼见为实。
