4. 分片集群部署规划

分片集群的部署规划决定了系统未来三到五年的扩展上限与运维成本。很多团队在初期只关注“能不能跑起来”，等到数据量增长到数 TB、写入量翻倍时，才发现配置服务器成为瓶颈、分片键分布不均、机架断电导致整个副本集不可用。本节从硬件、网络、节点数量、容量和故障域五个维度，给出一套可落地的规划方法。

一、硬件选型：按角色差异化配置

分片集群中有三类角色，它们的资源画像完全不同，不应使用同一套硬件规格。

mongos 路由节点是 CPU 密集型组件。它负责解析查询、路由到目标分片、合并结果，几乎不存储数据。选型时应优先高主频 CPU（如 8～16 核、3.0GHz 以上），内存 16～32GB 即可，磁盘只需容纳日志和少量元数据缓存，普通 SSD 足够。mongos 是无状态的，可以水平扩展，通常每个应用服务器就近部署一个，或独立部署 2～4 个并配合负载均衡。

配置服务器（config server）存储集群的元数据：分片键范围、块分布、分片位置等。它必须是 3 节点副本集（CSRS），数据量小但读写频繁，且一旦不可用，整个集群的元数据操作会阻塞。选型上要求低延迟 SSD、内存 16GB 以上、CPU 中等即可。配置服务器的磁盘不需要很大（通常几十 GB），但 IOPS 要稳定。

分片节点（shard）是真正存储业务数据的地方，也是资源消耗最大的角色。每个分片本身是一个副本集，通常 3 节点。分片节点需要大容量、高吞吐的存储。以 MongoDB 6.0 为例，WiredTiger 引擎建议内存至少能容纳热数据加索引，经验值是“热数据集大小 × 1.2”。若单分片热数据 200GB，则内存建议 256GB。磁盘优先 NVMe SSD，容量按压缩后数据量的 2～3 倍预留，为索引、oplog 和 compaction 留出空间。

二、网络拓扑：低延迟与冗余并重

分片集群内部通信频繁：mongos 到分片、分片副本集内部心跳与复制、配置服务器与 mongos 的元数据同步。网络规划的核心是降低跨节点延迟和避免单点链路。

推荐拓扑：同一分片副本集的三个节点部署在同一区域（Region）的不同可用区（AZ），保证复制延迟在 1～2ms 内；不同分片之间可以跨区域分布，但 mongos 应尽量靠近其服务的主要分片。所有节点之间使用万兆（10GbE）以上内网互联，副本集内部复制流量和客户端读写流量应通过不同网卡或 VLAN 隔离，避免大流量复制挤占业务请求。

此外，必须为每个节点配置带外管理网络（如 IPMI），并确保时间同步（NTP）正常。MongoDB 的 oplog 和选举机制对时间偏差敏感，节点间时间差超过 30 秒可能引发异常。

三、配置服务器与分片节点数量估算

配置服务器数量是固定的：必须为 3 节点副本集。MongoDB 3.4 之后不再支持 SCCC（三配置服务器镜像）模式，CSRS 是唯一选择。3 节点可容忍 1 个节点故障，若需要更高可用性可扩展到 5 节点，但多数场景 3 节点足够。

分片节点数量没有固定公式，需要根据数据量、写入吞吐和单分片承载能力综合估算。一个实用的估算流程如下：

1. 估算总数据量：当前数据量 × 年增长率 × 保留年限。例如当前 2TB，年增 60%，保留 3 年，则 3 年后约 2 × 1.6³ ≈ 8.2TB。
2. 确定单分片容量上限：建议单分片压缩后数据不超过 2TB，热数据不超过内存的 80%。若单节点 256GB 内存，热数据约 200GB，按热数据占比 20% 估算，单分片总数据约 1TB 较安全。
3. 计算分片数：8.2TB ÷ 1TB ≈ 9 个分片。但分片数应为质数或便于均衡的数量，实际可取 9 或 10 个分片。
4. 考虑写入吞吐：若单分片可承载 5000 写/秒，目标 30000 写/秒，则至少 6 个分片。取数据量和吞吐量估算的较大值。

注意：分片数不是越多越好。每个分片都是一个 3 节点副本集，9 个分片意味着 27 个数据节点，加上 3 个配置服务器和若干 mongos，运维复杂度显著上升。建议初期按估算值的 70% 部署，预留扩展空间，后续通过 sh.addShard() 在线增加分片。

四、容量规划：磁盘、内存与 oplog

容量规划要同时考虑三类存储：

因此单分片磁盘建议 2TB 以上，且使用 RAID 10 或直接多块 NVMe 做条带化。内存方面，WiredTiger 默认使用 50% 物理内存作为缓存，剩余留给文件系统缓存和连接。若单节点 256GB 内存，WiredTiger 缓存约 128GB，可较好支撑 200GB 热数据。

oplog 大小容易被低估。oplog 是固定大小的 capped collection，写入速率高时若 oplog 太小，会导致从节点无法追上主节点而触发全量同步。建议按“峰值写入速率 × 72 小时”估算，并在 mongod.conf 中通过 replication.oplogSizeMB 显式设置。

五、故障域隔离：从机架到可用区

故障域隔离的目标是：任意单一故障域失效时，每个副本集仍能保持多数派存活。具体做法：

• 同一副本集的 3 个节点分布在 3 个不同可用区（AZ）或 3 个不同机架，避免同一机架断电导致副本集失去多数派。
• 配置服务器副本集同样跨 3 个 AZ 部署，且与分片节点物理隔离，避免分片故障波及元数据。
• mongos 无状态，可部署在应用侧或独立区域，至少 2 个实例避免单点。
• 使用 MongoDB 的 readPreference 和 writeConcern 配合故障域策略：例如 writeConcern: { w: "majority", wtimeout: 5000 } 确保写入被多数派确认，readPreference: "nearest" 降低跨 AZ 读延迟。

最后强调一个常见误区：不要为了“省机器”把配置服务器和分片节点混部在同一台物理机上。配置服务器虽然数据量小，但元数据读写延迟直接影响整个集群的路由效率；一旦与高负载分片争抢 IO，会引发连锁反应。规划阶段多花一天做容量与故障域推演，胜过上线后数周的紧急扩容与故障排查。