加mongos节点不能解决突发写流量洪峰，因其仅缓解路由层瓶颈，而真正卡点在于分片键设计不合理、WiredTiger cache压力、journal刷盘争抢IO及config server元数据更新瓶颈。
直接加 mongos 节点不能解决突发写流量洪峰——它只缓解路由层并发瓶颈，而写洪峰真正卡在分片键设计、WiredTiger cache 压力、journal 刷盘和 config server 元数据更新这四条链路上。
分片键设计不合理会导致写热点，加再多 mongos 都没用
写请求根本没机会走到 mongos 路由层，就在客户端或驱动层被集中打到同一个 shard 上。典型表现是：单个 shard 的 CPU 或磁盘 IO 持续 >90%，其他 shard 几乎空闲。
- 避免用
_id（ObjectId）或created_at这类单调递增字段做分片键；它们会让新写入全部落在“末尾 chunk”，形成尾部热点 - 优先选高基数 + 写分布均匀的组合，比如
{"user_id": 1, "event_type": 1}；若必须支持时间范围查询，可用{"region": 1, "created_at": 1}，但要配合sh.status()监控 chunk 均衡度 - Hash 分片（
{"user_id": "hashed"}）能强制打散，但会禁用所有范围查询；上线前必须用真实流量压测验证查询路径是否退化为全分片广播
WiredTiger cache 和 journal 刷盘争抢 IO，是瞬时写卡顿的主因
MongoDB 5.0 的 WiredTiger 引擎在高并发写入下，不是慢在磁盘本身，而是 cache 满了被迫刷脏页 + journal 同步延迟双重挤压。此时 createIndex、moveChunk 或批量 insertMany 都会雪上加霜。
- 检查
wt:cache: bytes currently in the cache是否长期 >90% ofwt:cache: maximum bytes configured；若是，说明 cache 不足，需调大wiredTigerCacheSizeGB（建议设为物理内存的 60%） - 禁用低效索引：删除
keysExamined≈docsExamined但nReturned极小的索引（如慢日志里反复出现的IXSCAN{status: 1}），这类索引每次写都触发多处更新，放大 IO - 写密集字段（如计数器、时间戳）不要建单字段索引；改用复合索引覆盖查询，减少索引维护开销
config server 成为元数据瓶颈时，整个集群写操作会挂起
每次 chunk 拆分、自动迁移或写触发均衡，都要更新 config server 上的路由表。一旦它的磁盘 IO 饱和，所有写请求会在 waiting for config server update 状态卡住，表现为大批量 WriteConflict 或超时。
- Config Server 必须用 SSD，且
dbpath单独挂载，禁止与 shard 共享磁盘设备 - 启动时显式设置
--wiredTigerCacheSizeGB 4（默认仅 1GB），避免元数据操作频繁换页 - 禁用高频手动干预：
sh.splitAt()和sh.moveChunk()只用于紧急修复；让 balancer 按默认策略（每 2 小时检查一次）工作，减少元数据写压力
临时扩容 mongos 仅在特定条件下有效，且必须配套客户端改造
mongos 是无状态进程，加节点本身不耗时，但若客户端没适配，新加的节点等于闲置，甚至因元数据不同步引发跨分片重试，延迟翻倍。
- 确认真实瓶颈：先跑
mongostat --host <mongos-host>:27017和db.currentOp({secs_running: {$gt: 5}})，只有当mongosCPU >90% 或连接数 >6000（netstat -an | grep :27017 | wc -l）时，加节点才有意义 - 配置必须严格对齐：
--configdb参数一个 host 或端口都不能错，否则新 mongos 加载不到路由表，所有请求直接失败 - 客户端必须启用
loadBalanced=true（Driver 4.0+）或显式配置多个地址 +maxPoolSize，否则旧版驱动（如 Java Driver 3.x）不会自动发现新节点，仍只打到原有 mongos
真正决定能否扛住写洪峰的，从来不是“加了多少节点”，而是分片键是否从第一天就拒绝热点、WiredTiger cache 是否留够余量应对突发、config server 是否被当成普通副本集部署——这些细节在流量还没来时就已定局。
