槽是什么

redis集群的整个数据库被分为16384（2的14次方）个槽（slot），数据库中的每个key都属于这16384个槽的其中一个，一个槽可以管理多个key，一个key值属于一个槽。

集群中每个节点都可以处理0-16384个槽，如果集群中只有一个节点，那么这个节点就是自己处理所有的槽。

当16384个槽都有节点在处理时，集群处于上线状态（ok），相反，有任意一个槽没有得到处理，就处于下线状态（fail）。

在7000节点上执行:

cluster addslots <slot> [slot ...]
cluster addslots 0 1 2 3 4 ... 5000

那么槽0-槽5000指派给节点7000负责。

再手动把5001-10000指派给7001，10001-16383指派给7002。现在槽都指派了，集群处于上线状态。

记录槽信息

很显然，记录一个节点负责哪些槽，肯定是节点自己维护的。那肯定就在clusterNode
里了。

struct clusterNode {
    
    // ... 上一章节记录的属性
    
    // 二进制位数组，数组长度为16384/8=2048字节，刚好包括16384个二进制位。
    unsigned char slots[16384/8];
    
    // 记录该节点处理槽的数量，也就是slots数组中值为1的二进制位的数量
    int numslots;
    
    // ...
}

redis以0为起始索引，16383为终止索引，对slots数组中的16384个二进制位进行编号，根据索引i上的二进制位，判断节点是否负责处理槽i。

在索引i上的值为1 --> 表示节点负责处理槽i
在索引i上的值为0 --> 表示节点不负责处理槽i

槽数据结构.png

只有在slots[0]中的0-7位是1，表示这个节点值负责槽0槽7。

看一下时间复杂度。
取出和设置slots数组中的任意一个二进制位的复杂度都是O(1)，所以

检查该节点是否负责处理某个槽
将某个槽支配给该节点

这两个操作的时间复杂度都是O(1)

那，查询某一个槽是哪个节点负责的呢。以当前的结构需要遍历一遍集群中的redis，复杂度为O(n)，所以还会有一个数据结构。

很显然，记录槽在哪个节点上，肯定是集群维护的，那肯定就在clusterState里了

typedef struct clusterState {
    
    // ... 上一章节记录的属性
    
    // key 为槽索引，槽1就是slots[1]
    // value 为负责该槽的节点 clusterNode
    // 如果没有节点负责，那么指向 null
    clusterNode *slots[16384];
    
    // ...
}

有这个属性了，查询某一个槽是哪个节点负责的，时间复杂度也就O(1)了

现在合起来就有一张集群的大图了

槽完整大图.png

计算key属于哪个槽

def slot_number(key):
    return CRC16(key) % 16383

先计算key的CRC-16校验和， % 16383位运算计算出16383之间的整数，以这个数作为key的槽号。

使用

cluster keyslot <key> 命令可以查看一个给定键属于哪个槽

当计算出key所在的槽号后，节点就会检查这个槽号归不归自己管，在clusterState.slots中O(1)判断。

clusterState.slots[i] 等于 clusterState.shelf，那么归自己管，直接执行客户端发送的命令
如果不等于。该节点会返回clusterState.slots[i]指向的节点信息，向客户端返回MOVED错误，指引客户端转向至正确的节点。

举个例子：当在7000这台机器执行命令的时候，7000发现这个key在7001上。那么会发生如下动作。

在7000服务器上，客服端用户执行：

set phone 123123123

7000计算phone的槽为10086，并判断归7001负责，返回给客户端：

MOVED 10086 127.0.0.1：7001

客户端收到后，会自动把服务区转换到7001上，客户端自动继续执行，2-3步对用户无感知：

set phone 123123123

成功。

为什么不用一致性哈希呢

原理不太解释了，就一句话吧，一致性哈希对于数据分布、节点位置的控制不是很友好，这种轻便的哈希槽更符合redis这种场景。

重新分片

redis集群的重新分片操作是由redis的集群管理软件redis-trib执行负责的。步骤如下：

redis-trib对目标节点发送cluster setslot <slot> migrating <target_id> 命令。让目标节点准备好从源节点导入(import)属于槽slot的键值对
redis-trib对源节点发送 cluster setslot <slot> migrating <target_id> 命令，让源节点准备好将属于槽slot的键值对迁移（migrate）至目标节点
redis-trib向源节点发送cluster getkeysinslot <slot> <count>命令，获取最多count个属于槽slot的键值对的键名(key name)
对步骤3获得的每个键名，redis-trib都向源节点发送一个migrate <target_ip> <target_port> <key_name> 0 <timeout>命令，将被选中的键原子地从源节点迁移至目标节点
重复执行3-4，直到源节点保存的所有属于槽slot的键值对都被迁移到目标节点为止。
redis-trib向集群中的任意一个节点发送 cluster setslot <slot> node <target_id>命令，将槽slot指派给目标节点，这一消息会发送至整个集群，让集群所有节点都直到该slot被迁移到目标节点了。

迁移期间访问问题

当在迁移过程中，如果被访问的slot，可能会有部分key存在在源节点，有部分在目标节点中。

当客户端发送请求到源节点的时候，源节点会查看对应的key是否还在本节点，如果存在，则直接执行命令返回给客户。如果不存在，则会给客户端返回一个ASK错误，指引客户端往正在导入的目标slot去请求对应的key。客户端可以通过返回的ASK错误中的目标节点进行对应KEY的请求。
2）当客户端发送请求到目标节点时。

如果客户端请求时，带上ASKING标识，由目标节点会执行对应KEY的查询。正常情况下，如果是通过查询源slot，获取ASK错误之后，再到目标节点进行查询的时候，需要带上ASKING标识。
如果客户端请求时，未带上ASKING标识，原由上，对应的slot还属于源节点，则目标节点会拒绝执行KEY查询，会返回一个MOVED错误给客户端，告诉客户端对应的KEY的slot属于源节点。正常情况下，如果第一次请求KEY到了正在迁移的目标节点，则会收到MOVED错误。

这里有个小知识点，ASK错误，和MOVED错误相似，是在重新分片的过程中发生key的转移导致的未命中重定向。ASK只是两个节点在槽迁移过程中的临时措施。

知识点：每个redis节点，存多少槽，存那些槽。是手动设置的。