Redis-槽道原理

Redis Cluster
Redis3.0之后,节点之间通过去中心化的方式提供了完整的sharding(分片)、replication(复制)、failover解决方案,称为 Redis Cluster。

1、所有redis节点(包括主和从)彼此互联(两两通信)。
2、集群中的高可用逻辑,通过主节点的过半选举实现主从替换。
3、客户端与redis-cluster连接,无需再关心分片的计算,客户端不在关心分片的计算逻辑,内部分发分布式数据(内部有分片计算逻辑),客户端将key交给redis节点后,集群内部判断key值的正确存储位置,转发存储;

hash slot(哈希槽)
Redis Cluster在设计中没有使用一致性哈希(Consistency Hashing),而是引入哈希槽(hash slot)来实现;一个 Redis Cluster包含16384(0~16383)个哈希槽,存储在Redis Cluster中的所有key都会被映射到这些slot中,集群中的每个key都属于这16384个哈希槽中的一个,集群使用公式slot=CRC16(key)%16384来计算key属于哪个槽。

Redis群集中的每个节点都负责哈希槽的子集,因此,例如,您可能有一个包含3个节点的群集,其中:
节点A包含从0到5500的哈希槽。
节点B包含从5501到11000的哈希槽。
节点C包含从11001到16383的哈希槽。
这样可以轻松添加和删除集群中的节点。例如,如果我想添加一个新节点D,则需要将一些哈希槽从节点A,B,C移到D。类似地,如果我想从群集中删除节点A,则只需移动A所服务的哈希槽到B和C。当节点A为空时,我可以将其从群集中完全删除。

槽道原理
当连接redis集群中任意一个已知的节点想通过set key value命令来保存数据,或get key来获取数据,首先会根据key值,通过CRC16(key)%16384,算出这个key应该落入的槽道号,接下来就只需要找到是哪个节点管理这个槽道号,就可以在这个节点操作了。
有两种可能,要么当前连接的节点就管理着这个槽道号,在当前节点直接set就可以了。要么这个节点不管理这个槽道号,需要寻找对的节点。如果想判断槽道是否归某个节点管理,就需要使用一个能标记的东西将槽道和节点联系起来,在redis集群中,有两个关键类以及里面的两个关键属性(clusterNode和clusterState的slots属性)。
(1)clusterNode类的slots属性:clusterNode类对应一个节点的信息,类似cluster nodes命令得到的单个节点的信息,包括节点id、ip、端口等信息,它有一个关键属性slots,类型是一个2048位的byte数组(二进制位序列数组),对应就是16384个bit位,通过这个数组bit是1或0,来决定节点是否拥有槽道的管理权,每个节点都有自己的这个数组。

(2)clusterState类的slots属性:clusterState类记录了集群状态的信息,类似cluster info命令得到的集群信息。它有一个关键的属性slots,类型是一个16384位长度的clusterNode数组(索引数组),它记录着整个集群的槽道信息,根据这个数组的下标,可以找到对应的节点。

当前连接的节点根据key计算出来的槽道号,在二进制位序列数组查找该槽道号的值,如果是1,表示当前节点管理了这个槽道,如果是0,则没有管理这个槽道,需要查找索引数组对应的槽道号被哪个节点管理。
————————————————
版权声明:本文为CSDN博主「suxm&」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/xianmingsu/article/details/103631376

猜你喜欢

转载自blog.csdn.net/C18298182575/article/details/120889985