一致性HASH算法详解以及使用场景

一致性hash算法：

先构造一个0到232的整数环，然后将服务器节点的Hash值，放在该环上（可以理解为将你的ip做hash，将ip的HashCode放在环上）。然后根据需要缓存的数据的Key，计算Key的HashCode,然后在环上，顺时针查找距离这个Key的Hash值最近的缓存服务器的节点，然后将Value，存储到该服务器节点上。

                                                  图来自网络

 

新增节点场景：

如新增节点node5,计算的hash值趋于node2,node4之间，则 node2，node4之间的数据就有一部分需要迁移到node5，一方面对其他节点影响小，但是会导致数据会分配不均，其他节点数据压力依然很大

解决方式：

引入虚拟节点，在现有节点上层在增加一层虚拟节点，

我们将每台缓存服务器，虚拟为一组虚拟缓存服务器，将虚拟服务器的Hash值，放置在Hash环上，Key在环上先找到虚拟服务器节点，再得到物理服务器的信息。

这样，一台服务器节点，被环中多个虚拟节点所代表，且多个节点均匀分配。很显然，每个物理节点对应的虚拟节点越多，各个物理节点之间的负载越均衡，新加入物理服务器对原有的物理服务器的影响越保持一致。

应用场景：

缓存集群常用该算法如memcache：

memcached在实现分布式群集部署时，memcached服务之间是不能进行通讯的，分布式也是通过客户端的算法吧数据保存在不同的memcached中，所以当我们做完群集客户端往里面写入数据时，会出现下面的情况。客户端往一个memcached节点写入数据后，另外两个节点是查询不到的，此时就需要用一致性hash算法。

首先求出memcached 服务器（节点）的哈希值，并将其配置到0～232的圆（continuum）上。然后用同样的方法求出存储数据的键的哈希值，并映射到圆上。然后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务器上。如果超过232 仍然找不到服务器，就会保存到第一台memcached 。

但是memcache还是有问题如：

memcached对容错不做处理的，也就是说当Memcached 服务端挂掉或者 Memcached 重启复活，由于Memcached重启后无数据，对高并发的大型系统中，是没办法接受的，我们在集群的情况下，要做到负载均衡和容错 ，这种情况下， 服务器端挂掉，负载就不那么均衡，缓存数据也会丢失 ，重新对数据库进行操作，加大的系统的性能， 数据丢失容错也没做得那么好。 Memcache自身并没有实现集群功能，如果想用Memcahce实现集群需要借助第三方软件或者自己设计编程实现，如repcached、memagent、 memcached-ha等。

Redis集群模式也使用了一致性hash算法：

(1)所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽.

(2)节点的fail是通过集群中超过半数的节点检测失效时才生效.

(3)客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可

(4)redis-cluster把所有的物理节点映射到[0-16383]slot（插槽）上,cluster 负责维护node<->slot<->value