分区：一份数据太大，切开放到多台机器

一句话

分区（partitioning，也叫分片 / sharding）就是把一个大数据集切成若干互不重叠的小块，每块（一个分区）放在一台节点上，让存储和查询负载能横向摊到多台机器——这是数据「扩展」的核心手段。本章的全部张力集中在四件事上：怎么切才均匀（键范围 vs 哈希）、怎么防某一分区被压垮（热点 / 偏斜）、二级索引怎么办（本地索引 vs 全局索引）、以及加减节点时怎么把分区重新摊匀又少搬数据（再平衡）。

Glossary · 术语表

坐标

本章是 Part II「分布式数据」的第二章，紧接第 5 章复制。两者是一对互补的横向扩展手段，也常常叠加：复制是「同一份数据整份多放几处」，分区是「把大数据集切片、每片各放一处」。真实系统几乎都是「先分区、每个分区再复制几份」（见图 4）。分区又直接牵出下一层难题：一次操作若跨多个分区，就需要跨分区的一致性与协调——这正是第 7 章事务、第 9 章一致性与共识要接手的。本章可看作把第 5 章的「多副本」问题，换成了「多分片」问题。

这章要解决什么

复制解决了「一台挂了怎么办」和「读太多怎么办」，但它没解决数据本身太大——每台副本仍存着全量数据。设想一个社交应用：10 亿用户、几十 TB 数据、写入峰值每秒几十万条。这个量级下，单机的两道墙同时撞上来：硬盘装不下几十 TB；单机 CPU / 内存 / 磁盘 IO 扛不住几十万 QPS 的写。加副本没用——每份副本都得存全量、都得吃下全部写。

出路是把数据切开：每台只存 1/N 的数据、只处理落在自己这块上的请求，理论上加机器就能线性扩容。但切开会带来单机时代没有的三类新问题，本章逐一解决：① 按什么规则切，才能让数据和负载都摊得均匀、不出热点？② 二级索引（非主键查询）怎么在切开的数据上工作？③ 集群加减节点时，怎么把分区重新摊匀，还尽量少搬数据、且搬的时候不停服？ 切不好，扩容带来的不是性能，而是一个被挤爆的分区拖垮全局。

核心内容，讲透

① 分区的目标：把负载摊匀，躲开热点

分区的唯一敌人是偏斜（skew）：数据或请求不成比例地压在某些分区上，那些分区成了热点（hot spot），而扩容的初衷正是别让任何单点过载。最傻的「完全随机分」能摊得极匀，但代价是读的时候不知道数据在哪、只能问遍所有分区——不可用。所以真正的方案要在「摊得匀」和「找得到」之间取平衡，于是有了下面两种主流切法。

② 按键范围分区（range partitioning）

是什么：把键按顺序划成一段段连续区间，每个分区负责一段——像纸质百科全书按字母分卷（A–C 一卷、D–F 一卷）。区间边界可以人工设，也可由数据库自动选（让每段数据量大致相当）。分区内部按键有序存储（配合 LSM-tree / SSTable），于是范围扫描非常高效：查「某传感器在某天的全部读数」只需扫一个分区里连续的一段。用它的系统：Bigtable、HBase、RethinkDB、早期 MongoDB。

致命弱点是热点：如果键本身带有递增趋势——最典型的是用时间戳当键——那么所有新写入都砸向「今天」这一个分区，昨天的分区闲着、今天的被压垮。DDIA 给的解法是给键加前缀打散：比如把键从「时间戳」改成「传感器名 + 时间戳」，写入就按传感器名先散开；代价是查「所有传感器某时段的数据」时要对每个传感器各扫一段、再合并。

③ 按哈希分区（hash partitioning）

是什么：先用哈希函数把键搅成一个均匀分布的数字，再按这个哈希值的范围分区。好的哈希能把「偏斜的键」变成「均匀的哈希值」——哪怕大量键长得很像，打散后也均匀落在各分区。用它的系统：Cassandra、MongoDB（hashed sharding）、Voldemort。

代价是丢掉了范围查询：相邻的键（如连续的时间戳）被哈希打散到天南海北，「取一段连续键」就得问遍所有分区。Cassandra 的折中很经典：用复合主键（compound primary key）——第一列（分区键）拿去哈希决定落哪个分区，其余列在分区内部按序存储、可做范围扫描。于是「同一个用户的所有帖子按时间排」可以在一个分区里高效范围查，但跨用户就不行。这也是「先按 A 打散、再在每个 A 里按 B 有序」的通用套路。

顺带一提：常被提到的一致性哈希（consistent hashing）是 Karger 等人 1997 年为 CDN / Web 缓存提出的、把哈希值排成一个环来减少节点增减时的数据迁移；DDIA 特别提醒，数据库里说的「哈希分区」多半不是那篇论文严格意义上的一致性哈希，这个词用得挺乱，别被绕进去。

④ 热点：哈希也救不了「明星键」

哈希摊匀的是不同的键；可现实里常有同一个键被疯狂访问——名人账号发了条动态，几千万人同时读写同一条记录。这条记录的键哈希后只会落到一个分区，那台机器照样被打爆，哈希毫无帮助。DDIA 坦言：今天的系统大多还没法自动补偿这种「热键」，得靠应用层动手——最常见的招是给热键加盐（salting）：在键后面拼一个小随机数（比如 0–99），把一条热记录人为拆成 100 个键、散到 100 个分区去分担写。代价是读的时候要把这 100 份都读回来合并，还得自己记住「哪些键被拆过」——是个需要额外簿记的权宜之计。

⑤ 分区与二级索引：本地索引 vs 全局索引

前面都在讲按主键切数据。但真实查询常问的是「所有红色的车」「作者是张三的所有帖子」——这靠二级索引。麻烦在于：二级索引没法像主键那样干净地跟着分区走，因为「红色的车」可能散落在每一个分区里。DDIA 给了两种方案，是本章最容易考、也最容易搞混的一对：

方案 A · 本地索引 / 按文档分区（local / document-partitioned index）：每个分区只给自己那份数据建索引，各管各的。写很简单——改一条记录只动它所在的那一个分区（数据和它的索引都在一起）。但按二级索引读很贵：因为「红色的车」散在所有分区，你必须把查询发给每一个分区、再把结果汇总——这叫分散 / 聚集（scatter / gather），读延迟受最慢那个分区拖累，尾延迟容易被放大。用它的系统：MongoDB、Cassandra、Elasticsearch、SolrCloud、Riak、VoltDB。

方案 B · 全局索引 / 按词条分区（global / term-partitioned index）：把二级索引本身也切开，但不是按文档所在分区切，而是按被索引的值（词条 term）切——比如「所有 color=red 的索引项」集中放在索引分区 1，「color=blue」放索引分区 2。读快：查红色车只需问「持有 red 词条」的那一个索引分区，不用问遍全部。但写变复杂：改一条记录可能同时牵动好几个索引分区（它的颜色、价格、品牌词条各在不同分区），一次写就变成跨多个分区的分布式写——所以现实中全局索引的更新常常是异步的，意味着写完后短时间内索引可能还没跟上。用它的系统：DynamoDB 的全局二级索引（GSI）。

关键权衡与选型

本章的每个设计点都是一组取舍，且彼此独立、可自由组合（切法 × 索引方式 × 再平衡策略）。下面三张表把「什么场景选什么」摊开。

表 1 · 键范围分区 vs 哈希分区

表 2 · 本地（文档分区）索引 vs 全局（词条分区）索引

表 3 · 四种再平衡策略（加减节点时怎么重新摊分区）

三条实操心法：① 别用 hash mod N——它是再平衡的头号反面教材，一加节点就全体搬迁。② 分区数要「多于节点」但别太多：固定分区数方案里，分区是搬迁的最小单位，太少则扩容受限、太多则每个分区元数据 / 开销累积。③ 再平衡最好留个人工闸门——全自动再平衡叠加自动故障检测很危险：一个节点只是变慢被误判为「挂了」，触发再平衡 → 搬数据加重负载 → 更多节点显得像挂了 → 级联雪崩。让人「点一下确认」能挡掉大多数这类事故。

请求路由：找得到每条数据在哪

切完还剩最后一问：客户端要读某个键，怎么知道该连哪台节点？（分区还会因再平衡而搬动，这个映射是变化的。）DDIA 归纳三种做法：① 客户端随便连一个节点，那个节点要么自己处理、要么转发给对的节点；② 加一层路由层（routing tier），所有请求先到它、由它按分区映射转发（它自己不处理数据）；③ 客户端自己知道分区映射、直连目标节点。核心难点都一样——分区到节点的映射一变，谁来、怎么通知到做决策的那一方。许多系统靠一个独立的协调服务（如 ZooKeeper）专门维护这份集群元数据、变更时通知订阅者（HBase、SolrCloud、早期 Kafka 走这条）；Cassandra、Riak 则用节点间的gossip 协议互相同步、不依赖外部协调者；MongoDB 用专门的 config 服务器 + mongos 路由进程。

为什么重要 / 落到真实系统

分区是所有「大到单机装不下」的数据系统的地基。你在 MongoDB 里设 shard key、在 Cassandra 里定 partition key、在 Kafka 里给 topic 分 partition、在 DynamoDB 里挑 partition key——本质都是在本章的框架里做选择：range 还是 hash、本地还是全局索引、分区键会不会造成热点。面试里的高频题——「Kafka 分区数怎么定」「Cassandra 的 partition key 和 clustering key 有什么区别」「怎么避免热分区 / 热 key」「一致性哈希是什么、和取模有什么区别」「分库分表后二级查询怎么做」——答案全在这一章。选错分区键几乎是分布式数据库最常见、也最难补救的架构失误：它决定了数据怎么散、热点在哪、能不能范围查，而且一旦上线、数据填进去，重选分区键往往意味着一场浩大的数据迁移。

易错点与争议

• 把分区当成复制、或以为二选一：两者正交、通常叠加——先分区、每个分区再复制几份（见图 3）。「分了区就不用复制了」是常见误解。
• 迷信哈希能消灭所有热点：哈希摊匀的是不同的键；同一个热键（名人、爆款、全局计数器）哈希后仍落一个分区，照样打爆。热键得靠应用层加盐 / 拆分，数据库自己一般不管。
• 用时间戳等递增值当键（范围分区下）：所有新写砸向同一个末尾分区，写吞吐被单机卡死。要么改哈希，要么给键加高基数前缀打散。
• 随手用 hash mod N 定分区：看着简单，扩容时几乎全量数据搬家。要用「固定分区数」或「动态分区」等再平衡友好的方案。
• 低估分区键的不可逆：分区键决定了热点、范围能力和扩展性，且上线后极难更改——它是分布式数据建模里最该慎重、最该压力测试的一个决定。
• 全自动再平衡的陷阱：与自动故障检测叠加时，一次误判就可能引发「搬数据→更慢→更多误判」的级联失效；生产中常保留人工确认闸门。
• 「一致性哈希」名不副实：DDIA 明确提醒，数据库里说的哈希分区多半不是 Karger 论文那种严格的一致性哈希，别被术语混淆。

要点