前言
在阅读公司自主封装的jedis源码过程中，了解到sentinel集群连接多个master，当客户端连接sentinel获取对应key的主节点信息时，用到了一致性hash算法。
而最新版本的redis集群cluster模式下，用的hash slot模式。
所以针对这两个问题，积累一下相关知识点，便于理解。
普通hash
在正常集群分布时，需要对redis的key进行负载均衡，
简单方案，：
- 1.假设现在有4台服务器
- 2.对key进行hash并取余，得到对应的数值找到对应的服务器。
存在问题：如果线上4台服务器无法满足需求时，增加一台变成5台，这时候取余的结果跟之前的数值就存在区别，导致对应的key找不到数据，而且这个可能影响大部分的key都找不到
一致性hash
如上图，上方两个图为普通hash环，其具体的构造过程为：
- 1.先构造一个长度为 2^32 的一致性 Hash 环
- 2.计算每个缓存服务器的 Hash 值，并记录，这就是它们在 Hash 环上的位置
- 3.对于每个图片，先根据 key 的 hashcode 得到它在 Hash 环上的位置，然后在 Hash 环上顺时针查找距离这个 Key 的 Hash 值最近的缓存服务器节点，这就是该图片所要存储的缓存服务器。
但是以上的普通hash环会存在一个问题，当节点移除时，原有节点的数据会全量打到一个节点上，导致那个节点的数据倍增，同理，如果节点新增时，只会影响其中一个节点，其他节点的压力并不会移除。
这时，引入了包含虚拟节点的hash环，扩展整个环上的节点数量，可以将每台物理缓存服务器虚拟为一组虚拟缓存服务器，使得 Hash 环在空间上的分割更加均匀。
如图中下方图，node1x代表节点1，依次类推，通过寻找虚拟节点，然后找到对应的真实节点，只要虚拟节点足够多，节点会更均匀的分布在环上。
此时，新增一个节点，所影响的key会均匀的从其他节点转移到新的节点上，同理删除一个节点，节点上的缓存会均匀的转移到其他节点上。
一致性hash也有一些不足的地方：
- 1.节点过多，或者更新频繁，查询效率会比较低下。
- 2.需要一个服务进行负载均衡。
redis cluster 的 hash slot 算法
CRC16 值，然后对 16384 取模，可以获取 key 对应的 hash slot。
redis cluster 中每个 master 都会持有部分 slot，比如有 3 个 master，那么可能每个 master 持有 5000 多个 hash slot。
hash slot 让 node 的增加和移除很简单，增加一个 master，就将其他 master 的 hash slot 移动部分过去，减少一个 master，就将它的 hash slot 移动到其他 master 上去。
任何一台机器宕机，另外两个节点，不影响的。因为 key 找的是 hash slot，不是机器。
