分片架构
Sharding 把一个 Collection 的文档按 Shard Key 分布到多个 Shard，用于突破单个 Replica Set 的存储容量、写入吞吐或工作集边界。每个 Shard 通常本身是 Replica Set。
集群组件
| 组件 | 作用 |
|---|---|
| mongos | 根据集群元数据路由查询与写入，不持久化业务数据 |
| Config Server | 保存分片元数据和配置状态，必须以专用复制集运行 |
| Shard | 保存业务数据的分片，通常是 Replica Set |
| Chunk / Range | Shard Key 空间中的数据范围 |
| Balancer | 在 Shard 之间迁移 Range，改善数据分布 |
Shard Key
Shard Key 一旦进入生产数据分布，就会深刻影响路由、热点、事务和扩容成本。评估维度包括：
| 维度 | 目标 |
|---|---|
| Cardinality | 有足够多的不同键值，能够细分数据 |
| Frequency | 避免少数键值承载大部分数据或请求 |
| Monotonicity | 避免递增键把新写入长期集中到单个 Chunk |
| Query Isolation | 高频查询尽量携带 Shard Key，形成 Targeted Query |
| Growth | 单个键值对应的数据量不会无限增长 |
Hashed Sharding 能打散单调键写入，但失去自然范围局部性；Ranged Sharding 支持相邻键范围查询，但更容易形成递增热点。复合 Shard Key 可以平衡租户隔离、时间范围和写入分布。
Targeted 与 Scatter-Gather
查询包含足够的 Shard Key 条件时，mongos 可以只访问目标 Shard；缺少路由条件时，可能向多个 Shard 广播，再合并结果。
Scatter-Gather 不是一定错误，但在高频请求、排序、分页或聚合中会放大网络、CPU 和尾延迟。设计 Shard Key 时必须从核心查询反推，而不是只追求数据均匀。
Balancer 与数据迁移
Balancer 负责迁移数据范围，但迁移会消耗来源和目标 Shard 的网络、磁盘和复制资源。数据均匀不代表负载均匀：某个范围即使文档数量不大，也可能因热点查询成为瓶颈。
扩容前应确认：
- Chunk 或 Range 是否仍能有效拆分。
- 是否存在 Jumbo、单键超大数据或 Zone 约束。
- Oplog、磁盘和网络是否能承受迁移。
- 应用查询是否会因增加 Shard 数量扩大广播成本。