MongoDB分片集群部署与Chunk迁移均衡策略实战

MongoDB分片集群架构核心组件

MongoDB分片集群是处理TB级数据写入和查询水平扩展的标准架构。单实例MongoDB的写入能力和存储容量受限于单机硬件，当数据量超过单机存储阈值或写入QPS超过单机承受范围时，必须通过分片将数据分布到多个shard上并行处理。分片集群的三个核心组件：shard（数据分片，每个shard是一个replica set）、config server（存储集群元数据和chunk分布映射）、mongos（路由进程，将客户端请求路由到正确的shard）。

分片策略的选择决定了数据分布的均匀程度和查询效率。MongoDB支持两种分片策略：范围分片（Range-based）和哈希分片（Hash-based）。范围分片适合范围查询场景但容易产生热点，哈希分片写入分布均匀但不支持范围查询。

分片集群搭建与分片键选择

生产环境分片集群的最小部署：3个config server（replica set）、2个shard（各为3节点replica set）、1个mongos路由。

# 1. 启动config server副本集
mongod --configsvr --replSet cfgRS --port 27019 \
  --dbpath /data/config --bind_ip 0.0.0.0

# 初始化config server副本集
mongosh --port 27019
rs.initiate({
  _id: "cfgRS",
  configsvr: true,
  members: [
    { _id: 0, host: "cfg1:27019" },
    { _id: 1, host: "cfg2:27019" },
    { _id: 2, host: "cfg3:27019" }
  ]
})

# 2. 启动shard副本集
mongod --shardsvr --replSet shardRS1 --port 27018 \
  --dbpath /data/shard1 --bind_ip 0.0.0.0

# 3. 启动mongos路由
mongos --configdb cfgRS/cfg1:27019,cfg2:27019,cfg3:27019 \
  --port 27017 --bind_ip 0.0.0.0

# 4. 在mongos中添加shard
sh.addShard("shardRS1/shard1a:27018,shard1b:27018,shard1c:27018")
sh.addShard("shardRS2/shard2a:27018,shard2b:27018,shard2c:27018")

# 5. 启用数据库分片并选择分片键
sh.enableSharding("myapp")

# 哈希分片
sh.shardCollection("myapp.orders", { order_id: "hashed" })

# 范围分片
sh.shardCollection("myapp.logs", { created_at: 1 })

# 复合分片键
sh.shardCollection("myapp.events", { region: 1, timestamp: 1 })

分片键选择的三条硬规则：分片键一旦设定不可修改（MongoDB 4.4前），4.4后可修改但成本极高；分片键必须有唯一索引或与唯一索引的前缀匹配；分片键的基数（cardinality）必须足够大，低基数字段（如性别、状态枚举）会导致所有数据集中在少数chunk上，失去分片意义。

Chunk分裂与迁移机制

MongoDB将分片键值域划分为连续的范围区间，每个区间称为一个Chunk。默认Chunk大小64MB，当Chunk超过此阈值时自动分裂为两个子Chunk。随着数据写入不均匀，某些shard上的Chunk数量可能远多于其他shard，balancer进程负责在shard间迁移Chunk实现负载均衡。

// 查看集群Chunk分布
mongosh --port 27017

db.adminCommand({ balancerStatus: 1 })

db.config.chunks.aggregate([
  { $group: { _id: "$shard", chunkCount: { $sum: 1 } } },
  { $sort: { chunkCount: -1 } }
])
// 输出示例：
// { _id: "shardRS1", chunkCount: 45 }
// { _id: "shardRS2", chunkCount: 38 }

// 查看正在进行的迁移
db.config.migrations.find({ state: "in_progress" })

// 手动触发Chunk迁移
sh.moveChunk("myapp.orders",
  { order_id: ObjectId("650000000000000000000000") },
  "shardRS2"
)

// 调整Chunk大小
db.adminCommand({ setParameter: 1, chunkSizeMB: 32 })

Chunk迁移的过程：balancer选择源shard上最大的Chunk，在目标shard上创建空Collection，源shard将Chunk数据通过内部命令复制到目标shard，追加迁移期间的新写入，更新config server的元数据映射，源shard删除已迁移的Chunk数据。整个迁移过程中，mongos路由会自动处理新旧shard的读写重定向，对客户端透明。

Balancer调优与迁移窗口控制

Balancer默认持续运行，在Chunk数量差异超过阈值时自动迁移。大规模集群中，迁移操作占用大量网络带宽和磁盘I/O，可能影响业务性能。需要精确控制迁移窗口和速度。

// 设置Balancer运行窗口
db.config.settings.update(
  { _id: "balancer" },
  { $set: { activeWindow: { start: "02:00", stop: "06:00" } } },
  { upsert: true }
)

// 针对特定Collection禁用Balancer
sh.disableBalancing("myapp.orders")
sh.enableBalancing("myapp.orders")

// 完全停止Balancer
sh.stopBalancer()
sh.startBalancer()

// 监控迁移性能影响
db.adminCommand({ serverStatus: 1 }).metrics.migration
// 关注指标：docsCopied、docsDeleted、receiveWaitTimeMillis

迁移性能优化实践：在Chunk大小设置上，写入密集型场景建议32MB（更频繁分裂、更小粒度迁移），查询密集型场景建议128MB（减少跨shard查询次数）。迁移并发度在集群负载低于50%时可以设为2-3加速迁移，高峰期降回1避免影响业务。

分片集群监控与热点排查

分片集群最常见的性能问题是数据热点——某个shard承担了过多的读写请求。热点通常由分片键选择不当引起。

// 排查热点：查看各shard的请求分布
db.adminCommand({ connPoolStats: 1 })

// 监控各shard的ops计数
db.config.shards.find().forEach(shard => {
  const conn = new Mongo(shard.host);
  const status = conn.getDB("admin").serverStatus();
  print(`${shard._id}: ops=${status.opcounters.query}, ` +
    `inserts=${status.opcounters.insert}`);
});

// 识别大Chunk
db.config.chunks.find({
  "max._id": { $exists: true }
}).sort({ size: -1 }).limit(10)

// Jumbo Chunk处理
sh.splitAt("myapp.logs", { created_at: ISODate("2026-08-01") })

// 告警规则：shard间Chunk数量差异过大
/groups:
- name: mongodb-shard
  rules:
  - alert: ShardChunkImbalance
    expr: |
      max(mongodb_shard_chunks_total) - min(mongodb_shard_chunks_total) > 20
    for: 30m
    labels:
      severity: warning
    annotations:
      summary: "分片Chunk分布不均衡超过20个"

热点排查的工程经验：如果发现某个shard的QPS远超其他shard，检查分片键的基数和写入模式。单调递增的分片键（如ObjectId、时间戳）配合范围分片，所有新写入都会路由到最后一个shard，形成写热点。解决方案是将范围分片改为哈希分片，或在业务层加入随机前缀打散写入。