Redis集群查找数据的过程

Posted 2023-03-30

参考技术A 在Redis集群中，每个节点都会保存槽信息，比如Redis集群默认有16384个槽，假设node0节点保存了0-4000槽数据，node1保存了4001-8000槽数据，node2 保存了80001-16383槽数据，则在每个节点中，都保存有当前节点处理哪些槽数据，哪些数据由其他节点处理，如node0保存了0-4000由node0处理，4001-8000由node1处理，80001-16383由node2处理。

当客户端请求过来。如果首先到达node0，当时这个key（假设计算出槽节点为10086）所在的槽并不在node0 节点上（假设node0通过自己保存结构查询出来处理key的节点为node1，地址为127.0.0.1:7001），node0 会返回给客户端一个MOVED错误，结果类似如下

这样客户端就知道它应该去127.0.0.1:7001再做请求

Redis集群之ASK错误ASKING命令REDIS_ASKING标识

一、ASK错误

• 在进行重新分片期间，源节点向目标节点迁移一个槽的过程中，可能会出现这样一种情况：属于被迁移槽的一部分键值对保存在源节点里面，而另一部分键值对则保存在目标节点 里面
• 当客户端向源节点发送一个与数据库键有关的命令，并且命令要处理的数据库键恰好就属于正在被迁移的槽时：
  • 源节点会先在自己的数据库里面查找指定的键，如果找到的话，就直接执行客户端发送的命令（底层实现：如果节点收到一个关于键key的命令请求，并且键key所属的槽i正好就指派给了这个节 点，那么节点会尝试在自己的数据库里查找键key，如果找到了的话，节点就直接执行客户 端发送的命令）
  • 相反地，如果源节点没能在自己的数据库里面找到指定的键，那么这个键有可能已经被迁移到了目标节点，源节点将向客户端返回一个ASK错误，指引客户端转向正在导入槽的目标节点，并再次发送之前想要执行的命令（底层实现：如果节点没有在自己的数据库里找到键key，那么节点会检查自己的 clusterState.migrating_slots_to[i]，看键key所属的槽i是否正在进行迁移，如果槽i的确在进行 迁移的话，那么节点会向客户端发送一个ASK错误，引导客户端到正在导入槽i的节点去查找 键key）
• 下图展示了源节点判断是否需要向客户端发送ASK错误的整个过程

单机模式/集群模式下ASK错误的显示

• 与前面介绍的MOVED错误情况类似：
  • 集群模式的redis-cli在接到ASK错误时也不会打印错误，而是自动根据错误提供的IP地址和端口进行转向动作
  • 而单机模式的redis-cli客户端会打印ASK错误

• 备注：集群模式的redis-cli并未支持ASK自动转向，上面展示的ASK自动转向行为实际上是根据MOVED自动转向行为虚构出来的。因此，当集群模式的redis-cli真正支持ASK自动转向时，它的行为和上面展示的行为可能会有所不同

演示案例

• 举个例子，假设节点7002正在向节点7003迁移槽16198，这个槽包含"is"和"love"两个键， 其中键"is"还留在节点7002，而键"love"已经被迁移到了节点7003
• 如果我们向节点7002发送关于键"is"的命令，那么这个命令会直接被节点7002执行：

• 而如果我们向节点7002发送关于键"love"的命令，那么客户端会先被转向至节点7003， 然后再次执行命令：

演示案例

• 假设在节点7002向节点7003迁移槽16198期间，有一个客户端向节点7002发送命令：

GET "love"

• 因为键"love"正好属于槽16198，所以节点7002会首先在自己的数据库中查找键"love"， 但并没有找到，通过检查自己的clusterState.migrating_slots_to[16198]，节点7002发现自己正 在将槽16198迁移至节点7003，于是它向客户端返回错误：

ASK 16198 127.0.0.1:7003

• 这个错误表示客户端可以尝试到IP为127.0.0.1，端口号为7003的节点去执行和槽16198有关的操作，如下图所示：

• 接到ASK错误的客户端会根据错误提供的IP地址和端口号，转向至正在导入槽的目标节 点，然后首先向目标节点发送一个ASKING命令，之后再重新发送原本想要执行的命令

• 以前面的例子来说，当客户端接收到节点7002返回的以下错误时：

ASK 16198 127.0.0.1:7003

• 客户端会转向至节点7003，首先发送命令：

ASKING

• 然后再次发送命令：

GET "love"

• 并获得回复：

"you get the key 'love'"

• 整个过程如下图所示：

二、ASKING命令（REDIS_ASKING标识）

• ASKING命令功能：唯一要做的就是打开发送该命令的客户端的REDIS_ASKING标识
• 以下是ASKING命令的伪代码实现：

1. def ASKING():

2. # 打开标识

3. client.flags |= REDIS_ASKING

4. # 向客户端返回OK 回复

5. reply("OK")

• REDIS_ASKING标识：在一般情况下，如果客户端向节点发送一个关于槽i的命令，而槽i又没有指派给这个节点的话，那么节点将向客户端返回一个MOVED错误；但是，如果节点的 clusterState.importing_slots_from[i]显示节点正在导入槽i，并且发送命令的客户端带有REDIS_ASKING标识，那么节点将破例执行这个关于槽i的命令一次，下图展示了这个判 断过程

• 当客户端接收到ASK错误并转向至正在导入槽的节点时，客户端会先向节点发送一个 ASKING命令，然后才重新发送想要执行的命令，这是因为如果客户端不发送ASKING命令，而直接发送想要执行的命令的话，那么客户端发送的命令将被节点拒绝执行，并返回 MOVED错误
• 另外要注意的是，客户端的REDIS_ASKING标识是一个一次性标识，当节点执行了一个带有REDIS_ASKING标识的客户端发送的命令之后，客户端的REDIS_ASKING标识就会被移除。举个例子，如果我们在成功执行GET命令之后，再次向节点7003发送GET命令，那么第 二次发送的GET命令将执行失败，因为这时客户端的REDIS_ASKING标识已经被移除：

演示案例

• 举个例子，我们可以使用普通模式的redis-cli客户端，向正在导入槽16198的节点7003发送以下命令：

• 虽然节点7003正在导入槽16198，但槽16198目前仍然是指派给了节点7002，所以节点7003会向客户端返回MOVED错误，指引客户端转向至节点7002
• 但是，如果我们在发送GET命令之前，先向节点发送一个ASKING命令，那么这个GET命令就会被节点7003执行：

• 另外要注意的是，客户端的REDIS_ASKING标识是一个一次性标识，当节点执行了一个带有REDIS_ASKING标识的客户端发送的命令之后，客户端的REDIS_ASKING标识就会被移除

三、ASK错误和MOVED错误的区别

• ASK错误和MOVED错误都会导致客户端转向，它们的区别在于：
  • MOVED错误代表槽的负责权已经从一个节点转移到了另一个节点：在客户端收到关于槽i的MOVED错误之后，客户端每次遇到关于槽i的命令请求时，都可以直接将命令请求发送 至MOVED错误所指向的节点，因为该节点就是目前负责槽i的节点
  • 与此相反，ASK错误只是两个节点在迁移槽的过程中使用的一种临时措施：在客户端收 到关于槽i的ASK错误之后，客户端只会在接下来的一次命令请求中将关于槽i的命令请求发 送至ASK错误所指示的节点，但这种转向不会对客户端今后发送关于槽i的命令请求产生任何 影响，客户端仍然会将关于槽i的命令请求发送至目前负责处理槽i的节点，除非ASK错误再 次出现