Config Server 必须独立部署为专用副本集，禁止与Shard或mongos混用资源；混用会导致启动失败、响应延迟、心跳超时及静默只读降级，其writeConcern majority同步机制对延迟极度敏感。
Config Server 必须独立部署，不能混用应用节点资源
Config Server 在 MongoDB 分片集群中承担元数据管理职责，所有 mongos 路由节点都依赖它读取分片拓扑、chunk 分布、集合分片策略等关键信息。一旦它不可用或响应延迟高，整个集群的写入、均衡、甚至部分读操作都会卡住 —— 这不是性能问题，而是可用性单点故障。所以官方明确要求：Config Server 必须使用专用的 mongod 实例，且必须部署为副本集（3 节点最小），禁止与 shard 或 mongos 共享同一进程、同一主机或同一资源池（如共用 CPU/内存/磁盘）。
混用 Config Server 和 Shard 节点会触发启动拒绝
从 MongoDB 3.6 开始，如果尝试在同一个 mongod 进程中同时启用 sharding: { clusterRole: "shardsvr" } 和 sharding: { clusterRole: "configsvr" }，服务根本无法启动，直接报错：
ERROR: Cannot start node with both shardsvr and configsvr roles enabled
即使绕过配置检查（比如手动修改启动参数），运行时也会因内部锁机制和元数据隔离逻辑冲突而崩溃。更隐蔽的问题是：某些旧版驱动或 mongos 在发现 config server 返回非预期的 shard 角色响应后，会静默降级为只读模式，导致业务写入失败但无明显错误日志。
Config Server 共用物理机或云实例的后果
- 磁盘 I/O 竞争：Config Server 的
config.system.sessions和config.chunks集合虽小，但更新频繁且要求强一致性；Shard 节点的 WAL 日志刷盘、压缩、归档会抢占同一块 SSD 的队列深度，造成 config server 响应毛刺（P99 > 500ms），触发mongos的重试风暴 - CPU 抢占：Config Server 的多数操作是轻量级文档查询，但 chunk 拆分、迁移 commit 阶段需要短时高 CPU；若与 Shard 的
WiredTigercache 压缩线程同核运行，会导致 config server 的心跳超时被误判为宕机 - 内存压力：Config Server 默认不启用
WiredTigercache（它用的是内存映射文件 + journal），但若宿主机内存不足，Linux OOM killer 可能优先干掉它的进程 —— 它没有cacheSizeGB这类显式内存限制参数，反而更难保活
真正可行的“轻量级”部署方案
Config Server 不需要大规格机器，但必须隔离。生产环境推荐：
- 3 台最低配云主机（如 AWS t3.small / 阿里云 ecs.s6e.large），仅跑
mongod --configsvr --replSet configReplSet，禁用 swap，绑定独立云盘（gp3 / ESSD PL0 即可） - 绝对不要复用现有 Shard 主机的空闲 CPU 核心或 Docker 容器 —— 容器网络延迟和 cgroup 内存限制会放大上述毛刺问题
- 如果预算极紧，可将 3 个 Config Server 实例部署在同一物理机的 3 个独立 VM 中（KVM/QEMU），但需确保 vCPU 绑定物理核、磁盘直通、禁用 ballooning
混用从来不是资源优化，是把元数据层拖进数据层的风险泥潭。最常被忽略的一点：Config Server 副本集的 writeConcern: { w: "majority" } 是强制的，任何写入都必须等至少 2 个节点落盘，这个同步开销对延迟极其敏感 —— 它不接受妥协。
