查看原文
其他

一致性哈希及其在Greenplum中的应用

点击上方蓝色字体,选择“设为星标
回复”资源“获取更多资源前言

一致性哈希(consistent hashing)是分布式系统中非常重要的算法,在平滑扩缩容、动态负载均衡等方向有大量应用。相对于传统的线性(取模)哈希算法,一致性哈希可以保证在分布式哈希表中的桶数量发生变化时,受到影响需要重新映射的key尽量少。本文先简要复习下经典的割环一致性哈希方案,然后介绍它的变种——跳跃一致性哈希(jump consistent hash)。

割环一致性哈希

一致性哈希的概念最初在1997年由David Karger等大佬提出,原始论文见Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web,起初是为了解决网络中的热点问题,后来发展成分布式系统中通用的算法。为了与此后出现的其他一致性哈希算法相区别,一般将这个经典方法称为“割环法”。该算法能够满足论文中提出的两大目标,即平衡性(balance)和单调性(monotonicity)。

顾名思义,割环法将整个哈希空间组织成一个首尾相接的圆环,一般设为[0, 232 - 1]。以分布式K-V存储为例,哈希桶即为存储节点。将节点N的编号或IP等按哈希函数hash(N)映射在环上,再将数据的key按同样的哈希函数hash(k)映射在环上,数据就会存储在环上以顺时针方向遍历找到的第一个节点。当节点扩容或缩容时,仍然按照顺时针原则,将受到影响的区间内的数据重新分布到相邻的节点上去,达到增量更新的目的,即满足单调性。以下3张图能够简单地说明。

虽然哈希函数的结果是均匀的,但节点映射在环上可能不均匀,节点数越少,数据倾斜的可能性就越大。解决此问题的方法是将物理节点虚拟成多个影子节点,数据经过哈希后按顺时针原则落到影子节点指向的物理节点上。如果我们想要人为干预各节点上数据量的权重,还可以指定不同的影子节点数量。如下图所示,影子节点数量为3:2:2:1。

虚拟节点扩缩容时的数据迁移方法与仅采用物理节点相同,因此调整权重值也会触发数据迁移。

对于有N个桶和K个键的一致性哈希方案,其时间复杂度是:

  • 添加、删除节点——O(K / N + logN);

  • 添加、删除key——O(logN)。

其中,O(K / N)是数据重分布操作的平均代价,O(log N)则是在环上进行二分查找定位哈希桶的代价。

最后有一个小问题:节点扩缩容以及节点宕机时如何保证系统仍然可用呢?有两种直接的思路:

  • 中继——如果在某个节点上查不到所需的数据,就把请求转发给该节点的顺时针方向下一个节点进行处理。

  • 双写——每次写入数据时,都另外写一份到目标节点的顺时针方向下一个节点。

割环法已经能够满足一般分布式系统中的多数需求,Cassandra、Memcached等著名的存储系统都用到了它(注意Redis Cluster并没有)。下面介绍思想更加精妙,效率也更高的跳跃一致性哈希(jump consistent hash)方法。

跳跃一致性哈希

这个算法比较年轻,在2014年由Google的大佬John Lamping和Eric Veach提出,原始论文见A Fast, Minimal Memory, Consistent Hash Algorithm。它的实现非常简洁,仅有5行代码,如下。

int32_t JumpConsistentHash(uint64_t key, int32_t num_buckets) {
int64_t b = 1, j = 0;
while (j < num_buckets) {
b = j;
key = key * 2862933555777941757ULL + 1;
j = (b + 1) * (double(1LL << 31) / double((key >> 33) + 1));
}
return b;
}

看官可能还无法理解为什么能这样实现,接下来重走一遍论文的推导思路。

假设最终要求的满足平衡性和单调性的哈希函数是ch(k, n)(k为数据的键,n为哈希桶的数量),有如下简单的递推关系:

  • 当n = 1时,所有key都要映射到同一个桶中,即ch(k, 1) = 0;

  • 当n = 2时,为保证均匀性,需有K / 2个key分别映射到两个桶中(K是key的总数量),故K / 2个key需要重新映射;

  • ......

  • 当桶数量由n变为n + 1时,有K / (n + 1)个key需要重新映射。

那么该如何决定哪些key被重新映射到新的桶中呢?答案是采用线性同余法(LCG)生成的伪随机数决定。上文中的magic number 2862933555777941757就是线性同余法的乘数a。

以k作为种子生成一个伪随机数序列,可以保证对于确定的k,ch(k, n)的结果也是确定的,进而使用条件rand < 1 / (j + 1)即可保证哈希桶由j个变为j + 1个时,有1 / (j + 1)比例的数据会重新映射。

此时ch()函数的逻辑如下,时间复杂度显然为O(n)。

int ch(int key, int num_buckets) {
random.seed(key);
int b = 0; // This will track ch(key, j+1).
for (int j = 1; j < num_buckets; j++) {
if (random.next() < 1.0 / (j + 1)) b = j;
}
return b;
}

这个复杂度比割环法还要高,如何优化?容易想到,rand < 1 / (j + 1)的概率肯定是相对小的,也就是说随着j的增大,发生重分布的key的比例越来越小,j可以不必逐次自增,而是跳跃前进,这也就是算法名称中"jump"一词的由来。

观察上面的代码,b表示k最后一跳的目的哈希桶的编号,即满足条件:

ch(k, b + 1) ≠ ch(k, b) && ch(k, b + 1) = b

假设k连续不跳变,直到增加到j + 1个桶才发生跳变,可知此概率为:

[(b + 1)/(b + 2)] * [(b + 2)/(b + 3)] * ... * [(j - 1)/j] = (b + 1) / j

或者表示为:

P[j ≥ i] = P[ch(k, i) = ch(k, b + 1)] = (b + 1) / i

图示如下。

那么,j最多可以直接跳到哪里才不至于漏掉原有的循环过程呢?容易得知,要满足rand < (b + 1) / j,需要j < (b + 1) / rand,将其向下取整即可。改进后的ch()函数如下。

int ch(int k, int n) {
random.seed(k);
int b = -1, j = 0;
while (j < n) {
b = j;
r = random.next();
j = floor((b+1) / r);
}
return b;
}

将random替换为具体的LCG,就是本节开头的算法了。

分析时间复杂度:对于任意一个k,在哈希桶数从1增加到n的过程中,发生跳跃的期望次数是1 / 2 + ... + 1 / i + ... + 1 / n。根据欧拉常数的定义,调和级数与自然对数的差值的极限会收敛到一个小数,因此跳跃一致性哈希算法的复杂度是O(ln n),比割环法更优。

根据论文给出的实验数据,跳跃一致性哈希产生的分布的标准差远远比割环法小,也就是非常均匀。

随着桶数量的增加,跳跃一致性哈希算法的执行时间增长也不明显。

另外,它不需要额外的数据结构,内存占用极小(即论文标题中所说的minimal memory)。

但是,它相对于割环法而言有个非常大的缺点,即只能在哈希桶序列的尾部添加和删除桶,而不能在中间增删。显而易见,如果在中间增删桶,由于桶的标号是按自然顺序来的,因此会导致后方所有桶的标号发生变化,不再满足一致性哈希的基本性质。

仍然考虑节点扩缩容以及节点宕机时如何保证系统仍然可用的问题。

  • 中继——如果在尾部的哈希桶j + 1中查不到所需的数据,就把请求转发给ch(k, j)桶,即它的上一跳节点。

  • 双写——每次写入数据时,如果写入的是尾部的哈希桶j + 1,就另外写一份到ch(k, j);如果写入的是非尾部的哈希桶i,就另外写一份到i + 1。这样,不管是哪个节点失败,数据都不会丢失。

Greenplum中的应用

Greenplum提供了一个为集群扩容的工具gpexpand。在GP v5中,执行gpexpand时需要将所有哈希分布改为随机分布,按照新的集群规模重新根据hash key计算哈希值,再将数据重新均衡到各个segment节点上,相当于进行了一次完全的shuffle,如下图所示。

这种方式的缺点显而易见:集群在扩容期间处于不可用状态,数据交换量巨大。并且在数据由随机分布转为新的哈希分布之前,无法利用数据的本地性信息做查询优化,拖累性能。

在GP v6中,通过将跳跃一致性哈希引入gpexpand,实现了完全在线、高性能的集群扩容方式。如下图所示,将集群由3节点扩容到4节点,只有1/4的数据需要重分布。

GP v6的跳跃一致性哈希实现与Google原版完全相同。

另外,如何保证那些没有重分布完毕的表被正确地查询呢?GP v6在catalog表gp_distribution_policy里加入了一个新的字段numsegments,表示一张表的数据分布在前numsegments个节点上。因此,就算扩容的过程中有事务正在运行,只要numsegments没有改变,就仍然只在原有节点上执行查询。

最后,可以通过全局配置gp_use_legacy_hashops设定是否改回旧版的取模哈希方式,默认当然为false。


一万五千字详解HTTP协议

Spark如何协调来完成整个Job的运行详解

最新Hive/Hadoop高频面试点小集合

欢迎点赞+收藏+转发朋友圈素质三连
文章不错?点个【在看】吧! 
: . Video Mini Program Like ,轻点两下取消赞 Wow ,轻点两下取消在看

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存