这篇文章主要讲解了“redis的一致性hash和hash槽是什么”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“redis的一致性hash和hash槽是什么”吧！
假如我们现在有x台缓存设备，我们在决定把数据放到哪个缓存设备上的时候可以key%x，但是如果发生扩容或者节点丢失你就需要key%(x±y)这样就会遇到大量的数据迁移问题，一致性hash和hash槽就可以避免这种问题。
普通的hash是对服务器的数量取余，一致性hash是对特定的数字取余(2^32)不会因为服务器的数量变化，首先我们对服务器的ip或者其他唯一标识取余得到一个值这个值就是服务器在hash环上的位置，然后对要放入服务器的对象进行hash得到一个值，在hash换上找对应的服务器如果值所在的位置没有服务器就看下一个位置是否服务器知道找到可存储的服务器。
按照常用的hash算法来将对应的key哈希到一个具有2的32 次方个节点的空间中，即0 ~ (2的32)-1的数字空间中。我们可以把这个东西想象成一个咬住尾巴的，形成了一个闭环。
环有了我们现在需要把服务器放到环上，可以根据服务器的IP地址获取编号等唯一标识取hash后放到环上。
当我们需要把一个数据放到服务器上的时候我们首先需要计算数据的hash值然后取余，如果取余后的值在环上有对应的服务器那直接放进去如果没有则向后查找。
所以最后data1在redis1里面，data2在redis2里面。当我们获取数据的时候也是执行相同的过程，计算key的hash值，然后根据相同的规则获取存储的服务器。
如果现在某个redis节点挂掉了，那么其他节点里面的数据是还在的，原来节点里面的数据会被重新分配到下一个节点里面。
如果在环境中新增一台服务器RedisNeo，通过hash算法将RedisNeo映射到环中，通过按顺时针迁移的规则，那么以前hash值在Redis2和RedisNeo之间的数据迁移到RedisNeo里面(下图中RedisNeo挨着Redis2)，其它对象还保持这原有的存储位置。通过对节点的添加和删除的分析，一致性哈希算法在保持了单调性的同时，还是数据的迁移达到了最小，这样的算法对分布式集群来说是非常合适的，避免了大量数据迁移，减小了服务器的的压力。
所以redisNeo加入后data3就到redisNeo里面去了。
到目前为止一致性hash也可以算做完成了，但是有一个问题还需要解决，那就是平衡性。从下图我们可以看出，当服务器节点比较少的时候，会出现一个问题，就是此时必然造成大量数据集中到一个节点上面，例如你只有两个节点一个在1另一个在10，那么很显然1节点的压力是无限大的，因为只有hash值在[2,10]之间的才会到10节点，其他的全到1节点上去了，为了解决这种数据倾斜问题，一致性哈希算法引入了虚拟节点机制，即对每一个服务节点计算多个哈希，每个计算结果位置都放置一个此服务节点，称为虚拟节点。具体做法可以先确定每个物理节点关联的虚拟节点数量，然后在ip或者主机名后面增加编号，同时数据定位算法不变，只是多了一步虚拟节点到实际节点的映射。
哈希槽是在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的一致性hash和hash槽是什么”的内容了，经过本文的学习后，相信大家对redis的一致性hash和hash槽是什么这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
