今天来系统梳理一下分布式系统中另一个核心命题：分片（Sharding）。

在分布式系统里，复制解决的是可用性和读扩展的问题，而当数据规模或写入吞吐量已经无法由单机承载时，分片几乎是不可回避的选择。

一、为什么需要分片？

我们进行分片最主要的原因是 可伸缩性（Scalability）。

通过分片：

• 可以把数据分散到多台机器上
• 把读写负载拆分并行处理
• 通过 水平扩展（Scale Out） 的方式支撑更大的数据量和更高的吞吐

但分片并不是免费的午餐，它也带来了一系列新的复杂性。

分片带来的问题

• 需要分区键：必须通过某个 key 才能快速定位数据在哪个分片
• 分片方案难以修改：一旦上线，调整成本通常非常高
• 对二级索引和关系型数据不友好
• 跨分片操作复杂，甚至需要分布式事务

因此，分片更适合 键值型或以主键访问为主的场景。

二、广义分片：面向多租户的分片

在广义上，分片并不只用于“技术层面的水平扩展”，它在 多租户系统（Multi-Tenant） 中同样非常重要。

典型场景包括：

• SaaS 产品
• 云服务
• 企业级平台

在这些系统中，租户本身就是天然的分片单元。

面向多租户分片的常见收益

1. 资源隔离：一个租户的高负载不会拖垮其他租户
2. 权限隔离：降低越权访问的风险
3. 基于单元（Cell-based）的架构：提升故障隔离能力
4. 按租户备份与恢复：运维与应急处理更简单
5. 法律合规性（如 GDPR）：支持数据导出、删除
6. 数据驻留：支持数据存放在特定地域

但这种方式也有前提：

• 每个租户的数据规模不能大到单机无法承载
• 否则就会回到“单租户内部再分片”的问题

三、狭义分片：键值数据的分片方式

更常见的讨论是 狭义上的分片 —— 对键值数据进行分片。

1️⃣ 按键的范围进行分片（Range Sharding）

直接在原始 key 上划定区间：

• 每个分片负责一个连续范围
• 类似于字典按字母区间分册

优点

• 支持高效的范围查询
• 数据在分片内天然有序

缺点

1. 热点问题
   • 键具有连续性（如时间戳）
   • 新写入会集中到同一个分片
2. 再平衡成本高
   • 分片数量变化时需要拆分或合并分片
   • 会引发大量数据迁移

2️⃣ 按键的哈希进行分片（Hash Sharding）

为了解决范围分片的热点问题，可以先对 key 做哈希，再基于哈希值分片。

哈希分片可以让键分布更加均匀，但实现方式并不只有一种。

常见的几种方案

（1）哈希取模节点数

node = hash(key) % N

• 实现简单
• 但节点数变化会导致几乎所有数据重新分布
• 再平衡代价极高，实践中不推荐

（2）固定数量的分片

• 预先创建大量分片（如 1000 个）
• hash(key) % shard_count
• 再将分片映射到节点

优点

• 节点增减时只移动分片，不重新 hash key
• 再平衡成本可控

缺点

• 分片数一旦定死，很难调整
• 分片过大或过小都会带来问题

（3）按哈希范围分片

• 每个分片负责一个连续的哈希值区间
• 分片可以动态拆分或合并
• 数据量变化时适应性更强

（4）一致性哈希

• 将哈希空间抽象成一个环
• key 映射到顺时针遇到的第一个节点
• 节点变化时，只影响少量 key

一致性哈希在缓存系统、KV 存储中非常常见，本质上是一种“隐式分片”。

四、热点与倾斜：哈希也解决不了一切

即使使用哈希分片，也无法避免 业务层面的热点问题。

典型场景

• 社交媒体中的热点帖子
• 明星账号
• 爆款商品

这种情况下：

• 单个 key 的访问量极高
• 这个 key 被称为 热键

常见应对方式

• 应用层打散
  
  • 在 key 前后加随机数
  • 将写入分散到多个逻辑 key
• 热键独立分片
  
  • 将单个热键放入独立分片
  • 甚至分配专用机器

这些方案往往是 工程妥协，需要额外的读合并和运维成本。

五、再平衡：自动还是手动？

分片系统绕不开 再平衡（Rebalance）。

• 再平衡是昂贵操作
• 涉及大量数据迁移
• 会对系统性能产生显著影响

自动 vs 手动

• 全自动
  
  • 运维成本低
  • 但行为不可预测
  • 容易引发级联故障
• 人工介入
  
  • 操作慢
  • 但更安全、更可控

在很多生产系统中：

再平衡过程中引入人为控制，反而是一种优势

六、请求路由：如何找到正确的分片？

从“请求一条数据”到“找到对应分片所在的节点”，中间还需要解决 请求路由 的问题。

常见三种方案

1. 客户端连任意节点
   • 节点自己转发请求
2. 引入独立路由层
   • 专门负责分片感知和转发
3. 客户端感知分片拓扑
   • 直接访问目标节点

面临的挑战

• 谁决定分片在哪个节点？
• 路由层是否是单点故障？
• 分片迁移期间如何保证请求正确？

常见解决方式

• 协调服务
  
  • ZooKeeper、etcd
  • 基于共识协议，防止脑裂
• 流言协议
  
  • 用于无主系统
  • 提供弱一致性保证（如 Cassandra）

七、分片与二级索引

分片通常依赖 主键 / 分区键，但很多业务场景需要通过 非主键字段查询。

例如：

查询所有“红色”的汽车

这就涉及二级索引，而二级索引在分片系统中是一个难题。

1️⃣ 本地二级索引

• 每个分片维护自己数据的索引
• 写入简单
• 查询需要 分散 / 聚集（Scatter-Gather）

问题

• 查询所有分片
• 容易产生尾部延迟放大

2️⃣ 全局二级索引

• 索引本身也进行分片
• 每个索引分片维护某一类值的 ID 列表

权衡

• 读更高效
• 写更复杂
• 可能需要分布式事务或接受最终一致性

总结

分片是分布式系统实现可伸缩性的核心手段，但它带来的复杂性远不止“数据拆开”这么简单。

• 分片方案一旦选错，后期代价极高
• 没有银弹，只有权衡
• 分片设计本质上是对业务访问模式的建模

理解分片，不只是理解一种算法，而是理解：

数据、负载、演化、运维之间的长期博弈