前言
分布式存储系统 面临着的首要问题，就是如何将 大量的数据 分布在 不同的存储节点 上。无论上层接口是 KV 存储、对象存储、块存储、亦或是 列存储，在这个问题上大体是一致的。本文将介绍如何 分布式存储系统 中 做数据分布目标 及可选的 方案，并试着总结和权衡他们之间的关系。
正文
(一) 指标
这里假设 目标数据 是以 key 标识的 数据块 或 对象。在一个包含 多个存储节点 的集群中，数据分布算法 需要为每一个给定的 key 指定 一个 或 多个 对应的 存储节点 负责，数据分布算法 有两个基本目标：
- 均匀性(Uniformity)：不同存储节点的 负载 应该 均衡;
- 稳定性(Consistency)：每次一个 key 通过 数据分布算法 得到的 分布结果应该保持 基本稳定，即使再有存储节点发生变化的情况下。
可以看出，这两个目标在一定程度上是 相互矛盾 的。当有 存储节点增加或删除时，为了保持稳定应该 尽量少 的进行 数据的移动 和 重新分配，而这样又势必会带来 负载不均衡。同样追求 极致均匀 也会导致较多的 数据迁移。
所以我们希望在这两个极端之间，找到一个点以获得合适的均匀性和稳定性。除了上述两个基本目标外，工程中还需要从以下几个方面考虑数据分布算法的优劣：
- 性能可扩展性：这个主要考虑的是算法相对于 存储节点规模 的 时间复杂度。为了整个系统的可扩展性，数据分布算法不应该在集群规模扩大后显著的增加运行时间。
- 考虑节点异构：实际工程中，不同 存储节点 之间可能会有很大的 性能 或 容量差异，好的数据分布算法应该能很好的应对这种 异构，提供 加权的数据均匀。
- 隔离故障域：为了 数据的高可用，数据分布算法应该为每个 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 四种分配算法。
(三) 应用案例
常见的 分布式存储系统 大多采用类似于 分片 的 数据分布和定位方式：
- Cassandra/Dynamo：采用 分片 的方式并通过 Gossip 协议在对等节点间通信;
- Redis Cluster：将 key Space 划分为 slots，同样利用 Gossip 协议通信;
- Zeppelin：将数据分片为 Partition，通过 Meta 集群提供 中心目录服务;
- Bigtable：将数据切割为 Tablet，类似于可变的分片，Tablet Server 可以进行分片的切割，最终分片信息记录在 Chubby 中;
- Ceph：采用 CRUSH 方式，由 中心集群 Monitor 提供并维护 集群拓扑 的变化。
