首页 > 代码库 > 一致性哈系算法
一致性哈系算法
使用场景
现在我们假设有100台redis data服务器,一份数据101进来的时候,以散列公式hash(i)&100,计算所存放的服务器,假设hash(i) = i,那么数据被散列到标号为1的服务器,然后这个时候服务器新增了一台,然后散列公式为hash(i)%101,这个时候请求访问数据101的时候,被分配至0号服务器,但是其实这个时候数据是在1号服务器的。
所以这个时候大量的数据失效了(访问不到了)。
所以这个时候,我们假设是新增了服务器,如果是持久化存储的,我们可以让服务器集群对数据进行重新散列,进行数据迁移,然后进行恢复,但是这个时候就意味着每次增减服务器的时候,集群就需要大量的通信,进行数据迁移,这个开销是非常大的。如果只是缓存,那么缓存就都失效了。所以这个时候怎么办?
我们可以看到,关键问题在于,服务器数量变动的时候,要能够保证旧的数据能够按照老的算法,计算到数据所在的服务器,而新的数据能够按照新的散列算法,计算出数据所在的服务器。
如上图,我们有ABCD四台服务器,这四台服务器被分配至0~232 的一个环上,比如0~230的存储在A服务器,230 +1~231 存储到B服务器上.....CD按照这样的进行均分。将我们的散列空间也划为0~232 ,然后数据进来后对232 取模,得到一个值K1,我们根据K1在环上所处的位置,得到所分配到的服务器,如图,K1被分配到B服务器。 这个时候,我们有一台服务器B失效了。
我们可以看到,如果是B失效了,那么如果有持久化存储的,需要做数据恢复,将B的数据迁移至C即可,对于原本散列在A和D的数据,不需要做任何改变。 同理,如果我们是新增了服务器,那么只需要对一台服务器的数据迁移一部分至新加的服务器即可。
一致性hash算法,减少了数据映射关系的变动,不会像hash(i)%N那样带来全局的变动
而且这样还有个好处,假设我们使用UID作为散列范围(即上面的232 ),那么假设有部分UID的访问很频繁,而且这部分UID集中在B服务器上,那么就造成了B的负载远远高于其他服务器。这就是热点数据的问题。这个时候我们可以向B所在的UID空间添加服务器,减少B的压力。
其实还有个更好的解决办法:虚拟节点。
上面说的情况是,使用真实的服务器作为节点散列在232 上。 我们假设,只有4台服务器(如上图),然后A上面有热点数据,结果A挂掉了,然后做数据恢复,A的数据迁移至B,然后B需要承受A+B的数据,也承受不住,也挂了。。。。然后继续CD都挂了。这就造成了
雪崩效应。
上面会造成雪崩效应的原因分析:
如果不存在热点数据的时候,每台机器的承受的压力是M/2(假设每台机器的最高负载能力为M),原本是不会有问题的,但是,这个时候A服务器由于有热点数据挂了,然后A的数据迁移至B,导致B所需要承受的压力变为M(还不考虑热点数据访问的压力),所以这个失败B是必挂的,然后C至少需要承受1.5M的压力。。。。然后大家一起挂。。。
所以我们通过上面可以看到,之所以会大家一起挂,原因在于如果一台机器挂了,那么它的压力全部被分配到一台机器上,导致雪崩。
如果我们A挂了以后,数据被平均分配到BCD上,每台机器多承受M/6的压力,然后大家就都不会挂啦(不考虑热点数据)。
这里引入虚拟节点,如图:
环上的空间被划分为8份,然后A存储A1和A2。。。
这个时候,如果A服务器挂了,访问压力会分配至C2和D1,也就是C和D服务器,而不是像前面,全部被分配到B上。
引入虚拟节点,主要在于,如果一台服务器挂了,能够将压力引流至不同的服务器。
总结:一致性hash算法(DHT)通过减少影响范围的方式解决了增减服务器导致的数据散列问题,从而解决了分布式环境下负载均衡问题,如果存在热点数据,那么通过增添节点的方式,对热点区间进行划分,将压力分配至其他服务器。重新达到负载均衡的状态。
tair的负载均衡就是采用的一致性hash算法啦~~~
一致性hash算法在分布式环境中应用的很广,只要是涉及到分布式存储的负载均衡问题,一致性hash都是很好的解决的方案。
一致性哈系算法