一、普通哈希算法

假设我现在有四个master节点，现在来了一个key值Hello，经过计算得出hash值为111
那么Redis就会去看我现在有多少个节点，把key值取模节点数，并打到对应的master节点

普通hash-1.png

此时看起来没有问题，但是如果我想加一台机器或者某台机器挂了，那么就出问题了。
假设加一台机器，现在我就有了5个master节点，那么就会取模5。那么就会打到master1上，这样就必然找不到对应的数据，缓存就失效了。

普通hash-2.jpg
缺点：扩容或者节点宕机会使大量的请求无法拿到有效的缓存，大量的流量就会涌进数据库。

二、一致性哈希算法

把哈希函数可映射的空间(相当于普通哈希中桶的数目是固定的)固定下来了，比如固定为: 2n-1，并组织成环的形状。
假设有一个key值过来，我还是计算它的hash值，hash值会对应到环上的某个点。然后顺时针的去寻找离自己最近的一个节点。如果说原来的那台机器挂了，那也只是影响那台机器上的数据。

一致性hash-1.png
这样其实还会存在一个问题，就是缓存热点的问题。
可能集中在某个hash区间内的值特别多，那么就会导致大量的数据都涌入到一个master内，造成master的热点问题，出现性能瓶颈。
我们可以采用虚拟节点来解决数据负载均衡的问题。

虚拟节点.png
虚拟节点相当于是实际节点的一个影子或者说分身，而且虚拟节点一般都比实际节点的数量要多（可能一下多好几百倍，这个hash的环上都是密密麻麻的虚拟节点默认的一个实际redis节点有160个虚拟节点，如果给redis实际节点配置了权重的话（默认权重是1），那虚拟节点的个数就是权重160）。引入虚拟节点后，object不再直接映射到实际的cache节点中，而是先映射到虚拟节点中。然后虚拟节点会再进行一个hash计算，最后才映射到实际的cache节点中。所以虚拟节点就是对我们的实际节点进行一个放大。
一致性哈希还存在缺点：没有考虑到每台机器的异构性质，不能实现很好的负载均衡。
举个例子：机器C的配置很高，性能很好，而机器D的配置很低。但是，可能现实中大部分数据由于某些特征都哈希到（C,D）这段环上，直接就导致了机器D的存储压力很大。

三、Redis Cluster的hash slot算法

Redis Cluster有固定的16384个hash slot，对每个key计算CRC16的值，然后对16384取模，就可以获取到对应的hash slot。每个master节点都会持有部分的slot，比如说有3个master节点，那么每个节点就都持有5000多个slot。如果我现在要加一个节点，那么只需要把其他master上的slot移前面一部分过去即可，而移动slot的代价是很低的。

Redis Cluster.png