1. 普通 Hash 算法存在的问题
普通Hash算法存在一个问题,以ip_hash为例,假定下载用户ip固定没有发生改变,现在tomcat3出现了问题,down机了,服务器数量由3个变为了2个,之前所有的求模都需要重新计算。
说明:
如果在真实生产情况下,后台服务器很多台,客户端也有很多,那么影响是很大的,缩容和扩容都会存在这样的问题,大量用户的请求会被路由到其他的目标服务器处理,用户在原来服务器中的会话都会丢失。
2. 一致性 Hash 算法
一致性哈希算法思路如下:
首先有一条直线,直线开头和结尾分别定为为1
和2的32次方减1
,这相当于一个地址,对于这样一条线,弯过来构成一个圆环形成闭环,这样的一个圆环称为hash环
。我们把服务器的ip或者主机名求hash值
然后对应到hash环上
,那么针对客户端用户,也根据它的ip进行hash求值,对应到环上某个位置,客户端路由按照顺时针方向找最近的服务器节点
服务器下线的情况:
假如将服务器3下线,服务器3下线后,原来路由到3的客户端重新路由到服务器4,对于其他客户端没有影响只是这一小部分受影响(请求的迁移达到了最小,这样的算法对分布式集群来说非常合适的,避免了大量请求迁移)
增加服务器的情况
增加服务器5之后,原来路由到3的部分客户端路由到新增服务器5上,对于其他客户端没有影响只是这一小部分受影响(请求的迁移达到了最小,这样的算法对分布式集群来说非常合适的,避免了大量请求迁移)
数据请求倾斜问题
1)如前所述,每一台服务器负责一段,一致性哈希算法对于节点的增减都只需重定位环空间中的一小部分数据,具有较好的容错性和可扩展性。但是,一致性哈希算法在服务节点太少时,容易因为节点分部不均匀而造成数据倾斜问题
。例如系统中只有两台服务器,其环分布如下,节点2只能负责非常小的一段,大量的客户端请求落在了节点1上,这就是数据(请求)倾斜问题
2)为了解决这种数据倾斜问题,一致性哈希算法引入了虚拟节点机制,即对每一个服务节点计算多个哈希,每个计算结果位置都放置一个此服务节点,称为虚拟节点
。
实现方式:
在服务器ip或主机名的后面增加编号来实现。比如,可以为每台服务器计算三个虚拟节点,于是可以分别计算"节点1的ip#1"、“节点1的ip#2”、“节点1的ip#3”、“节点2的ip#1”、“节点2的ip#2”、"节点2的ip#3"的哈希值,于是形成六个虚拟节点,当客户端被路由到虚拟节点的时候其实是被路由到该虚拟节点所对应的真实节点