Redis Cluster在设计中没有使用一致性哈希(Consistency Hashing),而是使用数据分片引入哈希槽(hash slot)来实现;
一个 Redis Cluster包含16384(0~16383)个哈希槽(补充:为什么redis集群的最大槽数是16384个?),存储在Redis Cluster中的所有键都会被映射到这些slot中,集群中的每个键都属于这16384个哈希槽中的一个。按照槽来进行分片,通过为每个节点指派不同数量的槽,可以控制不同节点负责的数据量和请求数.
当前集群有3个节点,槽默认是平均分的:
集群使用公式slot=CRC16(key)/16384来计算key属于哪个槽,其中CRC16(key)语句用于计算key的CRC16 校验和。
我们看到的是master节点在 Redis Cluster中的实现时,都存有所有的路由信息。
当客户端的key 经过hash运算,发送slot 槽位不在本节点的时候:
注意这里并不是127.0.0.1:7001 帮client去连接127.0.0.1:7003获取数据的,而是将客户端请求重定向了。
很容易添加或者删除节点:
由于从一个节点将哈希槽移动到另一个节点并不会停止服务,所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态.
通过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