MongoDB分片集群架构设计与性能调优实战

分片架构核心概念

MongoDB分片（Sharding）是处理大规模数据集的水平扩展方案。当单机无法承载数据量或读写吞吐时，通过分片将数据分布到多个物理节点上。核心组件包括：shard（数据分片，每个shard是一个replica set）、config server（存储集群元数据，3节点副本集）、mongos（路由进程，接收客户端请求并路由到目标shard）。

选择分片键（Shard Key）是架构设计最关键的决策。分片键决定了数据分布策略和查询路由效率。不好的分片键会导致数据倾斜（jumbo chunk）或散列查询无法利用局部性。

// 选择分片键的最佳实践
// 1. 单调递增键（如ObjectId）+ 范围分片 = 写热点
// 2. 高基数字段 + 散列分片 = 均匀分布
// 3. 复合分片键 = 兼顾分布与查询局部性

// 启用分片
sh.enableSharding("mydb")

// 对集合设置散列分片键（适合写入密集型）
sh.shardCollection("mydb.orders", { userId: "hashed" })

// 复合范围分片键（适合多维度查询）
sh.shardCollection("mydb.logs", { region: 1, timestamp: 1 })

散列分片键能保证数据均匀分布，但所有范围查询都会变成散射读（scatter-gather）。复合范围分片键则将同一region的数据聚集在同一shard，查询{region: "east"}可精确路由。实际中需要根据读写模式权衡选择。

搭建生产级分片集群

以下是用配置文件方式搭建3-shard + 3-config + 2-mongos集群的关键配置：

# config server 配置 (config-svr-1.conf)
storage:
  dbPath: /data/configsvr1
net:
  port: 27019
replication:
  replSetName: configReplSet
sharding:
  clusterRole: configsvr

# shard 配置 (shard-1.conf)
storage:
  dbPath: /data/shard1
  wiredTiger:
    engineConfig:
      cacheSizeGB: 8        # 留一半内存给OS页缓存
    collectionConfig:
      blockCompressor: snappy  # 压缩节省存储
net:
  port: 27018
replication:
  replSetName: shard1
sharding:
  clusterRole: shardsvr

# mongos 路由配置
net:
  port: 27017
sharding:
  configDB: configReplSet/cfg1:27019,cfg2:27019,cfg3:27019

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

# 初始化 shard 副本集
rs.initiate({
  _id: "shard1",
  members: [
    { _id: 0, host: "s1n1:27018", priority: 2 },
    { _id: 1, host: "s1n2:27018" },
    { _id: 2, host: "s1n3:27018", arbiterOnly: true }
  ]
})

# 添加 shard 到集群
sh.addShard("shard1/s1n1:27018,s1n2:27018,s1n3:27018")
sh.addShard("shard2/s2n1:27018,s2n2:27018,s2n3:27018")
sh.addShard("shard3/s3n1:27018,s3n2:27018,s3n3:27018")

生产环境建议：config server必须3节点副本集确保元数据安全；每个shard至少3节点（1 primary + 1 secondary + 1 arbiter）保证高可用；mongos部署2+实例实现路由层容灾。

数据均衡与Chunk管理

MongoDB将分片键值空间划分为连续的chunk（默认64MB），balancer自动在shard间迁移chunk实现均衡。理解chunk管理对排查性能问题至关重要：

// 查看chunk分布
sh.status()

// 查看特定集合的chunk详情
use config
db.chunks.find({ ns: "mydb.orders" }).sort({ min: 1 })

// 手动迁移chunk（紧急处理数据倾斜）
sh.moveChunk("mydb.orders", { userId: 50000 }, "shard2")

// 标记jumbo chunk（超大chunk无法迁移）
// 需要先细化分片键或手动split
sh.splitAt("mydb.orders", { userId: 25000 })

// 调整chunk大小（小chunk=更均衡但更多迁移开销）
db.adminCommand({ setParameter: 1, chunkSize: 32 })

chunk迁移过程：balancer选择fromShard和toShard → fromShard进入drain模式 → 复制chunk数据到toShard → 追加迁移期间的写入oplog → 更新config server元数据 → toShard成为chunk新主人。整个过程对应用透明，但迁移期间可能短暂影响源shard性能。

WiredTiger存储引擎深度调优

WiredTiger是MongoDB默认存储引擎，其性能高度依赖内存配置：

# 关键参数配置
storage:
  wiredTiger:
    engineConfig:
      cacheSizeGB: 12          # 建议物理内存50%-60%
      journalCompressor: snappy # journal压缩
      checkpointIntervalSecs: 60 # 检查点间隔
    collectionConfig:
      blockCompressor: zstd    # zstd压缩率优于snappy
    indexConfig:
      prefixCompression: true  # 索引前缀压缩

# 系统层面优化
# 1. 禁用透明大页
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

# 2. 调整vm.dirty_ratio减少突发刷盘
sysctl -w vm.dirty_ratio=10
sysctl -w vm.dirty_background_ratio=3

# 3. XFS挂载选项（推荐文件系统）
mount -o noatime,nodiratime,allocsize=64m /dev/sdb /data

cacheSizeGB是最重要的参数。设置过大导致OS页缓存不足（MongoDB依赖OS缓存读取未在WiredTiger缓存中的数据），设置过小则频繁eviction。经验值：在纯MongoDB节点上设为物理内存的50%-60%，留余量给OS页缓存和连接开销。

读写性能优化实战

分片集群的读写性能优化需要从查询路由、索引策略、连接池三个层面入手：

// 1. 确保查询包含分片键（精准路由）
// 好：直接路由到目标shard
db.orders.find({ userId: 12345, status: "active" })

// 差：散射到所有shard
db.orders.find({ status: "active" })

// 2. 查看查询执行计划
db.orders.explain("executionStats").find({
  userId: 12345,
  createdAt: { $gte: ISODate("2026-01-01") }
})

// 3. 复合索引设计（ESR规则：Equal-Sort-Range）
db.orders.createIndex({ userId: 1, status: 1, createdAt: -1 })

// 4. 批量写入优化
const bulkOps = orders.map(o => ({
  insertOne: { document: o }
}));
db.orders.bulkWrite(bulkOps, { ordered: false }); // 无序批量写

// 5. 读偏好设置（将分析查询分流到secondary）
db.orders.find({ ... }).readPref("secondary", [
  { region: "east" }  // tag感知读偏好
])

关键指标监控：mongostat观察inserts/query/update/delete速率和conn数；mongotop观察各集合读写耗时；serverStatus中的wiredTiger.cache页面eviction指标判断缓存是否不足。

容灾与备份策略

分片集群的备份不能简单mongodump——需要保证跨shard的一致性快照：

# 方法1：通过mongos执行一致性备份（4.2+）
mongodump --host mongos:27017 \
  --readPreference secondary \
  --numParallelCollections 4

# 方法2：各shard同时oplog时间点快照
# 在balancer停止状态下对每个shard执行
sh.stopBalancer()
# 对shard1 primary执行：
mongodump --host s1n1:27018 --oplog

# 方法3：LVM快照（最快速）
# 1. 锁定所有shard的secondary
db.fsyncLock()
# 2. 对每个secondary的data卷做LVM快照
lvcreate --snapshot --name snap_shard1 -L 50G /dev/vg0/shard1_data
# 3. 解锁
db.fsyncUnlock()

生产推荐：定时LVM快照 + 增量oplog归档到S3/OSS。恢复时先恢复config server元数据，再并行恢复各shard。RPO目标5分钟以内，RTO根据数据量从分钟级（LVM快照）到小时级（全量dump）不等。

总结

MongoDB分片集群是处理TB级数据的成熟方案。核心架构决策在于分片键选择——它决定了数据分布、查询效率和扩展上限。性能调优需系统化考虑：WiredTiger缓存配置、查询精准路由、索引ESR规则、读写分离策略。容灾备份需利用一致性快照或LVM快照保证跨shard数据一致性。合理配置的分片集群可在百节点规模下稳定支撑千万级QPS写入。