一致性Hash代码实现

losetowin 发布于:2016-12-6 14:26 分类:技术  有 3720 人浏览,获得评论 0 条 标签: 一致性哈希 

本文地址:http://www.dutycode.com/yizhixing_hash_shixian-2.html
除非注明,文章均为 www.dutycode.com 原创,欢迎转载!转载请注明本文地址,谢谢。

场景

上篇文章介绍到的《一致性hash算法(概念)》后台回复“一致性hash”即可得到链接,附上代码实现及另外一种问题的解决办法。

代码实现

代码就在这里了~~代码有点长,不贴代码了,附上github的地址:

可以直接到:https://github.com/losetowin/learnning (在此下的learning/com.dutycode.learning.consistenthash包下)

具体代码地址如下:

https://github.com/losetowin/learnning/blob/master/learnning/src/main/java/com/dutycode/learning/consistenthash/ConsistentHashDemo.java

直接看下结果

新增节点时,日志打印出现如下内容:

6A524C95-9E4C-4C17-BA3D-B08FF94F4F49.png

如图所示,当新增节点时,虚拟节点分散在了几个虚拟节点中,分别对应到目前已存在的几个真实节点: 10.0.0.1~10.0.0.4之间,也就意味着流量和数据分别分散到了现有的几个真实节点之上。

删除节点时:我们假定删除的节点是10.0.0.2节点:

日志打印如下:

D2D958E5-24BB-4F70-9E68-FF00562A9F41.png

如图所示,删除节点时,摘除真实缓存节点10.0.0.2之后,受到影响的虚拟节点为

VNode-10.0.0.3-Num-3

VNode-10.0.0.1-Num-2

VNode-10.0.0.3-Num-4

VNode-10.9.1.100-Num-2

也就意味着,删除节点后,原存储在10.0.0.2节点上的数据将迁移到10.0.0.3、10.0.0.1、10.9.1.100三台机器上,同时,虽然摘除了节点,但流量和数据压力并没有全部压到一台机器上,而是分散到了多台缓存服务器上。解决了之前提到的可能导致的雪崩问题。 

另外一种实现方法


关于节点宕机还有另外一种处理方式:
主备服务器切换方式

一致性hash的方式虽然能够避免雪崩的问题,但同时也带来的一个问题是,一旦某个节点宕机之后,一定存在着数据迁移的问题,如果数据量大的话,迁移数据的时间可能会比较长。

有一种办法,可以空间换时间,这里的时间是指宕机之后的数据恢复时间。

可以采用主备服务器的方式,一旦主服务器宕机,则备服务器立马提供服务,接替主服务器提供服务。 比如,redis的sentinel。

具体如下图所示:

02F7EBD8-5D37-4621-BC94-A5177256E86E.png

这样在主节点宕机之后,备用节点可以直接接替主节点,也就省去了数据迁移,同时对业务端也最友好。

但同时也会存在一定的问题:如果当前主节点容量或者抗压无法满足的时候,扩容便是件很难的事情。 假如流量很重,主节点宕机,那么这时候备用节点补上的时候,同样也会被压垮。

那如何解决呢?

可以结合一致性Hash来做。主备的方式来保证某个节点宕机的时候能够快速响应, 一致性Hash来保证单节点压力无法承受的时候快速低成本的扩容。 

关于上篇文章的一个修正

上篇文章提到一个问题:
『2、为什么是2^32个桶空间?』
但上篇文章对这个问题的解释不太正确,在这里做下更正:
桶空间的大小根据选用的hash算法来定,一般情况下,hash的返回结果为32位的整型数据,无符号的整型的最大值是2^32-1,最小值是0,一共2^32个数字,所以,桶空间也就是2^32个了。


版权所有:《攀爬蜗牛》 => 《一致性Hash代码实现
本文地址:https://www.dutycode.com/yizhixing_hash_shixian-2.html
除非注明,文章均为 《攀爬蜗牛》 原创,欢迎转载!转载请注明本文地址,谢谢。