Redis Cluster在设计中没有使用一致性哈希（Consistency Hashing），而是使用数据分片引入哈希槽（hash slot）来实现；
一个 Redis Cluster包含16384（0~16383）个哈希槽（补充：为什么redis集群的最大槽数是16384个？），存储在Redis Cluster中的所有键都会被映射到这些slot中，集群中的每个键都属于这16384个哈希槽中的一个。按照槽来进行分片，通过为每个节点指派不同数量的槽，可以控制不同节点负责的数据量和请求数.
当前集群有3个节点,槽默认是平均分的:
- 节点 A （6381）包含 0 到 5499号哈希槽.
- 节点 B （6382）包含5500 到 10999 号哈希槽.
- 节点 C （6383）包含11000 到 16383号哈希槽.
二、哈希槽计算公式
集群使用公式slot=CRC16（key）/16384来计算key属于哪个槽，其中CRC16(key)语句用于计算key的CRC16 校验和。
三、哈希槽怎么工作
我们看到的是master节点在 Redis Cluster中的实现时，都存有所有的路由信息。
当客户端的key 经过hash运算，发送slot 槽位不在本节点的时候：
- （1）如果是非集群方式连接，则直接报告错误给client，告诉它应该访问集群中那个IP的master主机。
- （2）如果是集群方式连接，则将客户端重定向到正确的节点上。
注意这里并不是127.0.0.1:7001 帮client去连接127.0.0.1:7003获取数据的，而是将客户端请求重定向了。
四、哈希槽的优点
很容易添加或者删除节点：
- 比如如果我想新添加个节点D, 我需要从节点 A, B, C中转移部分槽到D上即可.
- 如果我像移除节点A,需要将A中得槽移到B和C节点上,然后将没有任何槽的A节点从集群中移除即可.
由于从一个节点将哈希槽移动到另一个节点并不会停止服务,所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态.
五、补充知识
查看哈希槽分区情况
通过cluster nodes命令，可以清晰看到Redis Cluster中的每一个master节点管理的哈希槽。比如 127.0.0.1:7001 拥有哈希槽 0-5460， 127.0.0.1:7002 拥有哈希槽 5461-10922， 127.0.0.1:7003 拥有哈希槽 10923-16383。
//查看集群中，各个master节点的哈希槽分区情况 127.0.0.1:7001> cluster nodes e51711eb03d 127.0.0.1:7002@17002 master - 0 1590126183862 2 connected 5461-10922 68c5fc14287 127.0.0.1:7003@17003 master - 0 1590126181856 3 connected 10923-16383 903322e4431 127.0.0.1:7001@17001 myself,master - 0 1590126182000 1 connected 0-5460
参考文献
版权声明：本文为CSDN博主「小小月的春天」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/tianpeng341204/article/details/78963850