redis槽道原理

redis槽道原理

1、槽道原理相关的2个问题
1.1节点如何判断槽道号管理权
1.2节点如何保存其他槽道管理者信息
2、槽道原理
在redis-cluster 存在分布式计算原则–hash 槽,引入16384个槽道 slot.
2.1槽道组成结构
16384位的二进制,以2048个元素的byte数据存储在每个节点内存里 byte[2048]—位序列
16384个元素的数组,元素值,指向的是一个内存的节点对象node—共享数组/索引数组
2.2位序列
❤每个节点在集群创建之初都会根据槽道管理权的分配创建一个二进制数据
主节点的二进制:将管理的槽道和二进制中的bit值做对应关系
16384位的二进制,定义,从左到右,位数0,1,2,…16383 对应槽道号;相当于每一个槽道号都能在这个主节点的二进制中
找到一个bit与其对应,如果对应的bit是1,表示该槽道号在本节点有管理权,如果是0没有管理权.

❤从节点的二进制:因为从节点没有槽道管理权的,二进制的值0

根据上述描述的逻辑,能从8000的二进制中判断任意一个槽道管理权是否归8000所有,他的二进制的特点 前5461位(0-5460)的bit都是1,其他剩余位都是0

❤使用位序列判断所属权
在8000中调用set name haha
计算name的槽道号 name–>5798
到位序列中找5798下标对应的bit–>0
判断5798这个槽道8000没有所属权
☆重要 通信的作用(为什么槽道号16384个?)
集群节点内部通信时,需要封装一个通信槽道状态数据,用到了这个2进制,byte[2048]大小刚好是2KB,通信头中有一个头
携带这个二进制,如果槽道16385 至少2个2KB的头才能写到当前节点想要传送出去的槽道数据。
2.3索引/共享数组
❤集群的创建阶段经过两两互联通信

经过两两互联通信,每个节点中的节点信息对象,都会通信给其他所有节点,所以登录一个创建好的集群中任何一个节点,能够
通过cluster nodes查看到所有节点信息。
集群的节点越多,每个节点保存的所有节点信息数据量越大.扩展上限1000个节点原因之一.理论上分片个数可以16384,每个
主节点管理一个槽道.不管理槽道的主节点可以有无数个。

❤分配槽道状态

经过集群的创建,经过节点信息的相互交互,可以进行槽道的分配,不进行槽道分配16384个槽道未分配状态,集群不可以使用,
一旦在某个节点指定管理的某一批槽道,随着二进制的变化作为互联的数据告知其他所有节点.

❤创建数组
每个集群节点中,只要集群创建完毕都会保存一个完全一样的数组对象.他是在一开始就创建的,但是元素的赋值是在分配
槽道时完成的
分配槽道时,二进制在变化,两两互联中携带相互传递,所有节点都能获取集群槽道的所有分配结果.所有节点将会对这个数
组进行赋值。
元素个数16384个,下标刚好对应槽道号.对应元素的值,引用变量指向该槽道的正确管理者。
❤数组创建所属权判断完毕之后寻找正确管理
8002调用set name
name–>5798–>bit 0没有管理权
到数组中拿到5798下标的元素引用变量—>8001详细信息包括ip port
让客户端重定向到8001

2.4扩展问题
❤能否使用数组直接判断所属权?
理论可以的,但是比二进制判断效率低的多的多
❤不判断所属权,直接利用数组进行重定向?
不可以,进入死循环
❤二进制进行通信的
没有通信,相互之间无法获取集群的槽道变化