一致性hash算法和实现

更新日期: 2019-07-29阅读: 2.2k标签: Hash

一致性hash算法是什么?

一致性hash算法,是麻省理工学院1997年提出的一种算法,目前主要应用于分布式缓存当中。

一致性hash算法可以有效地解决分布式存储结构下动态增加和删除节点所带来的问题。

在Memcached、Key-Value Store、Bittorrent DHT、LVS中都采用了一致性hash算法,可以说一致性hash算法是分布式系统负载均衡的首选算法。


传统hash算法的弊端

常用的算法是对hash结果取余数 (hash() mod N):对机器编号从0到N-1,按照自定义的hash算法,对每个请求的hash值按N取模,得到余数i,然后将请求分发到编号为i的机器。但这样的算法方法存在致命问题,如果某一台机器宕机,那么应该落在该机器的请求就无法得到正确的处理,这时需要将宕掉的服务器使用算法去除,此时候会有(N-1)/N的服务器的缓存数据需要重新进行计算;如果新增一台机器,会有N /(N+1)的服务器的缓存数据需要进行重新计算。对于系统而言,这通常是不可接受的颠簸(因为这意味着大量缓存的失效或者数据需要转移)。

传统求余做负载均衡算法,缓存节点数由3个变成4个,缓存不命中率为75%。计算方法:穷举hash值为1-12的12个数字分别对3和4取模,然后比较发现只有前3个缓存节点对应结果和之前相同,所以有75%的节点缓存会失效,可能会引起缓存雪崩。


一致性hash算法

首先,我们将hash算法的值域映射成一个具有2 32 次方个桶的空间中,即0~(2 32 )-1的数字空间。现在我们可以将这些数字头尾相连,组合成一个闭合的环形。

每一个缓存key都可以通过Hash算法转化为一个32位的二进制数,也就对应着环形空间的某一个缓存区。我们把所有的缓存key映射到环形空间的不同位置。

我们的每一个缓存节点也遵循同样的Hash算法,比如利用IP或者主机名做Hash,映射到环形空间当中,如下图


如何让key和缓存节点对应起来呢?很简单,每一个key的顺时针方向最近节点,就是key所归属的缓存节点。所以图中key1存储于node1,key2,key3存储于node2,key4存储于node3。


当缓存的节点有增加或删除的时候,一致性哈希的优势就显现出来了。让我们来看看实现的细节:

增加节点

当缓存集群的节点有所增加的时候,整个环形空间的映射仍然会保持一致性哈希的顺时针规则,所以有一小部分key的归属会受到影响。


有哪些key会受到影响呢?图中加入了新节点node4,处于node1和node2之间,按照顺时针规则,从node1到node4之间的缓存不再归属于node2,而是归属于新节点node4。因此受影响的key只有key2。


最终把key2的缓存数据从node2迁移到node4,就形成了新的符合一致性哈希规则的缓存结构。

删除节点

当缓存集群的节点需要删除的时候(比如节点挂掉),整个环形空间的映射同样会保持一致性哈希的顺时针规则,同样有一小部分key的归属会受到影响。


有哪些key会受到影响呢?图中删除了原节点node3,按照顺时针规则,原本node3所拥有的缓存数据就需要“托付”给node3的顺时针后继节点node1。因此受影响的key只有key4。


最终把key4的缓存数据从node3迁移到node1,就形成了新的符合一致性哈希规则的缓存结构。

说明:这里所说的迁移并不是直接的数据迁移,而是在查找时去找顺时针的后继节点,因缓存未命中而刷新缓存。

计算方法:假设节点hash散列均匀(由于hash是散列表,所以并不是很理想),采用一致性hash算法,缓存节点从3个增加到4个时,会有0-33%的缓存失效,此外新增节点不会环节所有原有节点的压力。

一致性hash算法的结果相比传统hash求余算法已经进步很多,但可不可以改进一下呢?或者如果出现分布不均匀的情况怎么办?比如下图这样,按顺时针规则,所有的key都归属于统一个节点。



一致性hash算法+虚拟节点

为了优化这种节点太少而产生的不均衡情况。一致性哈希算法引入了虚拟节点 的概念。

所谓虚拟节点,就是基于原来的物理节点映射出N个子节点,最后把所有的子节点映射到环形空间上。


虚拟节点越多,分布越均匀。使用一致性hash算法+虚拟节点这种情况下,缓存节点从3个变成4个,缓存失效率为25%,而且每个节点都平均的承担了压力。


一致性hash算法+虚拟节点的实现

原理理解了,实现并不难,主要是一些细节:

  1. hash算法的选择。Java代码不要使用hashcode函数,这个函数结果不够散列,而且会有负值需要处理。 
    这种计算Hash值的算法有很多,比如CRC32_HASH、FNV1_32_HASH、KETAMA_HASH等,其中KETAMA_HASH是默认的MemCache推荐的一致性Hash算法,用别的Hash算法也可以,比如FNV1_32_HASH算法的计算效率就会高一些。
  2. 数据结构的选择。根据算法原理,我们的算法有几个要求:
  • 要能根据hash值排序存储
  • 排序存储要被快速查找 (List不行)
  • 排序查找还要能方便变更 (Array不行)

另外,由于二叉树可能极度不平衡。所以采用红黑树是最稳妥的实现方法。Java中直接使用TreeMap即可。

原文 http://www.cnblogs.com/mseddl/p/11427563.html

链接: https://www.fly63.com/article/detial/5007

关于Webpack中hash的用法

在webpack的配置项中,可能会见到hash这样的字符。这种带哈希值的文件名,可以帮助实现静态资源的长期缓存,在生产环境中非常有用。带hash的文件是现在web启用缓存来提升性能比较建议的形式。

location.hash属性#_window.location.hash 使用

hash 属性是一个可读可写的字符串,该字符串是 URL 的锚部分(从 # 号开始的部分),#是用来指导浏览器动作的,都会被浏览器解读为位置标识符 , 这意味着这些字符都不会被发送到服务器端。对服务器端完全无用。所以,HTTP请求中不包括#。

vue-router之hash模式和history模式

hash模式即地址栏 URL 中的 # 符号(此 hash 不是密码学里的散列运算)。history模式利用了 HTML5 History Interface 中新增的 pushState() 和 replaceState() 方法。

多阶Hash算法

在分布式系统中,会经常用到K-V存储,一般实现的方式有红黑树或者哈希表,在Redis中还用到了跳表。都是通过一个确定的Key值,来查找Key附带的Value属性。本文会介绍一种高效的算法——多阶Hash。

webpack打包的3种hash值区别

我们都知道,webpack有各种hash值,包括每次项目构建hash,不同入口的chunkhash、文件的内容contenthash,这么多hash,它们有什么区别呢?

vue-router的两种模式:hash和history详解

Vue.js是一种流行的JavaScript框架,用于构建交互式Web应用程序。Vue-router是Vue.js框架中的一个重要组件,它允许您为应用程序创建路由。在Vue-router中,有两种不同的路由模式:hash模式和history模式

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!