浅谈分布式存储系统数据分布算法

目录

前言

指标

演进

应用案例

---

前言

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

 

 

指标

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

1. 均匀性(Uniformity)：不同存储节点的负载应该均衡；
2. 稳定性(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/e2 相关，而与节点数或数据数量均无关。也就是说当集群规模扩大时，数据迁移量并不会随着显著增加。另外，使用者可以通过调整 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 算法本质上也是一种基于分片的数据分布方式，其试图在以下几个方面进行优化：

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

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

客户端或存储节点利用 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 提供并维护集群拓扑的变化。

 

转载自：https://juejin.im/post/5b38cffae51d4558e36037ec