redis缓存学习之一致性hash和hash槽

本篇文章给大家带来了关于redis的相关知识，其中主要介绍了一致性hash和hash槽的相关问题，如果发生扩容或者节点丢失你就会遇到大量的数据迁移问题，一致性hash和hash槽就可以避免这种问题，希望对大家有帮助。

推荐学习：Redis学习教程

假如我们现在有x台缓存设备，我们在决定把数据放到哪个缓存设备上的时候可以key%x，但是如果发生扩容或者节点丢失你就需要key%(x±y)这样就会遇到大量的数据迁移问题，一致性hash和hash槽就可以避免这种问题。

一致性hash原理

普通的hash是对服务器的数量取余，一致性hash是对特定的数字取余(2^32)不会因为服务器的数量变化，首先我们对服务器的ip或者其他唯一标识取余得到一个值这个值就是服务器在hash环上的位置，然后对要放入服务器的对象进行hash得到一个值，在hash换上找对应的服务器如果值所在的位置没有服务器就看下一个位置是否服务器知道找到可存储的服务器。

1、环形空间

按照常用的hash算法来将对应的key哈希到一个具有2的32 次方个节点的空间中，即0 ~ (2的32)-1的数字空间中。我们可以把这个东西想象成一个咬住尾巴的，形成了一个闭环。

2、服务器hash到环上

环有了我们现在需要把服务器放到环上，可以根据服务器的IP地址获取编号等唯一标识取hash后放到环上。

3、数据存储和获取

当我们需要把一个数据放到服务器上的时候我们首先需要计算数据的hash值然后取余，如果取余后的值在环上有对应的服务器那直接放进去如果没有则向后查找。

所以最后data1在redis1里面，data2在redis2里面。当我们获取数据的时候也是执行相同的过程，计算key的hash值，然后根据相同的规则获取存储的服务器。

4、服务器的删除和添加

如果现在某个redis节点挂掉了，那么其他节点里面的数据是还在的，原来节点里面的数据会被重新分配到下一个节点里面。
如果在环境中新增一台服务器RedisNeo，通过hash算法将RedisNeo映射到环中，通过按顺时针迁移的规则，那么以前hash值在Redis2和RedisNeo之间的数据迁移到RedisNeo里面(下图中RedisNeo挨着Redis2)，其它对象还保持这原有的存储位置。通过对节点的添加和删除的分析，一致性哈希算法在保持了单调性的同时，还是数据的迁移达到了最小，这样的算法对分布式集群来说是非常合适的，避免了大量数据迁移，减小了服务器的的压力。

所以redisNeo加入后data3就到redisNeo里面去了。

5、平衡性

到目前为止一致性hash也可以算做完成了，但是有一个问题还需要解决，那就是平衡性。从下图我们可以看出，当服务器节点比较少的时候，会出现一个问题，就是此时必然造成大量数据集中到一个节点上面，例如你只有两个节点一个在1另一个在10，那么很显然1节点的压力是无限大的，因为只有hash值在[2,10]之间的才会到10节点，其他的全到1节点上去了，为了解决这种数据倾斜问题，一致性哈希算法引入了虚拟节点机制，即对每一个服务节点计算多个哈希，每个计算结果位置都放置一个此服务节点，称为虚拟节点。具体做法可以先确定每个物理节点关联的虚拟节点数量，然后在ip或者主机名后面增加编号，同时数据定位算法不变，只是多了一步虚拟节点到实际节点的映射。

hash槽

哈希槽是在redis cluster集群方案中采用的，redis cluster集群没有采用一致性哈希方案，而是采用数据分片中的哈希槽来进行数据存储与读取的。redis cluster采用数据分片的哈希槽来进行数据存储和数据的读取。redis cluster一共有2^14（16384）个槽，所有的master节点都会有一个槽区比如0～1000，槽数是可以迁移的。master节点的slave节点不分配槽，只拥有读权限。但是注意在代码中redis cluster执行读写操作的都是master节点，并不是你想 的读是从节点，写是主节点。第一次新建redis cluster时，16384个槽是被master节点均匀分布的。

和一致性哈希相比在扩容和缩容的时候需要手动手动分配hash槽，并且在删除master节点的时候要把他的从节点和hash槽交给其他master节点；hash槽的是根据CRC-16(key)%16384的值来判断属于哪个槽区。

推荐学习：Redis教程