Redis Cluster设计规范

雨点打透心脏的1/2处 2022-10-30 05:22 165阅读 0赞

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center]

### 文章目录 ###

*  一. 问题背景
 *  二. 前言
 *  三. Redis Cluster设计规范
 *   *  3.1 Redis Cluster的目标
     *  3.2 子集
     *  3.3 Redis Cluster协议中的客户端和服务器角色
     *  3.4 写安全
     *  3.5 可用性
     *  3.6 性能
     *  3.7 为什么避免合并操作
     *  3.8 Redis Cluster主要组件概述
     *   *  3.8.1 密钥分配模型
         *  3.8.2 键哈希标签
         *  3.8.3 集群节点属性
         *  3.8.4 集群总线
         *  3.8.5 集群拓扑
         *  3.8.6 节点握手
     *  3.9 重定向和重新分片
     *   *  3.9.1 移动重定向
         *  3.9.2 集群实时重新配置

# 一. 问题背景 #

> 做好了[基于Docker搭建Redis集群][Docker_Redis]后，用Redis集群做了很多实验，得到的实验结果并不符合网上的很多理论。因此深入了解Redis Cluster架构以及设计规范，解开了很多疑惑。如果对Redis架构演变不了解，阅读本文章前推荐先阅读[关于Redis的架构][Redis]。

参考自：[Redis集群规范官方文档][Redis 1]

# 二. 前言 #

*  本文章只阐述某些关键规范，详情可以阅读[Redis集群规范官方文档][Redis 1]
 *  由于官方文档是英文的，笔者能力有限，采用了谷歌浏览器的英文翻译的功能。因此会出现某些词语出现倒装或者难以理解。因此不必对某些词太纠结，了解大概意思即可。比如**密钥其实就是key，群集就是集群的意思。**

# 三. Redis Cluster设计规范 #

## 3.1 Redis Cluster的目标 ##

Redis Cluster是Redis的分布式实现，其在设计中的重要性顺序为以下目标：

*  高达1000个节点的高性能和**线性可扩展性。没有代理，使用异步复制**，并且不对值执行合并操作。
 *  可接受的写安全程度：系统尝试（以尽力而为的方式）保留源自与大多数主节点连接的客户端的所有写操作。通常，有一些小窗口，在这些小窗口中，可能会丢失已确认的写入。当客户端位于少数分区中时，丢失确认写入的Windows会更大。
 *  可用性：Redis Cluster能够**在大多数主节点可访问且每个不再可用的主节点上至少有一个可访问的从节点的分区中生存**。此外，通过使用副本迁移，不再由任何从属复制的主将从一个由多个从属覆盖的主接收一个。

本文档中描述的内容是在Redis 3.0或更高版本中实现的。

## 3.2 子集 ##

> **子集的意思，其实就是每台主节点上只存储部分数据，所有主节点上的数据合起来才是全量数据**

Redis Cluster实现了Redis的非分布式版本中所有可用的单键命令。只要所有键都散列到同一插槽，就可以执行执行复杂的多键操作（例如Set类型并集或交集）的命令。

Redis Cluster实现了一种称为**hash tags，哈希标签**的概念，可以使用该概念来**强制将某些key存储在同一哈希槽中**。但是，在手动重新分片过程中，多键操作可能会在一段时间内变得不可用，而单键操作始终可用。

**Redis Cluster不支持多个数据库，例如独立版本的Redis。只有数据库0，不允许使用SELECT命令。**

## 3.3 Redis Cluster协议中的客户端和服务器角色 ##

在Redis群集中，节点负责保存数据并获取群集状态，包括将key映射到正确的节点。群集节点还能够自动发现其他节点，检测不工作的节点，并在需要时将从节点升级为主节点，以便在发生故障时继续运行。（其实这个就是起到了**哨兵集群的作用**）

为了执行其任务，所有群集节点都使用TCP总线和称为Redis群集总线的二进制协议进行连接（因此**Redis Cluster中的每个节点都要开启2个端口，一个给TCP使用，另外一个给集群节点间的通信使用**）。使用**群集总线**，每个节点都连接到群集中的每个其他节点。节点使用gossip protocol（流行病协议，是一系列P2P的通信协议）传播有关群集的信息，以便发现新节点，发送ping数据包以确保所有其他节点都正常工作，并发送信号以指示特定情况。群集总线还用于在用户请求时跨群集传播Pub / Sub消息（发布/订阅），并在用户请求时编排手动故障转移（手动故障转移不是Redis Cluster故障检测器而是由系统管理员直接发起的故障转移）。

由于群集节点无法代理请求，通过`errors-MOVED`和`-ASK`客户端将被重定向到其他节点。从理论上讲，客户端可以自由地将请求发送到集群中的所有节点，并在需要时进行重定向，因此不需要客户端保持集群的状态。但是，能够在键和节点之间缓存映射的客户端可以以合理的方式提高性能。

## 3.4 写安全 ##

> 写安全讲述的主要是写入失败的情况、或者已确认写入的丢失等等，一般发生在分区、主机宕机这些情况中。笔者对此写安全不太了解，后面遇到困惑再回来研究

Redis Cluster在节点之间使用异步复制，最后一次故障转移将获得隐式合并功能。这意味着最后选择的主数据集最终将替换所有其他副本。在分区期间可能丢失写操作的时间总是很长。但是，对于连接到大多数主服务器的客户端和连接到少数主服务器的客户端，这些窗口有很大的不同。

与在少数主机上执行的写操作相比，Redis Cluster会更努力地保留与大多数主服务器连接的客户端执行的写操作。以下是在故障期间导致大多数分区中收到的已确认写入丢失的方案示例：

1.  写入可能到达主服务器，但是尽管主服务器可能能够答复客户端，但是写入可能不会通过在主服务器和从服务器节点之间使用的异步复制传播到从服务器。如果主机死亡，而写入没有到达从机，则如果主机无法访问足够长的时间以致提升其一个从机，则写入将永远丢失。在主节点完全突然故障的情况下，这通常很难观察到，因为主节点尝试在大约同一时间尝试答复客户端（带有写入的确认）和从节点（传播写入）。但是，这是现实世界中的失败模式。
2.  从理论上讲，丢失写操作的另一种可能的失败模式是：

*  主服务器由于分区而无法访问。
 *  它被其中一个奴隶进行了故障转移。
 *  一段时间后，它可能会再次可达。
 *  具有过期路由表的客户端可能会先写入旧的主机，再由集群将其转换为新主机的从机。

第二种故障模式不太可能发生，因为无法与足够多的其他主机通信的主节点有足够的时间来进行故障转移，并且该主节点将不再接受写操作，并且在分区固定后，仍会在少量时间内拒绝写操作允许其他节点通知配置更改。此故障模式还要求客户端的路由表尚未更新。

以分区的少数派为目标的写操作会丢失较大的窗口。例如，Redis Cluster在少数主服务器和至少一个或多个客户端的分区上丢失了大量写入，因为如果主服务器在主服务器上进行故障转移，则发送到主服务器的所有写入可能会丢失。多数党。

具体来说，NODE\_TIMEOUT要使一个主机进行故障转移，至少大多数主机必须无法访问它，因此，如果在此之前分区已固定，则不会丢失任何写操作。当分区的持续时间超过时NODE\_TIMEOUT，到该点为止在少数方执行的所有写操作都可能会丢失。但是，Redis集群的少数派一方将在NODE\_TIMEOUT不与多数派接触的情况下立即拒绝写入，因此存在一个最大窗口，在此之后，少数派将不再可用。因此，在那之后，不会再有写入被接受或丢失。

## 3.5 可用性 ##

> 同样看不太懂这个可用性。个人理解就是Redis Cluster会自动执行哨兵的作用，将slave提升为master，替代宕机的master继续提供服务

Redis群集在分区的少数部分不可用。在分区的大多数方面，假设每个不可达的主服务器至少拥有多数主服务器和一个从服务器，则集群将在NODE\_TIMEOUT一段时间后再次可用，再加上从服务器被选举并对其主服务器进行故障转移所需的几秒钟时间（故障转移）通常会在1或2秒内执行）。

这意味着Redis Cluster旨在承受群集中少数几个节点的故障，但是对于那些需要大量网络拆分而需要可用性的应用程序而言，它并不是一个合适的解决方案。

在由N个主节点组成的集群的示例中，每个节点都有一个从属节点，只要将单个节点分割开，集群的大部分将保持可用状态，并且1-(1/(N*2-1))当两个节点处于同一状态时，它将保持可用状态分割开（在第一个节点发生故障后，我们N*2-1总共剩下节点，而唯一没有副本的主节点发生故障的概率为1/(N\*2-1))。

例如，在具有5个节点且每个节点有一个从属节点的群集中，很1/(5\*2-1) = 11.11%可能在将两个节点从多数分区中分离出来之后，该群集将不再可用。

**由于Redis群集具有称为副本迁移的功能，因此在许多实际情况下，由于副本迁移到了孤立的主服务器（不再具有副本的主服务器），群集的可用性得以提高。因此，在每个成功的故障事件中，群集都可以重新配置从属布局，以便更好地抵抗下一次故障。**

## 3.6 性能 ##

**在Redis Cluster中，节点不会将命令代理到给定key的正确节点，而是将客户端重定向到服务于key空间给定部分的正确节点。**

最终，客户端获得群集的最新表示，以及哪个节点提供key的哪个子集，因此在正常操作期间，客户端直接联系正确的节点以发送给定命令。

由于使用了**异步复制**，因此节点不必等待其他节点的写入确认（如果未使用WAIT命令明确请求）。

另外，由于多键命令仅限于近键，因此除非重新分片，否则数据永远不会在节点之间移动。

正常操作的处理方式与单个Redis实例的处理方式完全相同。这意味着在具有N个主节点的Redis集群中，随着设计线性扩展，您可以期望获得与单个Redis实例乘以N相同的性能。同时，查询通常是在单次往返中执行的，因为**客户端通常会保留与节点的持久连接**，因此延迟时间也与单个独立Redis节点的情况相同。

**Redis Cluster的主要目标是在保持脆弱但合理的数据安全性和可用性形式的同时，具有很高的性能和可伸缩性。**

## 3.7 为什么避免合并操作 ##

> 同样看不懂此章节，后期遇到相关问题再回来看看

与Redis数据模型的情况一样，Redis Cluster设计避免了多个节点中相同键值对的版本冲突。Redis中的值通常很大；通常会看到具有数百万个元素的列表或排序集。数据类型在语义上也很复杂。传输和合并这些类型的值可能是一个主要瓶颈，并且/或者可能需要应用程序侧逻辑，存储元数据的额外内存等不小的参与。

这里没有严格的技术限制。CRDT或同步复制的状态机可以对类似于Redis的复杂数据类型进行建模。但是，此类系统的实际运行时行为将与Redis Cluster不同。Redis Cluster的设计旨在涵盖非集群Redis版本的确切用例。

## 3.8 Redis Cluster主要组件概述 ##

### 3.8.1 密钥分配模型 ###

密钥空间被划分为 **16384** 个插槽，有效地设置了16384个主节点的群集大小的上限（但是建议的最大节点大小约为1000个节点）。

**群集中的每个主节点都处理16384个哈希槽的子集。当没有正在进行的集群重新配置时（即，哈希槽从一个节点移动到另一个节点），该集群是稳定的。当群集稳定时，单个哈希槽将由单个节点提供服务（但是，服务节点可以具有一个或多个从属设备，在发生网络分裂或故障的情况下可以替换该从属设备，并且可以用于扩展）可接受过时数据的读取操作）。**

> 下面是用于将键映射到哈希槽的基本算法（有关此规则的哈希标签异常，请阅读下一段）：

HASH_SLOT = CRC16(key) mod 16384

### 3.8.2 键哈希标签 ###

为了实现哈希标签而使用的哈希槽的计算存在例外。哈希标记是一种确保在**同一哈希槽中分配多个密钥**的方法。这是为了在Redis Cluster中实现多键操作。

为了实现哈希标签，在某些情况下，密钥的哈希槽以略有不同的方式计算。如果密钥包含一个“\{…\}”图案仅之间子 \{和\}，以获得散列时隙被散列。但是，由于可能存在多次出现\{或\}以下规则很好地指定了算法：

*  如果键包含一个\{字符。
 *  如果有一个\}字符的右\{
 *  AND如果在的第一次出现\{和的第一次出现之间存在一个或多个字符\}。

然后，不对哈希进行哈希处理，仅对哈希的第一次出现\{和之后的第一次出现之间的\}内容进行哈希处理。

例子：

*  这两个键\{user1000\}.following和\{user1000\}.followers将哈希到相同的哈希槽，因为只有子字符串user1000将被哈希以计算哈希槽。
 *  对于密钥foo\{\}\{bar\}，整个密钥将按通常的方式进行散列处理，因为第一次出现时，\{其后\}是右侧，中间没有字符。
 *  对于键foo\{ \{bar\}\}zap，子字符串\{bar将被散列，因为它是第一次出现\{和第一次出现之间的子字符串\}。
 *  对于密钥foo\{bar\}\{zap\}的子串bar将被散列，由于算法停止在所述第一有效或无效（无字节内）匹配\{和\}。
 *  该算法得出的结论是，如果密钥以开头\{\}，则可以保证将其作为一个整体进行哈希处理。当使用二进制数据作为键名时，这很有用。

### 3.8.3 集群节点属性 ###

每个节点在集群中都有唯一的名称。节点名称是160位随机数的十六进制表示形式，是在节点首次启动时获得的（通常使用/ dev / urandom）。节点会将其ID保存在节点配置文件中，并将永久使用相同的ID，或者至少在系统管理员未删除节点配置文件或通过CLUSTER RESET命令请求硬重置的情况下使用该ID 。

**节点ID用于标识整个集群中的每个节点**。给定节点可以更改其IP地址，而无需也更改节点ID。群集还能够检测IP /端口的更改，并使用在群集总线上运行的Gossip protocols进行重新配置。

节点ID并不是与每个节点关联的唯一信息，而是唯一始终全局一致的信息。每个节点还具有以下关联的信息集。一些信息与该特定节点的集群配置详细信息有关，并且最终在整个集群中保持一致。相反，某些其他信息（例如上次对节点执行ping操作）是每个节点本地的。

每个节点都维护有关集群中其他节点的以下信息：节点ID，节点的IP和端口，一组标志，如果将节点标志为slave，则该节点的主节点是什么？对节点执行ping操作，最后一次接收到pong时，将显示该节点的当前 配置时期（在本规范的后面部分进行说明），链接状态以及最后一组哈希槽。

[CLUSTER NODES][]文档中介绍了[所有节点字段的][CLUSTER NODES]详细[说明][CLUSTER NODES]。

可以将`CLUSTER NODES`命令发送到群集中的任何节点，并根据查询的节点对群集的本地视图，提供群集的状态以及每个节点的信息。

以下是发送到三个节点的小型集群中的主节点的CLUSTER NODES命令的示例输出。

$ redis-cli cluster nodes
    d1861060fe6a534d42d8a19aeb36600e18785e04 127.0.0.1:6379 myself - 0 1318428930 1 connected 0-1364
    3886e65cc906bfd9b1f7e7bde468726a052d1dae 127.0.0.1:6380 master - 1318428930 1318428931 2 connected 1365-2729
    d289c575dcbc4bdd2931585fd4339089e461a27d 127.0.0.1:6381 master - 1318428931 1318428931 3 connected 2730-4095

在上面的列表中，不同的字段按顺序排列：节点ID，地址：端口，标志，发送的最后ping，收到的最后pong，配置时期，链接状态，插槽。一旦我们谈到Redis Cluster的特定部分，将涵盖上述字段的详细信息。

### 3.8.4 集群总线 ###

**每个Redis Cluster节点都有一个额外的TCP端口，用于接收来自其他Redis Cluster节点的传入连接**。此端口与用于从客户端接收传入连接的普通TCP端口处于固定偏移量。**要获得Redis Cluster端口，应在常规命令端口中添加10000**。例如，如果Redis节点正在端口6379上侦听客户端连接，则群集总线端口16379也将打开。

节点到节点的通信仅使用群集总线和群集总线协议进行：群集二进制协议由不同类型和大小的帧组成。未公开记录集群总线二进制协议，因为它不打算供外部软件设备使用该协议与Redis Cluster节点通信。但是，您可以通过阅读Redis Cluster源代码中的`cluster.h`和`cluster.c`文件来获取有关集群总线协议的更多详细信息 。

### 3.8.5 集群拓扑 ###

Redis Cluster是一个完整的网格，其中每个节点都使用**TCP连接**与其他每个节点连接。

在N个节点的群集中，每个节点都有N-1个传出TCP连接和N-1个传入连接。

**这些TCP连接始终保持活动状态，并且不会按需创建**。当节点希望响应集群总线中的ping操作而收到pong响应时，在等待足够长的时间以将该节点标记为不可访问之前，它将尝试通过从头重新连接来刷新与该节点的连接。

虽然Redis Cluster节点形成一个完整的网格，但节点使用Gossip protocols和配置更新机制以避免在正常情况下在节点之间交换太多消息，因此交换的消息数量不是指数级的。

### 3.8.6 节点握手 ###

节点始终接受集群总线端口上的连接，即使收到ping节点不受信任，甚至会在收到ping时回复ping。但是，如果不将发送节点视为群集的一部分，则接收节点将丢弃所有其他数据包。

一个节点仅以两种方式将另一个节点作为群集的一部分：

*  节点是否向其显示MEET消息。Meet消息与PING消息完全一样，但是会强制接收者接受该节点作为群集的一部分。只有系统管理员通过以下命令请求节点时，节点才会将MEET消息发送到其他节点：群集会议IP端口
 *  如果已经受信任的节点将闲聊该节点，则该节点还将另一个节点注册为群集的一部分。因此，如果A知道B，B知道C，则最终B会向A发送有关C的八卦消息。发生这种情况时，A会将C注册为网络的一部分，并尝试与C连接。

这意味着只要我们在任何连接图中加入节点，它们最终将自动形成完全连接图。这意味着群集能够自动发现其他节点，但前提是存在系统管理员强制建立的信任关系。

这种机制使群集更加健壮，但可以防止更改IP地址或其他与网络相关的事件后，不同的Redis群集意外混合。

## 3.9 重定向和重新分片 ##

### 3.9.1 移动重定向 ###

Redis客户端可以自由地向集群中的每个节点（包括从节点）发送查询。节点将分析查询，如果可接受（即，在查询中仅提及单个键，或提及的多个键全部位于同一哈希槽中），它将查找哪个节点负责哈希槽一个或多个键所属的位置。

如果哈希槽由节点提供服务，则查询将被简单地处理，否则节点将检查其内部哈希槽到节点的映射，并使用MOVED错误回复客户端，如以下示例所示：

GET x
    -MOVED 3999 127.0.0.1:6381

错误包括键的哈希槽（3999）和可以为查询提供服务的实例的ip：port。客户端需要将查询重新发出到指定节点的IP地址和端口。请注意，即使客户端在重新发出查询之前等待了很长时间，并且与此同时，群集配置已更改，如果哈希槽3999现在由另一个节点提供服务，则目标节点将再次发出MOVED错误答复。如果联系的节点没有更新的信息，则会发生相同的情况。

因此，虽然从ID识别群集节点的角度来看，我们还是尝试简化与客户端的接口，只是公开散列槽和IP：端口对识别的Redis节点之间的映射。

客户端不是必需的，但应尝试记住127.0.0.1:6381为哈希槽3999提供服务。这样，一旦需要发出新命令，它就可以计算目标密钥的哈希槽，并有更大的机会选择正确的节点。

一种替代方法是，当收到MOVED重定向时，仅使用[CLUSTER NODES][]或[CLUSTER SLOTS][]命令刷新整个客户端群集布局。遇到重定向时，很可能重新配置了多个插槽，而不仅仅是一个插槽，因此尽快更新客户端配置通常是最佳策略。

请注意，当群集稳定时（配置中没有正在进行的更改），最终所有客户端都将获得哈希槽映射->节点，从而使群集高效，客户端直接寻址正确的节点，而无需重定向，代理或其他单个故障点实体。

客户端还`必须能够处理`本文档后面介绍的`-ASK重定向`，否则它不是完整的Redis Cluster客户端。

### 3.9.2 集群实时重新配置 ###

Redis Cluster支持在集群运行时添加和删除节点的功能。添加或删除节点被抽象为相同的操作：将哈希槽从一个节点移动到另一个节点。这意味着可以使用相同的基本机制来重新平衡群集，添加或删除节点等等。

*  要将新节点添加到群集，请将一个空节点添加到群集，并将某些哈希槽集从现有节点移动到新节点。
 *  为了从群集中删除节点，将分配给该节点的哈希槽移至其他现有节点。
 *  为了重新平衡群集，在节点之间移动一组给定的哈希槽。  
    该实现的核心是能够移动哈希槽的能力。从实际的角度来看，哈希槽只是一组密钥，因此Redis Cluster在重新分片期间真正要做的就是将密钥从一个实例移动到另一个实例。移动哈希槽意味着将碰巧发生哈希的所有键移动到该哈希槽中。

要了解其工作原理，我们需要显示CLUSTER用于在Redis Cluster节点中操作插槽转换表的子命令。

可以使用以下子命令（在这种情况下，其他子命令无效）：

*  [集群ADDSLOTS][ADDSLOTS] slot1 \[ [slot2][ADDSLOTS] \] … \[slotN\]
 *  [集群DELSLOTS][DELSLOTS] slot1 \[ [slot2][DELSLOTS] \] … \[slotN\]
 *  [CLUSTER SETSLOT][]插槽NODE节点
 *  [CLUSTER SETSLOT][]插槽MIGRATING节点
 *  [CLUSTER SETSLOT][]插槽IMPORTING节点

前两个命令ADDSLOTS和和DELSLOTS只是用于为Redis节点分配（或删除）插槽。分配插槽意味着告诉给定的主节点它将负责为指定的哈希插槽存储和提供内容。

分配散列槽后，它们将使用八卦协议在群集中传播，这将在后面的配置传播部分中指定 。

ADDSLOTS当从头开始创建新集群时，通常使用该命令为每个主节点分配所有16384个哈希槽的子集。

将DELSLOTS主要用于群集配置的人工修改或用于调试任务：在实践中很少使用。

SETSLOT如果使用SETSLOT NODE表单，则该子命令用于将插槽分配给特定的节点ID 。否则，插槽可以在两种特殊状态进行设置MIGRATING和IMPORTING。使用这两个特殊状态是为了将哈希槽从一个节点迁移到另一个节点。

*  当将插槽设置为MIGRATING时，该节点将接受与该哈希插槽有关的所有查询，但是仅当所讨论的键存在时，否则该查询将使用-ASK重定向转发到作为迁移目标的节点。
 *  当将插槽设置为“导入”时，该节点将接受与该哈希插槽有关的所有查询，但前提是请求之前带有ASKING命令。如果ASKING客户端未给出命令，则查询会通过-MOVED重定向错误重定向到实际的哈希槽所有者，这通常会发生。

让我们通过一个哈希槽迁移示例使这一点更加清楚。假设我们有两个Redis主节点，分别称为A和B。我们想将哈希槽8从A移到B，因此我们发出如下命令：

*  我们发送B：CLUSTER SETSLOT 8 IMPORTING A
 *  我们发送A：集群SETSLOT 8迁移B

每当其他所有节点都使用属于哈希槽8的键查询客户机时，所有其他节点将继续将客户机指向节点“ A”，因此发生的情况是：

*  关于现有键的所有查询均由“ A”处理。
 *  所有关于A中不存在的键的查询都由“ B”处理，因为“ A”会将客户端重定向到“ B”。  
    这样，我们不再在“ A”中创建新键。同时，redis-trib在重新分片和Redis群集配置期间使用的一个称为的特殊程序会将哈希插槽8中的现有密钥从A迁移到B。这是使用以下命令执行的：

CLUSTER GETKEYSINSLOT slot count

上面的命令将count在指定的哈希槽中返回密钥。对于返回的每个密钥，redis-trib向节点“ A”发送一个`MIGRATE`命令，该命令将以原子方式将指定的密钥从A迁移到B（两个实例都在迁移密钥所需的时间（通常非常短的时间）内被锁定，因此存在没有比赛条件）。这是MIGRATE的工作方式：

MIGRATE target_host target_port key target_database id timeout

`MIGRATE`将连接到目标实例，发送密钥的序列化版本，并在收到OK代码后，将从其自己的数据集中删除旧密钥。从外部客户端的角度来看，密钥在任何给定时间都存在于A或B中。

在Redis Cluster中，无需指定0以外的数据库，但是 `MIGRATE`是通用命令，可用于不涉及Redis Cluster的其他任务。 即使移动诸如长列表之类的复杂键时，`MIGRATE`也已被优化为尽可能快，但是在Redis Cluster中，如果使用数据库的应用程序中存在延迟限制，则重新配置存在大键的群集不被视为明智的过程。

迁移过程最终完成后，该`SETSLOT <slot> NODE <node-id>`命令将发送到迁移中涉及的两个节点，以将插槽再次设置为正常状态。通常将同一命令发送到所有其他节点，以避免等待新配置在群集中自然传播。

> 后面内容详情可看[Redis Cluster设计规范][Redis Cluster]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwNjM0ODQ2_size_16_color_FFFFFF_t_70_pic_center]: /images/20221024/f3aa09893dd242e39f03b7e37a0ec5bb.png
[Docker_Redis]: https://zilianggan.gitee.io/docs/#/redis/%E5%9F%BA%E4%BA%8EDocker%E6%90%AD%E5%BB%BARedis%E9%9B%86%E7%BE%A4
[Redis]: https://zilianggan.gitee.io/docs/#/redis/%E5%85%B3%E4%BA%8ERedis%E7%9A%84%E6%9E%B6%E6%9E%84
[Redis 1]: https://redis.io/topics/cluster-spec
[CLUSTER NODES]: https://redis.io/commands/cluster-nodes
[CLUSTER SLOTS]: https://redis.io/commands/cluster-slots
[ADDSLOTS]: https://redis.io/commands/cluster-addslots
[DELSLOTS]: https://redis.io/commands/cluster-delslots
[CLUSTER SETSLOT]: https://redis.io/commands/cluster-setslot
[Redis Cluster]: https://redis.io/topics/cluster-spec#keys-distribution-model