前言

分布式存储系统 面临着的首要问题，就是如何将 大量的数据 分布在 不同的存储节点 上。无论上层接口是 KV 存储、对象存储、块存储、亦或是 列存储，在这个问题上大体是一致的。本文将介绍如何 分布式存储系统 中 做数据分布目标 及可选的 方案，并试着总结和权衡他们之间的关系及优缺点。

正文

(一). 指标

这里假设 目标数据 是以 key 标识的 数据块 或 对象。在一个包含 多个存储节点 的集群中，数据分布算法 需要为每一个给定的 key 指定 一个 或 多个 对应的 存储节点 负责，数据分布算法 有两个基本目标：

• 均匀性(Uniformity)：不同存储节点的 负载 应该 均衡；

• 稳定性(Consistency)：每次一个 key 通过 数据分布算法 得到的 分布结果 应该保持 基本稳定，即使再有存储节点发生变化的情况下。

可以看出，这两个目标在一定程度上是 相互矛盾 的。当有 存储节点增加或删除 时，为了保持稳定应该 尽量少 的进行 数据的移动 和 重新分配，而这样又势必会带来 负载不均衡。同样追求 极致均匀 也会导致较多的 数据迁移。

所以我们希望在这两个极端之间，找到一个点以获得合适的均匀性和稳定性。除了上述两个基本目标外，工程中还需要从以下几个方面考虑数据分布算法的优劣：

1. 性能可扩展性：这个主要考虑的是算法相对于 存储节点规模 的 时间复杂度。为了整个系统的可扩展性，数据分布算法不应该在集群规模扩大后显著的增加运行时间。

2. 考虑节点异构：实际工程中，不同 存储节点 之间可能会有很大的 性能 或 容量差异，好的数据分布算法应该能很好的应对这种 异构，提供 加权的数据均匀。

3. 隔离故障域：为了 数据的高可用，数据分布算法应该为每个 key 找到 一组存储节点，这些节点可能提供的是 数据的镜像副本，也可能是类似 擦除码 的副本方式。数据分布算法应该尽量 隔离 这些副本的故障域，如 不同机房、不同机架、不同交换机、不同机器。

(二). 演进

看完算法的评价指标后，接下来介绍一些可能的方案演进，并分析他们的优劣。这里假设 key 的值足够分散。

1. Hash

一个简单直观的想法是直接用 Hash 来计算，简单的以 Key 做 哈希 后 对节点数取模。可以看出，在 key 足够分散的情况下，均匀性 可以获得，但一旦有 节点加入 或 退出 时，所有的原有节点都会受到影响。稳定性 无从谈起。

2. 一致性Hash

一致性 Hash 可以很好的解决 稳定性问题，可以将所有的 存储节点 排列在收尾相接的 Hash 环上，每个 key 在计算 Hash 后会 顺时针 找到先遇到的 存储节点 存放。而当有节点 加入 或 退出 时，仅影响该节点在 Hash 环上 顺时针相邻 的 后续节点。但这有带来 均匀性 的问题，即使可以将存储节点等距排列，也会在 存储节点个数 变化时带来 数据的不均匀。而这种可能 成倍数的不均匀 在实际工程中是不可接受的。

3. 带负载上限的一致性Hash

一致性 Hash 有 节点变化时不均匀的问题。Google 在 2017 年提出了 Consistent Hashing with Bounded Loads 来控制这种 不均匀的程度。简单的说，该算法给 Hash 环上的每个节点一个 负载上限 为 1 + e 倍的 平均负载，这个 e可以自定义。当 key 在 Hash 环上 顺时针 找到合适的节点后，会判断这个节点的 负载 是否已经 到达上限，如果 已达上限，则需要继续找 之后的节点 进行分配。

如上图所示，假设每个桶 当前上限 是 2，红色的小球按序号访问，当编号为 6 的红色小球到达时，发现顺时针首先遇到的 B（3，4），C（1，5）都已经 达到上限，因此最终放置在桶 A 里。

这个算法最吸引人的地方在于 当有节点变化 时，需要迁移的数据量是 1/e^2 相关，而与 节点数 或 数据数量 均无关。

也就是说当 集群规模扩大 时，数据迁移量 并不会随着显著增加。另外，使用者可以通过调整 e 的值来控制 均匀性 和 稳定性 之间的权衡，就是一种 以时间换空间 的算法。总体来说，无论是 一致性 Hash 还是 带负载限制 的 一致性 Hash，都无法解决 节点异构 的问题。

4. 带虚拟节点的一致性Hash

为了解决 负载不均匀 和 异构 的问题，可以在 一致性 Hash 的基础上引入 虚拟节点。即 hash 环上的 每个节点 并不是 实际 的 存储节点，而是一个 虚拟节点。实际的 存储节点 根据其 不同的权重，对应 一个 或 多个虚拟节点，所有落到相应虚拟节点上的 key 都由该 存储节点负责。

如下图所示，存储节点 A 负责 (1,3]，(4,8]，(10, 14]，存储节点 B 负责 (14,1]，(8,10]。

这个算法的问题在于，一个 实际存储节点 的 加入 或 退出，会影响 多个虚拟节点的重新分配，进而引起 很多节点 参与到 数据迁移 中来。

另外，实践中将一个 虚拟节点 重新分配给 新的实际节点 时，需要将这部分数据 遍历 出来 发送给新节点。我们需要一个更合适的 虚拟节点切分 和 分配方式，那就是 分片。

5. 分片

分片 将 哈希环 切割为 相同大小的分片，然后将这些 分片 交给 不同的节点 负责。

注意这里跟上面提到的 虚拟节点 有着很 本质的区别：分片的划分和分片的分配被解耦。

一个 节点退出 时，其所负责的 分片 并不需要 顺时针合并 给之后节点，而是可以更灵活的 将整个分片 作为一个 整体 交给 任意节点。在实践中，一个 分片 多作为 最小的数据迁移 和 备份单位。

而也正是由于上面提到的 解耦，相当于将原先的 key 到 节点 的 映射 拆成了两层。需要一个 新的机制 来进行 分片 到 存储节点 的 映射。由于 分片数 相对 key 空间已经很小并且 数量确定，可以更精确地初始设置，并引入 中心目录服务 来根据 节点存活 修改 分片的映射关系。同时将这个 映射信息 通知给所有的 存储节点 和 客户端。

上图是 分布式KV存储 Zeppelin中的 分片方式，Key Space 通过 Hash 到 分片，分片及其副本 又通过一层映射到 最终的存储节点 Node Server。

6. CRUSH算法

CRUSH 算法本质上也是一种 基于分片 的数据分布方式，其试图在以下几个方面进行优化：

• 分片映射信息量：避免 中心目录服务 和 存储节点 及 客户端之间 交互大量的 分片映射信息，而改由 存储节点 或 客户端 自己根据 少量 且 稳定 的集群节点拓扑和确定的规则自己计算分片映射。

• 完善的故障域划分：支持 层级 的 故障域控制，将 同一分片 的 不同副本 按照配置划分到 不同层级 的 故障域中。

客户端 或 存储节点 利用 key、存储节点 的 拓扑结构 和 分配算法，独立的进行 分片位置 的计算，得到一组负责对应 分片 及 副本 的 存储位置。

如图所示是 一次定位 的过程，最终选择了一个 row 下的 cab21，cab23，cab24 三个机柜下的三个存储节点。

当 节点变化 时，由于 节点拓扑 的变化，会影响 少量分片 数据进行迁移，如下图是加入 新节点 引起的 数据迁移。通过良好的 分配算法，可以得到很好的 负载均衡 和 稳定性，CRUSH 提供了 Uniform、List、Tree、Straw 四种分配算法。

(三). 应用案例

常见的 分布式存储系统 大多采用类似于 分片 的 数据分布和定位方式：

1. Cassandra/Dynamo：采用 分片 的方式并通过 Gossip 协议在对等节点间通信；

2. Redis Cluster：将 key Space 划分为 slots，同样利用 Gossip 协议通信；

3. Zeppelin：将数据分片为 Partition，通过 Meta 集群提供 中心目录服务；

4. Bigtable：将数据切割为 Tablet，类似于可变的分片，Tablet Server 可以进行分片的切割，最终分片信息记录在 Chubby 中；

5. Ceph：采用 CRUSH 方式，由 中心集群 Monitor 提供并维护 集群拓扑 的变化。

欢迎关注技术公众号： 零壹技术栈

本帐号将持续分享后端技术干货，包括虚拟机基础，多线程编程，高性能框架，异步、缓存和消息中间件，分布式和微服务，架构学习和进阶等学习资料和文章。