MongoDB分片集群Shard Key路由策略与Chunk迁移均衡配置

MongoDB分片集群架构与数据分片原理

MongoDB分片集群通过水平拆分数据到多个Shard节点实现横向扩展，解决单机存储和吞吐瓶颈。集群由三个组件构成：Shard（数据分片，每个Shard是一个副本集）、Config Server（元数据存储，记录Shard Key范围到Shard的映射关系）和Mongos（路由进程，接收客户端请求并根据Shard Key路由到目标Shard）。

分片的核心是Shard Key——文档中的一个或多个字段，MongoDB根据该字段的值将文档分配到不同Chunk。Chunk是Shard Key值域的连续区间，默认大小64MB。当Chunk增长超过阈值时自动分裂，当各Shard间Chunk数量不均衡时由Balancer组件自动迁移Chunk。Shard Key的选择直接决定了数据分布均匀度、查询路由效率和写入性能，是分片集群设计中最关键的决策。

Shard Key类型：范围分片与哈希分片

MongoDB支持两种分片策略。范围分片（Ranged Sharding）按Shard Key值的自然顺序划分Chunk区间，支持范围查询的路由优化但容易产生热点写入。哈希分片（Hashed Sharding）对Shard Key计算64位散列值后按散列范围分片，写入均匀分布但不支持范围查询的定向路由。

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

// 方式1: 范围分片 - 适合范围查询频繁且写入均匀的场景
sh.shardCollection("ecommerce.orders", { "order_date": 1, "order_id": 1 })

// 方式2: 哈希分片 - 适合单调递增字段导致写入热点的情况
sh.shardCollection("ecommerce.events", { "event_id": "hashed" })

// 方式3: 复合分片 - 范围+哈希混合
sh.shardCollection("ecommerce.user_logs", {
    "user_id": 1,          // 范围分片：同一用户的日志在同一Chunk
    "timestamp": "hashed"  // 哈希分片：时间戳打散写入
})

范围分片在order_date为Shard Key时，同一天的所有订单会聚集在同一Chunk。批量写入当天订单时大量请求集中到一个Shard形成热点。哈希分片通过散列将写入分散到所有Shard消除热点，代价是按日期范围查询时需要scatter-gather（向所有Shard广播查询）。

Chunk分裂与迁移机制详解

Chunk分裂不涉及数据移动，仅更新Config Server中的元数据。当Chunk大小超过配置阈值时自动触发分裂。迁移是物理数据移动，由Balancer发起，将Chunk从Chunk数多的Shard迁移到Chunk数少的Shard。

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

// 查看各Shard的Chunk分布
db.getSiblingDB("config").chunks.aggregate([
    { $group: {
        _id: "$shard",
        chunkCount: { $sum: 1 },
        minKey: { $min: "$min.order_id" },
        maxKey: { $max: "$max.order_id" }
    }},
    { $sort: { chunkCount: -1 } }
])

// 查看特定Collection的分片范围
db.getSiblingDB("config").chunks.find({
    ns: "ecommerce.orders"
}).sort({ min: 1 })

// 手动分裂Chunk（通常不需要，自动分裂已足够）
sh.splitAt("ecommerce.orders", { "order_date": ISODate("2026-01-01") })
sh.splitFind("ecommerce.orders", { "order_date": ISODate("2026-06-15") })

// 手动迁移Chunk到指定Shard
sh.moveChunk("ecommerce.orders",
    { "order_date": ISODate("2026-03-01") },
    "shard-03"
)

迁移过程分三个阶段：Balander选择源Shard和目标Shard后初始化迁移；源Shard将Chunk数据发送到目标Shard（通过初始复制+增量oplog同步）；更新Config Server元数据将Chunk归属切换到目标Shard；源Shard删除已迁移数据。迁移期间Chunk仍可接受读写请求，从源Shard路由，迁移完成后切换到目标Shard。

Balancer配置与均衡窗口管理

Balancer默认持续运行，检测到任何两个Shard间Chunk数量差超过迁移阈值时触发迁移。迁移阈值根据Shard总数动态调整：Shard数小于等于20时阈值为2，21-79时为4，大于等于80时为8。生产环境中Balancer的迁移会消耗网络和I/O资源，通常配置在低峰期运行。

// 查看Balancer状态
sh.getBalancerState()

// 设置Balancer活动窗口（仅在凌晨2点到6点运行）
db.settings.update(
    { _id: "balancer" },
    { $set: { activeWindow: { start: "02:00", stop: "06:00" } } },
    { upsert: true }
)

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

// 重新启用
sh.enableBalancing("ecommerce.orders")

// 调整Chunk大小（默认64MB，大Chunk减少迁移频率但迁移时间长）
db.settings.update(
    { _id: "chunksize" },
    { $set: { value: 128 } },  // 128MB
    { upsert: true }
)

// 查看迁移历史
db.getSiblingDB("config").changelog.find({
    what: "moveChunk.commit"
}).sort({ time: -1 }).limit(10)

Chunk大小权衡：较小Chunk（如32MB）使数据分布更均匀，但分割和迁移更频繁，元数据量大。较大Chunk（如128MB）减少迁移频率但单次迁移耗时长，切换期间阻塞时间增加。64MB是MongoDB官方推荐值，适用于多数场景。

Shard Key选择策略与热点排查

选择Shard Key的四个原则：基数足够高（不同值数量远大于Shard数）、写入频率均匀分布、查询频率高的字段作为前缀、避免单调递增字段单独使用。常见错误是用MongoDB默认的ObjectId作为Shard Key，因其时间戳前缀单调递增导致所有写入集中到最后一个Chunk。

// 检查Shard Key基数
db.orders.aggregate([
    { $group: { _id: "$user_id", count: { $sum: 1 } } },
    { $sort: { count: -1 } },
    { $limit: 20 }
])

// 检查Chunk写入热点
db.getSiblingDB("config").chunks.aggregate([
    { $match: { ns: "ecommerce.orders" } },
    { $group: {
        _id: "$shard",
        chunkCount: { $sum: 1 }
    }},
    { $sort: { chunkCount: -1 } }
])

// 查看各Shard的写入QPS（通过serverStatus）
db.getSiblingDB("admin").serverStatus().opcounters

// explain分析查询路由
db.orders.explain("executionStats").find({
    user_id: "user-12345",
    order_date: { $gte: ISODate("2026-01-01") }
})

最优实践是使用复合Shard Key，前缀字段高基数且查询频繁，后续字段确保同前缀的文档分散到不同Chunk。例如电商订单表用{ user_id: 1, order_id: “hashed” }：user_id范围分片使同一用户的订单在相近Chunk便于聚合查询，order_id哈希打散同一用户的写入避免单Chunk热点。

分片集群扩容与数据重分布

新增Shard后Balancer自动将Chunk从现有Shard迁移到新Shard。大集群迁移持续数小时到数天，期间需要监控迁移速率和对业务的影响。MongoDB 5.0引入了基于采样器的均衡策略，根据数据量而非Chunk数量做均衡，提升分布精确度。

// 添加新Shard
sh.addShard("rs-shard-04/host04:27018,host05:27018,host06:27018")

// 监控迁移进度
db.getSiblingDB("config").changelog.countDocuments({
    what: "moveChunk.to",
    time: { $gt: new Date(Date.now() - 3600000) }  // 最近一小时
})

// 查看数据量分布（比Chunk数量更准确）
db.getSiblingDB("config").chunks.aggregate([
    { $match: { ns: "ecommerce.orders" } },
    { $group: {
        _id: "$shard",
        chunks: { $sum: 1 }
    }}
])

// 刷新路由缓存（添加Shard后Mongos需要刷新）
db.adminCommand("flushRouterConfig")

// Zone分片：将特定范围数据固定到指定Shard
sh.addTagRange("ecommerce.orders",
    { "region": "asia" },
    { "region": "asia" },
    "ASIA_ZONE"
)
sh.addTagRange("ecommerce.orders",
    { "region": "europe" },
    { "region": "europe" },
    "EUROPE_ZONE"
)

Zone Sharding（Zone分片）实现数据局部性：将特定Shard Key范围标记到Zone，再将Shard加入对应Zone。亚太用户数据自动路由到亚太Region的Shard减少跨区域延迟。这种模式下迁移仍由Balancer执行，但迁移目标固定在对应的Zone Shard集合内，不会跨Zone移动数据。