第7章 分片集群：横向扩展的代价

第 7 章 · 分片集群：横向扩展的代价

章节摘要：分片集群由 mongos 路由、config 服务与多个分片组成，按分片键把数据水平拆开。本章从一次热点分片事故与一次迁移风暴事故讲分片架构、部署、分片键选择与再分片。读完本章，你能判断"该不该分片"，并选出一个不后悔的分片键。

学习目标

1. 能画出 mongos、config、shard 三层架构与数据寻址过程；
2. 能描述 chunk 分裂与 balance 迁移的触发条件；
3. 能用 hashed/range 两类键分析数据分布；
4. 能识别单调递增键、低基数键两类高危选择。

核心概念速览

金句：分片键是给数据定的"户口"——迁户口（再分片）要停写排期数周，落户前请三思。

子章节导航

• 7.1 分片架构：热点分片事故，讲路由、chunk 与哈希/范围两类键。复盘揭示了扩容的讽刺循环：买新机器、热点照旧、还多背搬迁负载；scatter-gather 广播查询的账单要算细——延迟随分片数线性恶化，"让高频查询携带分片键"是先于一切的设计军规。
• 7.2 部署与迁移：迁移风暴事故，讲搭建流程与 balancer 管理。风暴时间线还原了 chunk 迁移"复制、追日志、改路由"三步的真实流量代价；zone 受控放置与预分裂两个进阶手段，分别解决"数据必须住哪"和"别让新集合从集中分裂开始"两类需求。
• 7.3 分片键选择：低基数键整改事故，讲选键判据与再分片。34 个 chunk 的天花板复盘给出"两期走"的整改框架——refine 止血、新集合根治，分片键事故的整改是成本分期题而非单纯技术选型题；哈希键与复合键的边界讨论配合真实写入样本统计法，把选键从经验判断变成数据对齐。

子章节之间的逻辑关系

7.1 讲数据怎么被拆开、找到；7.2 讲拆完怎么搬平衡；7.3 回到源头——键怎么选才不用事后大动干戈。倒着读也成立：7.3 的键选对了，7.2 的 balancer 风暴多半不会发生；7.1 的广播查询过多，往往正是 7.3 选键时没看查询日志的后果。三章合起来是一个因果链的两端，中间隔着时间的延迟兑现。

  架构与寻址(7.1) ──► 迁移与平衡(7.2) ──► 选键判据(7.3)
        │                   │                  │
     mongos·chunk        balancer          基数·写分布
​

本章还该回答一个前置问题：该不该分片。单集合数据量与索引总体积能在单机内存的合理倍数内放下、写入未到单机瓶颈时，复制集加纵向扩容仍是更简单的答案——分片换来的扩展性，每一分都用运维复杂度支付。先问"该不该"，再问"怎么分"，顺序反了就是给自己发牌。

本章知识点核对清单

离开本章前逐条自查：能否画出 mongos、config、shard 三层并说清一次带分片键查询的完整寻址路径；能否解释 chunk 分裂与迁移各自的触发条件、以及 jumbo chunk 为什么会让均衡器停摆；能否对着 sh.status() 的分布表判断是否存在热点或冻结；能否用选键四问评估自己业务的主集合；能否说出 refineCollectionShardKey 能解什么、不能解什么。任何一条卡住，回对应小节的事故复盘重走一遍定位过程。

一个常被问到的边界

评审会上最常被问到的边界问题：数据量到多少才必须分片。经验数字是单集合索引工作集明显超过 WiredTiger 缓存、且纵向加内存的成本曲线变陡时，通常落在单节点几 TB 量级；但比数字更可靠的是第 10 章的三个指标——缓存命中率、扫描量与复制延迟，它们先于容量上限报警。把分片决策挂在这三个指标上，比挂在一个拍出来的 GB 数上更能经住复盘。

前置知识与后续延伸

前置：第 6 章复制集（每个分片就是一个复制集）。延伸：分片集群的监控指标在第 10 章，跨分片操作与事务限制在第 8 章。