集群 SETSLOT

CLUSTER SETSLOT slot <IMPORTING node-id | MIGRATING node-id |
  NODE node-id | STABLE>

可用版本

3.0.0

时间复杂度

O(1)

ACL 类别

@admin, @slow, @dangerous,

CLUSTER SETSLOT 负责以不同的方式更改接收节点中哈希槽的状态。它可以根据使用的子命令，

1. MIGRATING 子命令：将哈希槽设置为 *迁移* 状态。
2. IMPORTING 子命令：将哈希槽设置为 *导入* 状态。
3. STABLE 子命令：从哈希槽中清除任何导入/迁移状态。
4. NODE 子命令：将哈希槽绑定到不同的节点。

该命令及其子命令对于启动和结束集群实时分片操作非常有用，这些操作通过在源节点中将哈希槽设置为迁移状态，并在目标节点中设置为导入状态来完成。

每个子命令都在下面有文档记录。在最后，您将找到有关如何使用此命令和其他相关命令执行实时分片的描述。

CLUSTER SETSLOT <槽位> MIGRATING <目标节点 ID>

此子命令将槽位设置为 *迁移* 状态。为了将槽位设置为此状态，接收命令的节点必须是哈希槽的所有者，否则会返回错误。

当槽位设置为迁移状态时，节点会更改其行为，如下所示：

1. 如果接收到有关现有键的命令，则会像往常一样处理该命令。
2. 如果接收到有关不存在的键的命令，则节点会发出 ASK 重定向，要求客户端仅将该特定查询重试到 目标节点。在这种情况下，客户端不应更新其哈希槽到节点的映射。
3. 如果命令包含多个键，如果都不存在，则行为与第 2 点相同，如果都存在，则与第 1 点相同，但是，如果只有部分键存在，则命令会发出 TRYAGAIN 错误，以使感兴趣的键完成迁移到目标节点，以便可以执行多键命令。

CLUSTER SETSLOT <槽位> IMPORTING <源节点 ID>

此子命令是 MIGRATING 的反向操作，并准备目标节点从指定的源节点导入键。该命令仅在节点不是指定哈希槽的所有者时才有效。

当槽位设置为导入状态时，节点会更改其行为，如下所示：

1. 有关此哈希槽的命令会被拒绝，并像往常一样生成 MOVED 重定向，但在命令跟随一个 ASKING 命令的情况下，在这种情况下，命令将被执行。

这样，当处于迁移状态的节点生成 ASK 重定向时，客户端会联系目标节点，发送 ASKING，并在其后立即发送命令。这样，旧节点中不存在的键或已迁移到目标节点的键的命令将在目标节点中执行，从而

1. 新键始终在目标节点中创建。在哈希槽迁移期间，我们只需要移动旧键，而不是新键。
2. 有关已迁移键的命令将在迁移的目标节点（新的哈希槽所有者）的上下文中正确处理，以确保一致性。
3. 如果没有 ASKING，则行为与往常相同。这保证了具有错误哈希槽映射的客户端不会在目标节点中写入错误，从而创建一个尚未迁移的键的新版本。

CLUSTER SETSLOT <槽位> STABLE

此子命令只是从槽位中清除迁移/导入状态。它主要用于通过 redis-cli --cluster fix 修复处于错误状态的集群。通常，这两个状态会在使用 SETSLOT ... NODE ... 子命令（如下一节所述）完成迁移后自动清除。

CLUSTER SETSLOT <槽位> NODE <节点 ID>

NODE 子命令是语义最复杂的命令。它将哈希槽与指定节点关联，但该命令仅在特定情况下有效，并且根据槽状态具有不同的副作用。以下是命令的前置条件和副作用集。

1. 如果当前哈希槽所有者是接收命令的节点，但命令的效果是将槽分配给另一个节点，则如果接收命令的节点中仍有该哈希槽的键，该命令将返回错误。
2. 如果槽处于 *迁移中* 状态，则当槽分配给另一个节点时，该状态将被清除。
3. 如果槽在接收命令的节点中处于 *导入中* 状态，并且命令将槽分配给该节点（这发生在将哈希槽从一个节点重新分片到另一个节点的结束时，在目标节点中），则该命令具有以下副作用：A） *导入中* 状态被清除。B）如果节点配置纪元尚未是集群中的最大纪元，则它会生成一个新的配置纪元并将其分配给自己。这样，它的新哈希槽所有权将胜过之前由以前的故障转移或槽迁移创建的任何过去配置。

重要的是要注意，步骤 3 是 Redis 集群节点在没有其他节点同意的情况下创建新配置纪元的唯一时间。这仅在手动配置操作时才会发生。但是，不可能创建两种节点具有相同配置纪元的非瞬时设置，因为 Redis 集群使用配置纪元冲突解决算法。

Redis 集群实时重新分片解释

CLUSTER SETSLOT 命令是 Redis 集群用来将一个哈希槽中包含的所有键从一个节点迁移到另一个节点的重要部分。这是在其他命令的帮助下，迁移是如何协调的。我们将拥有当前哈希槽所有权的节点称为 *源* 节点，而我们将要迁移到的节点称为 *目标* 节点。

1. 使用 CLUSTER SETSLOT <槽> IMPORTING <源节点 ID> 将目标节点槽设置为 *导入中* 状态。
2. 使用 CLUSTER SETSLOT <槽> MIGRATING <目标节点 ID> 将源节点槽设置为 *迁移中* 状态。
3. 使用 CLUSTER GETKEYSINSLOT 命令从源节点获取键，并使用 MIGRATE 命令将它们移动到目标节点。
4. 向目标节点发送 CLUSTER SETSLOT <槽> NODE <目标节点 ID>。
5. 向源节点发送 CLUSTER SETSLOT <槽> NODE <目标节点 ID>。
6. 向其他主节点发送 CLUSTER SETSLOT <槽> NODE <目标节点 ID>（可选）。

说明

• 步骤 1 和 2 的顺序很重要。我们希望目标节点准备好接受 ASK 重定向，当源节点被配置为重定向时。
• 步骤 4 和 5 的顺序很重要。目标节点负责将更改传播到集群的其余部分。如果源节点在目标节点之前被告知，并且目标节点在被设置为新槽所有者之前崩溃，则即使在成功故障转移后，槽也会没有所有者。
• 步骤 6，向未参与重新分片的节点发送 SETSLOT，从技术上来说是不必要的，因为配置最终会自行传播。但是，最好这样做，以便尽快阻止节点指向错误的节点，以查找已移动的哈希槽，从而导致更少的重定向以查找正确的节点。

RESP2/RESP3 响应