MongoDB分片集群架构与组件角色

MongoDB分片集群通过水平分片实现数据分布和横向扩展，核心组件包括三个角色：mongos（路由服务器）、config server（配置服务器）和shard（数据分片）。mongos接收客户端请求，根据分片键路由到对应shard；config server存储集群元数据（分片范围映射、chunk分布）；shard存储实际数据，每个shard可以是一个副本集。

生产环境推荐部署架构：3个config server（CSRS副本集）、2个以上shard（每个shard为3节点副本集）、2个以上mongos（负载均衡前置）。部署命令示例：

# 1. 启动config server副本集（3节点）
mongod --configsvr --replSet csrs --dbpath /data/config --port 27019
mongod --configsvr --replSet csrs --dbpath /data/config2 --port 27020
mongod --configsvr --replSet csrs --dbpath /data/config3 --port 27021

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

# 2. 启动shard副本集（每个shard 3节点）
mongod --shardsvr --replSet shard1 --dbpath /data/shard1 --port 27001
# ... 初始化shard1副本集，同理部署shard2

# 3. 启动mongos路由
mongos --configdb csrs/cfg1:27019,cfg2:27020,cfg3:27021 --port 27017

# 4. 在mongos中添加分片
mongo --port 27017
sh.addShard("shard1/shard1a:27001,shard1b:27001,shard1c:27001")
sh.addShard("shard2/shard2a:27002,shard2b:27002,shard2c:27002")

# 5. 启用数据库分片
sh.enableSharding("ecommerce")

分片键选择策略与数据分布影响

分片键决定数据在shard间的分布方式，是分片集群设计中最关键的决策。分片键选择直接影响写入吞吐、查询效率和数据均衡。常见分片键策略：

**范围分片（Range-based）**：按分片键值范围划分chunk。适合范围查询，但容易导致热点写入（所有写入集中在最后一个chunk）。

**哈希分片（Hash-based）**：对分片键做哈希后分布，写入均匀分散，但不支持范围查询：

// 哈希分片：适合单调递增的_id字段
sh.shardCollection("ecommerce.orders", { "_id": "hashed" })

// 范围分片：适合需要范围查询的字段
sh.shardCollection("ecommerce.logs", { "timestamp": 1 })

// 复合分片键：兼顾范围查询和分布均匀
sh.shardCollection("ecommerce.orders", { "user_id": "hashed", "created_at": 1 })

复合分片键的设计原则：第一个键选择高基数（cardinality高）字段保证分布均匀，第二个键选择范围查询常用字段。上述user_id哈希保证写入均匀分布，created_at支持同一用户的订单按时间范围查询。

分片键一旦设置无法修改（MongoDB 4.2之前完全不可修改，4.2后支持refineCollectionShardKey追加字段但不支持替换）。选择分片键前需要评估：

– 基数（Cardinality）：分片键不同值的数量。低基数字段（如status只有3个值）导致数据集中在少数chunk。
– 频率（Frequency）：分片键值的分布是否均匀。如果某值占比50%，对应shard会承受50%的负载。
– 单调性（Monotonicity）：递增字段做范围分片会导致所有写入命中最后一个shard。

chunk迁移与均衡器调优

均衡器（Balancer）自动在shard间迁移chunk，保证数据分布均匀。默认配置下，当任意两个shard的chunk数量差超过迁移阈值时触发迁移：

// 查看均衡器状态
sh.getBalancerState()

// 查看均衡器窗口（迁移时间窗口）
sh.getBalancerWindow()

// 设置均衡器运行窗口（避开业务高峰）
db.settings.update(
  { _id: "balancer" },
  { $set: { activeWindow: { start: "02:00", stop: "06:00" } } },
  { upsert: true }
)

// 手动设置迁移阈值
db.settings.update(
  { _id: "balancer" },
  { $set: { _maxChunkSize: 64 } },  // 默认64MB
  { upsert: true }
)

// 查看chunk分布
db.getSiblingDB("config").chunks.aggregate([
  { $group: { _id: "$shard", count: { $sum: 1 } } }
])

// 手动迁移chunk
sh.moveChunk("ecommerce.orders", { user_id: ObjectId("...") }, "shard2")

chunk迁移过程中会短暂锁定chunk（MongoDB 4.2后采用并行迁移，不再锁定），默认每次迁移一个64MB chunk。生产环境建议设置均衡器窗口在低峰期运行，避免迁移I/O影响业务性能。

分片集群查询路由与性能优化

mongos路由查询时，根据查询条件是否包含分片键决定路由策略：

**定向查询（Targeted）**：查询包含分片键，mongos直接路由到对应shard，性能最优。

**广播查询（Scatter-Gather）**：查询不含分片键，mongos向所有shard发送查询并合并结果，延迟和负载随shard数量增长。

// 定向查询：包含分片键user_id，只命中一个shard
db.orders.find({ user_id: ObjectId("65a1b2c3...") })

// 广播查询：不含分片键，所有shard都要扫描
db.orders.find({ status: "paid" })

// 复合分片键的前缀查询：定向
db.orders.find({ user_id: ObjectId("65a1b2c3..."), created_at: { $gte: ISODate("2026-09-01") } })

// 非前缀查询：广播
db.orders.find({ created_at: { $gte: ISODate("2026-09-01") } })

优化方向：确保高频查询路径包含分片键前缀。对于不含分片键的查询，在分片键上创建索引可以减少扫描量。全局查询需要在应用层做结果合并和排序，mongos的limit会下发到每个shard分别限制，最终合并时可能不准确。

分片集群运维与故障处理

常见运维操作和故障场景处理：

// 添加新shard扩容
sh.addShard("shard3/shard3a:27003,shard3b:27003,shard3c:27003")

// 移除shard（先迁移数据）
sh.removeShard("shard2")
// 返回迁移进度: { msg: "draining ongoing", remaining: { chunks: 42, dbs: 1 } }

// 查看分片状态
sh.status()

// 查看库和集合的分片信息
db.getSiblingDB("config").databases.find()
db.getSiblingDB("config").collections.find()

// 诊断chunk迁移失败
db.getSiblingDB("config").chunks.find({ ns: "ecommerce.orders", jumbo: true })
// jumbo chunk: 超过最大迁移大小的chunk，需要手动split
sh.splitChunk("ecommerce.orders", { user_id: ObjectId("...") })

Jumbo chunk是指数据量超过_maxChunkSize的chunk，均衡器无法迁移。处理方法是手动splitChunk将其拆分为更小的chunk。如果分片键基数过低导致无法split（所有文档分片键值相同），需要重新评估分片键设计。

mongos连接池配置影响并发处理能力，驱动程序默认连接池大小100。高并发场景下在应用层调整：

// Node.js driver
const client = new MongoClient(uri, {
  maxPoolSize: 200,
  minPoolSize: 10,
  maxIdleTimeMS: 30000,
  connectTimeoutMS: 5000,
  socketTimeoutMS: 45000,
  serverSelectionTimeoutMS: 5000
});

监控分片集群的关键指标：各shard的chunk数量（通过config.channels聚合）、均衡器迁移队列长度、mongos到shard的连接延迟、各shard的opcounters（操作计数）。MongoDB Cloud Manager或Prometheus exporter提供这些指标的采集和告警能力。分片集群不适合所有场景——数据量低于单机承载能力时，副本集即可满足高可用需求，分片引入的复杂度和运维成本只有在数据量或写入吞吐超过单机上限时才有必要。