MongoDB 分片集群中的 Balancer 和 Chunk Migration 是什么？
简化版
Balancer 负责在分片集群中均衡 chunk 分布，Chunk Migration 是把数据块从一个 shard 迁移到另一个 shard 的过程。它能缓解数据倾斜，但迁移会消耗网络、磁盘和复制资源，不能忽略业务高峰影响。
详细版
MongoDB 分片后，数据按 shard key 切成多个 chunk 分布在不同 shard 上。随着写入增长，某些 shard 可能 chunk 过多，Balancer 会触发迁移。
- Chunk 是分片数据分布和迁移的基本单位。
- Balancer 监控 chunk 分布并决定是否迁移。
- 迁移过程涉及拷贝数据、同步增量、切换元数据、清理旧数据。
- Shard key 选得差会导致热点，Balancer 只能缓解分布不均，不能根治写热点。
- 大量迁移会影响线上性能，生产中要关注窗口期和监控。
完整版教学
一、为什么分片后还需要均衡
分片的目标是把数据和负载分散到多个 shard 上，但数据不会天然均匀增长。如果 shard key 选择不合理，或者某些范围的数据增长特别快，就会出现一个 shard 存了更多 chunk、承受更多写入和查询。Balancer 的职责就是发现 chunk 分布不均，并把部分 chunk 迁到其他 shard。它像仓库调度员，看到某个仓库太满，就安排搬货到空仓库。
Shard A: 120 chunks
Shard B: 80 chunks
Shard C: 78 chunks
Balancer 可能从 A 迁移部分 chunk 到 B/C记忆钩子：Balancer 解决“块分布不均”，不一定解决“请求热点集中”。
二、Chunk 是什么
在分片集合中，MongoDB 按 shard key 的范围把数据划分成 chunk。每个 chunk 表示某个 shard key 范围内的一段数据，属于某一个 shard。随着数据增长，chunk 可能分裂；当分布不均时，chunk 可能迁移。理解 chunk 很关键，因为分片不是逐条文档随意漂移，而是以 chunk 为单位组织和移动数据。
shard key: userId
Chunk1: [0, 10000) -> Shard A
Chunk2: [10000, 20000) -> Shard B
Chunk3: [20000, 30000) -> Shard C三、Chunk Migration 大致怎么走
迁移不是简单复制一个文件。目标 shard 先拉取 chunk 范围内的数据，迁移期间源 shard 上可能仍有写入，所以还要同步增量变更。等目标 shard 追上后，集群元数据会切换 chunk 所属关系，后续请求路由到新 shard。最后源 shard 清理已经迁走的数据。这个过程涉及网络传输、磁盘读写、复制日志和元数据更新，因此在大数据量场景下会对集群有实际影响。
选择 chunk
-> 目标 shard 拷贝数据
-> 同步迁移期间的增量
-> 更新元数据归属
-> 源 shard 清理旧数据四、为什么 Balancer 不能根治热点
如果 shard key 是递增时间戳或自增 ID，新写入总是落在最新范围，那么所有新增流量可能集中到某一个 chunk 或 shard。Balancer 可以事后把 chunk 迁走，但写入热点在迁移完成前仍然集中，而且新数据还会继续打到热点范围。这就像高速收费站只有一个入口，后面再怎么搬库存，也解决不了入口拥堵。根治热点要回到 shard key 设计，例如提高基数、打散写入、避免单调递增热点。
| 问题 | Balancer 是否能解决 | 根因 |
|---|---|---|
| chunk 数量不均 | 能缓解 | 数据分布偏斜 |
| 历史数据堆在某 shard | 能迁移 | 范围分布不均 |
| 新写入都打一个范围 | 难根治 | shard key 热点 |
| 查询不带 shard key | 不能根治 | 路由无法定向 |
五、带数字看迁移成本
假设一个 chunk 有 128MB，迁移 100 个 chunk 就是约 12.8GB 数据拷贝，还不算迁移期间的增量同步和复制开销。如果网络带宽、磁盘 I/O 或复制延迟本来就紧张，迁移可能让业务延迟抖动。很多生产环境会限制 balancer 运行窗口，避开流量高峰。面试回答里能说出迁移成本，比只说“自动均衡”更像真实做过集群。
128MB/chunk × 100 chunks = 12.8GB
如果每晚迁移 500 chunks，迁移流量约 64GB 起步六、生产中应该关注哪些指标
需要关注各 shard 的 chunk 数量、数据量、磁盘使用率、迁移队列、复制延迟、慢查询和网络吞吐。如果 balancer 频繁运行，可能说明 shard key 设计或数据增长模式有问题。还要关注应用查询是否带 shard key，否则即使数据分布均衡，查询也可能广播到多个 shard。均衡只是分片集群健康的一部分，路由效率和热点写入同样重要。
// 常见排查方向：查看分片集合分布和迁移情况
sh.status()七、常见误区与追问
- 误区：开启分片后数据会永远自动均匀。 数据增长和 shard key 分布会变化，仍然可能倾斜。
- 误区：Balancer 能解决所有热点。 它主要均衡 chunk 分布，不能根治单调 shard key 带来的写热点。
- 误区：迁移没有成本。 Chunk Migration 会消耗网络、磁盘、复制和元数据更新资源。
- 追问：为什么查询不带 shard key 会慢？ 路由无法定位目标 shard，可能广播查询多个 shard。
- 追问：生产要不要限制 balancer 时间？ 高流量集群常会规划窗口，避免迁移和业务高峰叠加。
八、加强记忆
Balancer 和 Chunk Migration 可以用“搬仓库”记：chunk 是一箱箱货，shard 是仓库，balancer 是调度员。它能把货从满仓搬到空仓，但如果入口一直只往一个仓库倒货，热点仍然存在。面试时先讲 chunk、再讲迁移流程、最后强调成本和 shard key 根因，就不会停留在“自动均衡”这种表面答案。