REDIS数据分布的三种算法：老土的hash+一致性圆圈定理hash+redis cluster的hash slot

前言：

这个知识点其实也是了解下即可，并不需要很深的领悟，由于这几个图是现场画的，可能会有一些机制的不清晰，有兴趣的，可以一起共同讨论一下这些机制的缺点和痛点，共同进步

1.redis数据分布算法一：最老土的hash

例如：来了一个key之后，计算这个hash值，然后对节点数量进行取模，这个取模是根据节点数量来定的，例如3个master节点，那么就对3取模，这里以3个master node节点举例，这个取模的结果一定是0-2之间的，小于master节点数量的，结果就比较显然就是0，1，2三个结果之间的，根据不同的结果，写入到指定的master node上就可以了，但是这种算法实际上是存在很多问题的，第一个问题，就是要是如果hash值一直取模的算法是2或者是1，那数据全在2或者是1的master node上面了，一旦2或者是1出现宕机，所有的请求将直线打入mysql数据库中，很惨，还有一种可能就是，2宕机了，可是根据hash取模，算出来的还是2，那不是无法写入了，等等问题，所以这个叫做最老土的hash算法；

如图：【最老土的hash算法】

2.最老土的hash算法的plus版(一致性hash算法)【爱的魔力转圈圈】

一致性hash算法，也是有一个key过来，同样也是计算的hash值，然后会用hash值在圆环对应的各个点上(每个点都有一个hash值)去对比，看看hash值应该落在这里圆圈的哪个部位，保证的就是一个圆圈，只要其中一个master出现宕机的情况，只有之前在那个master node上的数据会受到影响，因为按照顺时针走，全部都在之前的master node上找不到了，master宕机了，会顺时针走到下一个master去，也找不到，也就是有【3分之一的流量也会直接涌入到MySQL数据库中重新查询一次】

如图：【一致性hash算法】

问题：一致性hash算法，可能集中在某个hash区间内的值会特别多，那么会导致大量的数据都涌入同一个master内，造成master的热问题，性能出现瓶颈

【有问题就解决下问题，或者是想想解决的思路】

这个一致性hash算法也是有解决方案的：
· 给每个master node均匀分布虚拟节点，这样的话，在每个区间内，大量的数据，都会均匀的分布到不同的节点内，而不是按照顺时针的顺序去走，全部涌入同一个master内，导致一个master node节点数据太多瓶颈；

3.redis cluster的hash slot算法

redis cluster有固定的16384个hash slot，对每个key计算16进制的值，然后对16384取模，可以获取key对应的hash slot； redis cluster中每个master都会持有部分slot【卡槽】，比如说有3个masternode，那么可能每个master持有5000多个hash slot卡槽，hash slot让node的增加和移除很简单，增加一个master，就将其他的master的hash slot移动部分过去，减少一个master，就将它的hash slot移动到其他的master上去，移动hashslot的成本是非常低的，客户端的api，可以对指定的数据，让他们走同一个hash slot，通过hash tag来实现；

上图：【hash slot算法】

要是其中一台master出现了宕机怎么办？有影响吗？

一台机器出现宕机，另外两个节点，不影响，因为key找的是hash slot，找的不是某个master node机器实例 ；

4.最后对redis cluster做个简介【和对三种算法做个简单的总结】

直接上图：【因为俺觉得看图，也是文字，但是比看一堆文字要爽的多，所以就将内容处理成为图片的格式】

最后谢谢大家！这篇文章面试的时候可以看看，就是一部分底层原理算法！如果此篇文章有不足的地方，或者是有错误的观点，欢迎大家在评论去指出！共同学习，努力进步！

声明：转发请备出处！谢谢！所有的原图可以找我申领，redis的生产环境的部署，集群的搭建，哨兵模式，主从分离，redis如何支撑海量数据，几十万的QPS，master node和slave node的主从分离痛点等等，包括小到linux上面的静态IP配置，网段，全部画图笔记，可以无条件分享！