MongoDB（四）：分片集群与生产实践

星辰逐梦2026/6/18大约 19 分钟

MongoDB（四）：分片集群与生产实践

导语：分片（Sharding）是 MongoDB 面试最能拉开差距的部分——「分片键怎么选」几乎是必问题。本篇覆盖分片集群架构（mongos / config server / shard）、chunk 与均衡器、分片键的三维评估与四种策略、定向查询与广播查询、跨分片事务，以及容量规划、监控与场景设计题，共 20 题。

一、为什么分片与集群架构

1. 为什么需要分片？和副本集有什么区别？（必问）

答：副本集解决高可用与读扩展，但所有节点存的是同一份全量数据，因此有三条硬上限：

单机存储上限：数据量超过单机磁盘；
单机读写上限：写入压力超过单机 IO/CPU（副本集对写没有扩展能力，所有写入都走 Primary）；
内存上限：工作集放不进内存，性能断崖。

分片把数据水平拆分到多个分片（每个分片本身又是一个副本集），从而同时扩展存储、写入吞吐与内存容量：

维度	副本集	分片集群
数据分布	每个节点都有全量数据	每个分片只有一部分数据
扩展方向	读扩展 + 高可用	读、写、存储全面水平扩展
复杂度	低	高（分片键、均衡、路由）
适用	大多数场景的首选	数据量极大或写入极高时

面试要点：分片不是银弹。官方建议顺序是「先单机 → 再副本集 → 最后分片」。过早分片会带来无法回退的复杂度（分片键选错、跨分片查询、运维成本）。

2. 分片集群由哪些组件构成？（必问）

答：三类角色：

组件	职责	关键点
mongos（路由）	接收客户端请求，查询 config server 的元数据，把请求路由到目标分片，合并结果返回	无状态，可部署多个并放在负载均衡后面；不存数据
config server	存储集群元数据：分片列表、chunk 分布、集合的分片配置、均衡器状态等	3.4 起必须是副本集（CSRS）；7.0 起元数据下放到每个分片，减轻 config server 压力
shard（分片）	实际存储数据的节点，每个 shard 都是一个副本集	3.6 起强制要求副本集，保证每个分片都有高可用

                    ┌──────────────┐
   应用 ──►  mongos1│  (无状态路由) │
      └──►  mongos2│              │
                    └──────┬───────┘
                           │  读取元数据
                    ┌──────▼────────┐
                    │ config server │  3 节点副本集，存元数据
                    └───────────────┘
           ┌───────────────┼───────────────┐
     ┌─────▼─────┐   ┌─────▼─────┐   ┌─────▼─────┐
     │ shard1    │   │ shard2    │   │ shard3    │
     │ (副本集)  │   │ (副本集)  │   │ (副本集)  │
     └───────────┘   └───────────┘   └───────────┘

常见追问：

应用连谁？ 必须连 mongos（连接串写多个 mongos 地址），绝不能直连 shard（会绕过路由，写错数据）；
mongos 挂了怎么办？ 多部署几个，客户端驱动会自动重连其它 mongos；
config server 挂了会怎样？ 副本集保证多数派可用时集群正常；全部不可用时集群变为只读（无法做 chunk 分裂、迁移与路由元数据更新）；
8.0 的「配置分片（Config Shard）」：允许 config server 同时承载应用数据，从而用更少的机器起步（对小规模集群降低门槛），可在专用/内嵌 config server 之间切换。

二、数据分布机制

3. 什么是 chunk？它是怎么分裂和迁移的？

答： chunk 是数据在分片间迁移的最小单位，由一段连续的分片键区间内的文档组成。

默认大小 128MB（早期版本为 64MB），可配置区间约 1MB ~ 1024MB；
当 chunk 超过阈值，mongos 会触发分裂（split）成两个更小的 chunk；
均衡器（balancer）发现各分片 chunk 数量差异超过阈值（默认迁移阈值随 chunk 数变化）时，把 chunk 从「多的分片」迁到「少的分片」（moveChunk）。

// 查看 chunk 分布与大小
sh.status()                                   // 集群总览（含 chunk 分布）
db.adminCommand({ "listChunks": "order.orders" })  // 某集合的 chunk 列表

// 修改 chunk 大小（需在 mongos 执行）
use config
db.settings.updateOne({ _id: "chunksize" }, { $set: { value: 256 } }, { upsert: true })

// 手动分裂与迁移（一般不需要手动干预）
sh.splitAt("order.orders", { userId: "U-5000" })
sh.moveChunk("order.orders", { userId: "U-5000" }, "shard2")

chunk 分裂与迁移的影响（面试常问「迁移会不会影响性能」）：

迁移会复制数据 + 短暂阻塞该 chunk 的写入，产生额外 IO 与网络开销；
因此生产上会设置均衡窗口（balancerWindow）把迁移限制在业务低峰，或对迁移限速；
不要频繁手动 moveChunk，让 balancer 自己工作即可。

4. 什么是 jumbo chunk？如何处理？

答：当某个 chunk 的数据量超过 chunk size 且无法再分裂时，被标记为 jumbo：

典型原因：分片键值过于集中（比如所有文档的 tenantId 都是同一个值）；
后果：该 chunk 无法迁移（迁移后不会变小，split 也拆不开），导致分片间数据严重不均、单分片压力过大；
处理方式：
1. 治本：重新设计分片键（提高基数，或改用复合/哈希分片键），配合 reshardCollection 在线重分片（5.0+）；
2. 治标：手动 sh.splitAt() 在热点区间内插入分裂点，或临时把大数据文档拆分；
3. 排查：sh.status() 中看到 jumbo 标记。

// 定位 jumbo chunk
sh.status()      // 输出中出现 jumbo 标记的 chunk
// 或
db.getSiblingDB("config").chunks.find({ jumbo: true })

5. 均衡器（balancer）是怎么工作的？什么时候不该开？

答：

作用：让各分片的 chunk 数量（以及数据量）大致均衡，默认后台运行；
触发条件：某分片 chunk 数比最少的分片多出阈值（阈值随 chunk 总数动态变化，chunk 少时允许差异大，chunk 多时更严格）；
迁移过程：moveChunk 从 donor 复制到 recipient，切换元数据，删除源数据（会短暂影响写入）；
控制手段：设置均衡窗口、暂停/恢复均衡、限制迁移并发。

// 暂停/恢复均衡（升级或大批量导入前常用）
sh.stopBalancer()
sh.getBalancerState()
sh.startBalancer()

// 指定均衡窗口（写在 config.settings 中）
use config
db.settings.updateOne(
  { _id: "balancer" },
  { $set: { activeWindow: { start: "02:00", stop: "06:00" } } },
  { upsert: true }
)

什么时候暂停均衡：大批量数据导入/迁移（避免「导入 + 迁移」双重 IO）、集群维护/升级、分片间网络抖动时。

三、分片键的选择（本章最重要）

6. 分片键怎么选？三个评估维度是什么？（必问）

答：分片键决定了数据如何分布与查询如何路由，是分片集群唯一无法轻易更改的核心决策。评估三个维度：

维度	含义	不合格的表现
基数（Cardinality）	分片键的不同取值数量	取值太少（如 `status` 只有 3 个值）→ chunk 无法继续分裂，jumbo chunk
频率（Frequency）	单个取值的文档占比	某个值占了 90% 数据（如大客户的 `tenantId`）→ 数据倾斜
单调性（Monotonicity）	取值是否随时间单调递增	用自增 ID、时间戳、ObjectId 做键 → 写入永远打到最后一个 chunk → 写热点

理想分片键：

取值多、分布均匀（每次写入能落到不同分片）；
查询常用：让高频查询能带上分片键，成为定向查询；
写入能打散（非单调递增）。

// 反面示例：用自增数字做分片键（单调递增 → 永远写最后一个 chunk）
sh.shardCollection("order.orders", { orderId: 1 })        // ❌ 写热点

// 反面示例：用状态字段分片（基数太低 → 只有 4~5 个 chunk）
sh.shardCollection("order.orders", { status: 1 })          // ❌ 无法均衡

// 正面示例：哈希分片键（打散写入）
sh.shardCollection("order.orders", { userId: "hashed" })   // ✅ 写入均匀

// 正面示例：复合分片键（既打散写入，又支持定向查询）
sh.shardCollection("log.events", { tenantId: 1, deviceId: 1 })   // ✅

7. 范围分片、哈希分片、复合分片、Zone 分片各有什么特点？

答：

策略	写法	优点	缺点	适用
范围分片（Range）	`{ userId: 1 }`	支持范围查询（区间扫描命中少量分片）；有序	单调键会产生热点；分布可能不均	查询以范围为主（时间区间、ID 区间）
哈希分片（Hashed）	`{ userId: "hashed" }`	写入分布均匀，几乎无热点	范围查询要广播所有分片（等值查询才能定向）；不支持范围分片语义	写多、以等值查询为主
复合分片（Compound）	`{ tenantId: 1, userId: "hashed" }`	兼顾：前缀做定向，后缀打散写入	设计需要贴合查询	多租户 SaaS 常用
Zone 分片	按分片键区间划分 zone	让数据就近存放（多机房）或冷热分层（热数据放 SSD 分片）	配置复杂，需维护区间	多地域部署、数据分级

// 范围分片：适合「按时间区间查日志」
sh.shardCollection("log.events", { createdAt: 1 })

// 哈希分片：适合「用户中心」这种等值查询为主的场景
sh.shardCollection("user.profile", { userId: "hashed" })

// 复合分片：多租户 + 打散写入（前缀等值，后缀哈希）
sh.shardCollection("saas.docs", { tenantId: 1, docId: "hashed" })

// Zone：把「北京」的租户数据固定放在 bj 机房的分片上
sh.addShardToZone("shard-bj", "BJ")
sh.updateZoneKeyRange("saas.docs", { tenantId: "BJ-0000" }, { tenantId: "BJ-9999" }, "BJ")

哈希分片为什么写入均匀？ 它对分片键值做 MD5 之类的哈希，把原本单调递增的值打散成随机分布；代价是哈希后丢失了顺序性，所以范围查询（$gt/$lt）必须广播到所有分片。

8. 分片键有哪些限制？选错了能改吗？（高频）

答：

限制

分片键必须是已建索引的字段（或索引的前缀），不存在时 MongoDB 会自动建索引（哈希分片键会建哈希索引）；
分片键值最大 512 字节；
不能是数组字段（不允许多键索引作为分片键）；
分片键字段的值一旦插入，早期版本不可修改。

「改分片键」的演进（重要考点）：

版本	能力
4.2 之前	分片键完全不可变，选错只能导数据重建
4.2	允许 `update` 修改分片键的值（filter 必须带完整分片键；且不能改到不同分片？可以，会触发迁移）
4.4	`refineCollectionShardKey`：追加后缀字段扩展分片键（如 `{a:1}` → `{a:1, b:1}`），只能加不能减
5.0	`reshardCollection`：在线重分片，可换一个全新的分片键，数据在后台迁移，业务基本无感
8.0	重分片显著提速，新增 `forceRedistribution`（同分片键也能重分片，用于重新打散数据）

// 4.2：修改分片键的值（必须在 filter 里带上完整分片键）
db.orders.updateOne({ tenantId: "T-1", orderId: 100 }, { $set: { tenantId: "T-2" } })

// 4.4：给分片键追加后缀字段
db.adminCommand({ refineCollectionShardKey: "order.orders", key: { userId: 1, orderId: 1 } })

// 5.0+：在线重分片（换成分片键 { orderId: "hashed" }）
db.adminCommand({
  reshardCollection: "order.orders",
  key: { orderId: "hashed" },
  numInitialChunks: 64
})

生产提醒：虽然 5.0 起可以重分片，但它依然是重操作（后台复制大量数据、占用 IO）。设计阶段就想清楚分片键，永远优于事后重分片。

9. 定向查询和广播查询有什么区别？（影响性能的关键）

答：

查询形态	路由行为	性能
包含完整分片键（等值）	定向（targeted）：只发往 1 个分片	最好
包含分片键前缀/范围	发往部分分片	较好
不含分片键	广播（scatter-gather）：发往所有分片，再由 mongos 合并	最差：分片越多越慢

// 分片键 { userId: 1 }
db.orders.find({ userId: "U-1" })                       // ✅ 定向到 1 个分片
db.orders.find({ userId: "U-1", status: "PAID" })       // ✅ 定向
db.orders.find({ status: "PAID" })                      // ❌ 广播到所有分片
db.orders.find({ userId: { $gte: "U-1", $lte: "U-9" } }) // ⚠️ 区间 → 部分分片（范围分片时）

// 用 explain 看路由情况：SHARD_MERGE 表示走了多个分片
db.orders.find({ status: "PAID" }).explain("executionStats")
// winningPlan.stage: "SHARD_MERGE"（合并多分片结果）
// 对比：
db.orders.find({ userId: "U-1" }).explain("executionStats")
// winningPlan.stage: "SINGLE_SHARD"（只命中一个分片）

设计经验：把最常用的查询条件作为分片键前缀（让高频查询定向），同时保证写入均匀（用哈希后缀或高基数前缀）。

10. 分片键选错会出现哪些典型症状？

答：

症状	根因	对策
写热点：某分片 CPU/IO 持续 100%	单调递增分片键（自增 ID、时间戳、ObjectId）	改哈希分片键或复合键；5.0+ 在线重分片
数据倾斜：某分片数据量远超其它	分片键频率不均（大租户）	用「租户 + 高基数后缀」复合键；必要时 Zone 隔离
jumbo chunk 无法迁移	分片键基数太低	重新设计分片键 + 重分片
查询全慢：每个查询都广播	常用查询条件不在分片键里	重选分片键（贴合查询模式）
chunk 频繁迁移	分片键分布抖动 / 写入不均	检查分片键单调性，暂停/限流均衡

四、分片集群的使用要点

11. 分片集群下事务怎么用？有什么额外限制？

答：

4.2 起支持跨分片的多文档事务，API 与副本集完全一致（startTransaction / withTransaction）；
隔离级别仍是快照隔离，默认 60 秒超时，写入总量受 16MB oplog 限制；
性能代价明显更高：需要 mongos 作为协调者，跨分片写入要走两阶段提交式的协调，比单分片/单文档操作慢一个数量级；
最佳实践：让事务涉及的文档落在同一个分片——把「同一逻辑事务内要一起改的数据」用同一分片键值分布（例如订单与其明细都用 orderId 作为分片键前缀），这样事务就是单分片事务，性能接近本地事务；
8.0 起，分片集合的事务中可以使用 $lookup（此前不支持）。

// 单分片事务（推荐）：订单与其明细使用同一 orderId 前缀，天然落在同分片
sh.shardCollection("shop.orders",  { orderId: "hashed" })
sh.shardCollection("shop.details", { orderId: "hashed" })   // 同键 → 同分片

session.withTransaction(() => {
  db.orders.insertOne({ orderId: "O-1001", amount: 200 }, { session })
  db.details.insertOne({ orderId: "O-1001", sku: "A-1" }, { session })
})

12. 分片集群中的聚合、`$lookup` 与读偏好有什么注意点？

答：

聚合：管道开头若包含分片键，可把执行下推到目标分片（SINGLE_SHARD）；否则 $match/$group 要在各分片分别执行再由 mongos 合并（SHARD_MERGE），开销大；
$lookup：需要 5.1+ 才支持「分片集合之间」的关联；关联的 from 集合最好是未分片或与本地集合同分片键，否则会退化为广播；
读偏好：readPreference=secondary 时，mongos 会把读请求路由到目标分片的从节点，但同一个查询的不同分片可能来自不同一致性时刻的数据（不建议在需要全局一致的场景下用从节点读）；
readConcern: available 可能读到孤儿文档（orphaned documents）：chunk 迁移过程中，源分片上的旧数据尚未清理，此时读源分片可能看到「已经被迁走」的数据。需要一致性时用 local / majority。

13. 分片集群如何扩容与缩容？

答：

// 添加分片（新分片为空，balancer 会逐步把 chunk 迁过来）
sh.addShard("rs-shard4/m4a:27017,m4b:27017,m4c:27017")
sh.status()                       // 观察 chunk 迁移进度

// 移除分片（会先把该分片上的 chunk 全部迁走，耗时可能很长）
db.adminCommand({ removeShard: "shard4" })
db.adminCommand({ removeShard: "shard4" })   // 重复执行直到 state 为 completed

要点：

添加分片后不会立刻均衡：balancer 按阈值逐步迁移，可能持续数小时甚至数天（数据量大时），建议放在低峰期并临时调整均衡窗口；
移除分片前要确认磁盘空间足够接收剩余数据；
8.0 的 moveCollection / unshardCollection：可以把未分片集合整体搬移到指定分片，或把已分片集合取消分片（数据集中到一个分片），让「分片与否」变成可逆操作。

// 8.0：把未分片集合移到指定分片 / 取消某集合的分片
sh.moveCollection("order.archive", "shard3")
sh.unshardCollection("order.orders")

14. 什么时候该分片？什么时候不该？

答：

先做这些（成本远低于分片）

索引与查询优化（消灭 COLLSCAN、覆盖查询、减少返回字段）；
数据模型优化（避免无界数组、控制文档大小）；
冷热分离 / 归档（历史数据移到独立集合或对象存储）；
垂直扩容（加内存、换 SSD——通常是最便宜的方案）；
读写分离（报表/备份走从节点，8.0 起慢查询定位可区分 workingMillis）。

该分片的信号

单集合数据量达到 TB 级并且持续增长；
写入 QPS/IO 已经逼近单机上限（副本集对写无扩展能力）；
工作集远超单机内存，且无法通过归档解决；
有明确的高基数、贴合查询的分片键可用。

不该分片的情况

数据量只有几百 GB：优先副本集 + 索引优化；
业务查询模式尚不明确：分片键无法确定，先别分；
团队没有分片运维经验：分片集群的监控、备份、故障处理复杂度显著更高。

五、生产实践与综合场景

15. 分片集群该怎么备份？

答：

单集合粒度：mongodump 连 mongos 可以导出（会遍历所有分片），但大数据量下慢且影响生产；
一致性要求高：使用文件系统快照，需保证各分片的快照在同一逻辑时间点（配合 fsync 锁写）；
7.1 起 fsync/fsyncUnlock 支持在分片集群上运行，配合 mongodump 实现自管理分片集群的备份，这是一项实用的新能力；
云上：优先使用云厂商/Atlas 的备份与 PITR（基于 oplog 增量）。

// 7.1+：分片集群整体锁写 → 快照 → 解锁（各分片执行，由 mongos 协调）
db.adminCommand({ fsync: 1, lock: true })
// ... 对各个 shard 的数据目录做快照 ...
db.adminCommand({ fsyncUnlock: 1 })

16. 分片集群日常要监控哪些指标？

答：

类别	指标	异常信号
chunk 均衡	各分片 chunk 数、`sh.status()`	长期严重不均、出现 jumbo chunk
迁移	`serverStatus().shardingStatistics` 的迁移计数与耗时	`countDonorMoveChunkCommitted` 突增、迁移耗时变长
均衡器	`sh.getBalancerState()`、均衡窗口	长时间未均衡（可能被暂停忘了恢复）
config server	副本集健康状态、`configServerInShardCache`	config server 多数派不可用 → 集群只读
路由	mongos 的 `connections`、`opcounters`	mongos CPU 饱和、连接数打满
业务侧	`SINGLE_SHARD` vs `SHARD_MERGE` 比例	广播查询比例高 → 分片键不合理

// 8.0：查看分片统计（含 chunk 迁移与 config shard 切换计数）
db.serverStatus().shardingStatistics

17. 场景题：一个日均 5000 万条日志的 MongoDB 该如何设计？

答：这是一道综合题，回答要覆盖建模 → 索引 → 生命周期 → 扩展四层：

① 数据建模

使用时间序列集合（5.0+）或普通集合按天/按月分表（logs_20260925）；
文档字段精简，避免嵌套大对象；写入用 insertMany(ordered:false) 批量写。

② 索引设计

db.logs.createIndex({ tenantId: 1, ts: -1 })                    // 支撑「按租户 + 时间范围」查询
db.logs.createIndex({ ts: 1 }, { expireAfterSeconds: 2592000 })  // TTL：30 天自动清理

③ 生命周期管理

TTL 索引自动删除过期数据；TTL 后台任务约每 60 秒执行一次，删除不精确到秒；
冷数据归档到对象存储或 logs_archive 集合后再删除；
写入高峰期避开 compact 与索引重建。

④ 容量与扩展

单机磁盘与 IO 评估：先垂直扩容 + 副本集，报表查询走隐藏从节点；
数据量到 TB 级或写入到瓶颈后分片：分片键建议 { tenantId: 1, ts: 1 } 或 { ts: "hashed" }（视查询模式）——前者支撑「按租户 + 时间」的定向查询且写入按 tenantId 打散，后者写入绝对均匀但范围查询要广播；
分片集群的写关注：日志可容忍少量丢失，用 { w: 1 } 换取吞吐；审计日志用 { w: "majority" }。

18. 场景题：MongoDB 出现「查询突然全面变慢」，怎么排查？

答：按「先定位、再分类、后处理」的顺序：

确认范围：是所有查询还是某个集合？是读慢还是写慢？

db.currentOp({ secs_running: { $gte: 3 } })          // 正在执行的慢操作
db.adminCommand({ currentOp: 1, planSummary: "COLLSCAN" })  // 是否突然出现全表扫描

看资源与内存：

db.serverStatus().extra_info.page_faults      // 突增 → 内存不足，工作集被挤出
db.serverStatus().wiredTiger.cache            // 脏页高、eviction 频繁
db.serverStatus().connections                 // 连接打满 → 排队

看索引是否被删/失效：$indexStats 对比 accesses.ops，是否有人 drop 了索引；explain 看是否从 IXSCAN 变成 COLLSCAN；
看数据量突变：某个集合是否被批量导入导致体积暴增、索引膨胀；
看分片集群侧：是否正在做 chunk 迁移/重分片（大量 IO）、是否有分片不均衡；
看应用侧：是否新增了 $regex 非前缀匹配、$ne、无索引 $lookup、深度 skip；是否类型不统一（字符串查数字）；
处理：临时用 hint 固定索引、killOp 杀掉异常查询、暂停均衡、扩容只读副本，再按根因修复（重建索引、优化查询、加内存、归档数据）。

19. 面试高频「坑」总结

答：

不要直连 shard：必须连 mongos，否则绕过路由写入会导致数据错乱；
分片键不要用单调递增字段：写热点是分片集群第一大事故；
不要过早分片：复杂度不可逆，先索引优化 + 副本集；
readConcern: available 可能读到孤儿文档：事务与强一致场景用 local/majority；
跨分片事务性能差：让事务内数据同分片（同分片键前缀）；
sh.status() 里别忽略 jumbo：一旦出现就意味着分片键设计有问题；
迁移窗口要规划：大批量导入前暂停均衡，导入后再恢复；
w: 1 在主节点故障时可能丢数据：核心数据一律 w: "majority"；
TTL 删除不精确：它是后台任务（约 60 秒一轮），不能当「精确定时删除」用；
mongos 也要做高可用：客户端连接串写多个 mongos 地址。

20. 一页速记：MongoDB 面试主线

答：

入门：是什么 → 与 MySQL 区别 → 适用场景 → BSON/ObjectId → 内嵌 vs 引用
性能：索引类型 → 最左前缀 → ESR → 多键索引 → 覆盖查询 → explain 三定律 → 聚合管道
高可用：副本集 → PV1 选举 → oplog 幂等 → Rollback → readPreference/readConcern/writeConcern
一致性：单文档原子 → 多文档事务（4.0/4.2）→ 快照隔离 + 60s + 16MB → 因果一致会话
扩展：mongos/config/shard → chunk 与均衡器 → 分片键三维（基数/频率/单调性）
      → 范围 vs 哈希 → 定向 vs 广播 → 重分片（5.0+）
运维：内存与工作集 → 慢查询与 profiler → TTL 与归档 → 备份（快照 + oplog）→ 监控指标

回答任何 MongoDB 问题的通用框架：先说适用场景 → 再说机制原理 → 最后给出「怎么配、怎么防坑」。只背概念的答案拿不到高分，能说出「为什么这么设计、错了会怎样」才是面试官想听的。