Redis聚类

最新推荐文章于 2024-01-17 21:43:20 发布

dnc8371

最新推荐文章于 2024-01-17 21:43:20 发布

阅读量219

点赞数

文章标签：大数据分布式数据库 python redis

本文是我们学院课程的一部分，标题为Redis NoSQL键值存储。

这是Redis的速成班。 您将学习如何安装Redis并启动服务器。 此外，您将在Redis命令行中乱七八糟。 接下来是更高级的主题，例如复制，分片和集群，同时还介绍了Redis与Spring Data的集成。 在这里查看！

1.简介

本教程的最后部分专门介绍Redis的最新和最酷但仍处于试验阶段（尚未投入生产）的功能-群集。本部分的内容主要基于Redis文档部分http://redis.io/topics/cluster-tutorial和http://redis.io/topics/cluster-spec 。 Redis集群（或简称为Redis集群）是一种分布式Redis部署，旨在解决以下主要目标：

自动在多个节点之间分割数据集的能力
提供高性能和线性可扩展性的能力
保留来自与大多数节点连接的客户端的所有写操作的能力（ 写安全性 / 一致性 ）
能够在大多数主节点都可访问且每个不再可用的主节点上至少有一个可访问的从节点的网络分区中生存的能力（ 可用性 ）

Redis Cluster是数据分片（分区）的替代（但更高级）解决方案，我们已经在本教程的第4部分“ Redis Sharding”中看到过（但不是使用第三方工具，所有功能均由Redis本身提供）附加配置）。为了实现高可用性，Redis Cluster还高度依赖于主从复制，这在本教程的第3部分“ Redis复制”中已经看到。

2. Redis集群限制

首先，与Redis Cluster相关的所有功能都处于实验模式，尚未准备好用于生产。

构建任何高度可用的分布式系统非常困难，但是Redis试图使其成为可能。有一些局限性需要注意和权衡，我们已经提到了其中一些，但在这里也有必要重复一下。

首先，处理多个按键的命令不被Redis的集群支持（ SINTER ， SUNION ，...）。这种功能需要在Redis节点之间移动数据，这将使Redis Cluster无法在负载下提供可接受的性能和可预测的行为。通常，在Redis节点中处理命令的键不可用的所有操作都不会实现。

其次，Redis Cluster不支持像独立版本的Redis一样的多个数据库。只有一个数据库0，并且不允许SELECT 。

第三，Redis集群中的节点不将命令代理到存储给定密钥的正确节点，而是将客户端重定向到服务给定范围的密钥空间的正确节点（所谓的query routing的混合形式）。最终，客户端获得群集拓扑的最新表示，并且知道哪个节点提供密钥的哪个子集，可以直接联系正确的节点以发送给定命令（有效地回退到client side partitioning ）。

3.分片（分区）方案

正如我们从第4部分 Redis Sharding中已经知道的那样，有两种数据分片（分区）方案用于拆分数据，而一致性哈希是最先进和广泛使用的方案。 Redis Cluster不使用一致的哈希，而是使用不同形式的数据拆分，每个键都是所谓的hash slot 。

Redis群集中有16384个hash slots ，要计算给定密钥的hash slot ，将计算该密钥的CRC16函数（ http://en.wikipedia.org/wiki/Cyclic_redundancy_check ），然后将其模将16384的值应用于其结果。

Redis群集中的每个节点都负责hash slots的子集。例如，让我们考虑一个具有四个Redis节点＃ 1 ，＃ 2 ，＃ 3和＃ 4的集群。这可能会给我们以下hash slots分布：

Redis节点1包含从0到4096的 hash slots
Redis节点2包含从4097到8192的 hash slots
Redis节点3包含从8193到12288的 hash slots
Redis节点4包含从12289到16383的 hash slots

这种分片（分区）方案可以轻松更改群集的拓扑（添加和删除节点）。例如，如果需要添加新节点＃5，则应将来自节点＃ 1 ，＃ 2 ，＃ 3和＃ 4的一些hash slots移至节点＃ 5 。同样，如果需要从群集中删除节点＃ 3 ，则应将节点＃ 3服务的hash slots移至节点＃ 1和＃ 2 。当节点＃3变空时，可以将其从群集中永久删除。

现在最好的部分是：因为将hash slots从一个节点移动到另一个节点不需要停止正在进行的操作，所以添加和删除节点（或更改节点持有的hash slots的百分比）不需要停机。

在本教程的后面，我们将回到本示例，并使用三个Redis主节点（每个节点由一个从属节点支持）构建实际的集群。在Redis Cluster运行期间，我们将添加和删除一些节点，以了解如何实时hash slots 。

3.1键哈希标签

Redis分片（分区）方案支持的非常有趣的功能就是所谓的密钥hash tags 。 Hash tags是一种确保在同一hash slot分配两个（或多个）密钥的技术。

为了支持hash tags ， hash slot以不同的方式计算。如果键包含“ {…} ”模式，则仅对“ { ”和“ } ”之间的子字符串进行哈希处理，以获得hash slot （如果出现多次“ { ”或“ } ”密钥名称，会制定一些规则，并在http://redis.io/topics/cluster-spec中进行了描述。

我们在第4部分的 Redis Sharding中玩过的Twemproxy （ nutcracker ）还允许遵循相同的规则集来配置用于hash tags 。

4.简而言之，Redis聚类

在Redis群集中，所有节点都持有全局密钥集的某些部分（碎片或分区）。此外，每个节点都保持群集的状态（包括hash slots映射），以便将客户端重定向到给定密钥的正确节点。 Redis群集中的所有节点还能够自动发现其他节点，检测不可达或无法按预期工作的节点，并在需要时执行从属节点以进行主选举。

至于http://redis.io/topics/cluster-spec上描述的实现细节，则集群中的所有节点都使用带有二进制协议的TCP（ cluster bus ）进行连接，以便每个节点都连接到该节点中的每个其他节点。使用cluster bus的cluster bus （这意味着在N个节点的Redis群集中，每个节点具有N – 1个传出TCP连接和N – 1个传入TCP连接）。这些TCP连接始终保持活动状态。节点使用八卦协议（ http://en.wikipedia.org/wiki/Gossip_protocol ）分散群集状态，发现新节点，确保所有节点均正常工作以及在群集中传播发布/订阅消息。

Redis群集中的每个节点都有唯一的ID（名称）。节点ID（名称）是160位随机数的十六进制表示，是在节点第一次启动时获得的。节点会将其ID（名称）保存在节点配置文件中（默认情况下为nodes.conf ），并将永久使用相同的ID（名称）（或至少在不删除节点配置文件的情况下）。

节点ID（名称）用于标识整个Redis群集中的每个节点。给定节点可以更改其IP地址，而无需也更改其ID（名称）。群集还能够检测IP或/和端口的更改，并使用在cluster bus运行的八卦协议广播此信息。此外，每个节点还具有与之相关的其他信息，Redis群集中的所有其他节点都应知道以下信息：

节点所在的IP地址和TCP端口
一组标志（主，从，…）
节点服务的一组hash slots （请参阅分片（分区）方案）
上次使用群集总线发送ping数据包
上次收到pong数据包的答复
节点被标记为失败的时间
该节点的从站数量
主节点ID（名称）（如果此节点是从节点）（如果为主节点，则为零）

使用CLUSTER NODES命令可以使用某些信息（请参阅Redis Cluster Commands部分）。

5.一致性，可用性和可伸缩性

Redis Cluster是一个分布式系统。好的分布式系统是可扩展的，并且能够大规模提供更好的性能。但是，在任何分布式系统中，任何组件都可能随时发生故障，并且系统应该提供某些保证，以防发生此类故障（尤其是在它是数据存储的情况下）。在本节中，我们将简要介绍Redis在一致性，可用性和可伸缩性方面进行的一些高级权衡。可以在http://redis.io/topics/cluster-spec和http://redis.io/topics/cluster-tutorial中找到更深入的见解和详细信息。请注意，Redis Cluster的发展非常Swift，本节中讨论的某些保证可能不再成立。

5.1一致性

Redis Cluster无法保证强大的一致性，但是会努力保留客户端执行的所有写入操作。不幸的是，这并不总是可能的。由于Redis Cluster在主节点和从节点之间使用异步复制，因此在网络分区期间可能丢失写操作时，总是会有时间窗口。如果主节点在没有到达从节点的写入的情况下死亡，则写入将永远丢失（以防万一主节点长时间无法访问并且其从节点之一被提升为主节点）。

5.2可用性

Redis群集在网络分区的少数部分不可用。在网络分区的多数端中，假设每个不可达的主机至少有多数主机和一个从机，Redis群集仍然可用。这意味着Redis群集可以承受群集中几个节点的故障，但不能承受大型网络分区。对于示例，让我们考虑具有N个主节点（ M1 ， M2 ， M3 ）和N个从属节点（ S1 ， S2 ， S3 ，每个主节点都有一个从节点）的Redis集群。如果由于网络分区而导致任何单个主节点无法访问（假设我们为M2 ），则群集的大部分仍将保持可用状态（并且S2将被提升为主节点）。以后，如果其他任何主节点或从节点变得不可访问（ S2除外），则群集仍然可用。但是请注意，如果节点S2由于某种原因发生故障，则Redis Cluster将无法继续运行（因为主M2和从属S2都不可用）。

5.3可扩展性

从分片（分区）方案部分我们已经知道，Redis群集节点不会将命令转发给给定密钥的正确节点，而是重定向客户端。客户端最终获得完整的映射，其中哪些节点服务于哪个键子集，并且可以直接与正确的节点联系。因此，Redis Cluster能够线性扩展（添加更多节点可带来更好的性能），因为所有支持的操作的处理方式与单个Redis实例完全相同，而没有额外的开销。

6.安装具有群集支持的Redis

Redis Cluster当前仅在不稳定版本中可用。撰写本文时，最新的不稳定版本是3.0.0-beta1 ，可以从http://redis.io/download下载。请注意，仅提供Linux发行版，Windows端口尚不可用。

使用集群安装Redis发行版与本教程的第1部分“ Redis安装”中描述的常规Redis安装没有什么不同，并且遵循相同的步骤：

wget https://github.com/antirez/redis/archive/3.0.0-beta1.tar.gz
tar xf 3.0.0-beta1.tar.gz
cd redis-3.0.0-beta1/
make
make test
sudo make install

最后一步之后，通常的Redis可执行文件将安装在/usr/local/bin文件夹中。

7.配置Redis集群

无法使用常规Redis实例和常规配置创建Redis群集。相反，应该在特殊的群集模式下运行几个空的Redis实例。为此，应使用特定于群集的配置来运行实例（应在配置文件中将cluster-enabled指令设置为“ yes ”），以便启用特定于群集的功能和命令。

运行某些具有群集模式支持的Redis实例所需的最少设置包括以下设置。

cluster-enabled 是（默认：否）
为该实例启用Redis集群模式
cluster-config-file nodes.conf （默认值： nodes.conf ）
存储此实例的配置的文件的路径。该文件绝不应该被触碰，它只是由Redis Cluster实例在启动时生成，并在每次需要时进行更新（请参阅Nutshell中的Redis Clustering一节）。
cluster-node-timeout 5000
故障检测算法将超时（以毫秒为单位）之后无响应的实例视为发生故障。正如我们在分片（分区）方案部分中提到的那样，我们将配置和运行一个实时Redis集群，其中包含三个Redis主节点（ master1 ， master2 ， master3 ），每个Redis主节点由Redis从节点（ slave1 ， slave2 ， slave3 ）支持，如图所示。下面的图片。

图1. Redis集群拓扑

在此过程中，我们将探索大多数Redis集群功能，但在此之前，让我们从配置主服务器和从服务器开始。为了使配置足够简单，我们将从群集正常运行所需的最低限度的设置开始。

7.1配置Redis Cluster主节点

Redis主节点的最小配置如下所示：

Redis节点master1 （ redis-master1.conf ）

port 6379
    cluster-enabled yes
    cluster-config-file nodes.conf
    cluster-node-timeout 5000
    appendonly yes

Redis节点master2 （ redis-master2.conf ）

port 6380
    cluster-enabled yes
    cluster-config-file nodes.conf
    cluster-node-timeout 5000
    appendonly yes

Redis节点master3 （ redis-master3.conf ）

port 6381
    cluster-enabled yes
    cluster-config-file nodes.conf
    cluster-node-timeout 5000
    appendonly yes

准备好配置文件后，我们可以将配置作为命令行参数，一一启动Redis主节点。

redis服务器redis-master1.conf

图2. Redis master1节点以集群模式运行
redis服务器redis-master2.conf

图3. Redis master2节点以集群模式运行
redis服务器redis-master3.conf

图4. Redis master3节点以集群模式运行

与独立Redis实例的控制台输出相比，有两个值得注意的区别：

开始时，每个节点都会生成其unique ID （名称），如我们在《 Nutshell中的Redis群集》中所讨论的那样，请注意，此值仅在第一次运行时生成，然后再使用
每个实例都以cluster mode运行
此外，对于每个正在运行的实例，都有一个使用当前node ID （ name ）和一些其他信息创建的nodes.conf文件。

目前，我们有三个Redis主节点以集群模式运行，但实际上尚未形成集群（每个Redis主节点仅看到自身，而其他节点则看不到）。为了验证这一点，我们可以在每个实例上单独运行CLUSTER NODES命令（请参阅Redis Cluster Commands部分），并观察确实如此。

图5.每个Redis主节点仅看到自己，而看不到其他

为了形成集群，应使用CLUSTER MEET命令将Redis节点（以集群模式运行）连接在一起（请参阅Redis集群命令部分）。不幸的是，该命令仅接受IP地址，但不接受主机名。在我们的拓扑master1具有IP地址192.168.1.105， master2拥有192.168.2.105和master3具有192.168.3.105。 具有IP地址，让我们对master1节点发出命令。

图6.发出CLUSTER MEET命令形成Redis集群

现在，如果我们重新运行CLUSTER NODES命令，结果应该会完全不同。

图7a。在每个Redis主节点上重新运行CLUSTER NODES，确认每个节点都能看到所有其他节点（有效地形成了一个集群）

图7a。在每个Redis主节点上重新运行CLUSTER NODES以确认每个节点都能看到所有其他节点（有效地形成了一个集群）。

图7b。在每个Redis主节点上重新运行CLUSTER NODES，确认每个节点都能看到所有其他节点（有效地形成了一个集群）

图7b。在每个Redis主节点上重新运行CLUSTER NODES以确认每个节点都能看到所有其他节点（有效地形成了一个集群）。

图7c。在每个Redis主节点上重新运行CLUSTER NODES，确认每个节点都能看到所有其他节点（有效地形成了一个集群）

图7c。在每个Redis主节点上重新运行CLUSTER NODES以确认每个节点都能看到所有其他节点（有效地形成了一个集群）。

CLUSTER NODES命令的输出看起来有点晦涩难懂，需要一些解释，每列的含义。

第1栏	`Node ID` （名称）
第2栏	`IP:port`节点的`IP:port`
第三栏	标志：主人，奴隶，我自己，失败 …
第4栏	如果是从站，则为主站的`Node ID` （名称）
第5栏	上一个未决PING的时间仍在等待回复
第6栏	最后收到的PONG 时间
第7栏	此节点的配置时代（请参阅http://redis.io/topics/cluster-spec ）
第8栏	到该节点的链接状态
第9栏	`Hash slots`

表格1

在输出中未设置最后一列Hash Slots ，这是有原因的：我们尚未将hash slot分配给主节点，这就是我们现在要做的。可以通过在特定群集节点上使用CLUSTER ADDSLOTS 命令（请参阅Redis群集命令）将Hash slots分配给节点（分别使用CLUSTER DELSLOTS分配）。不幸的是，不可能分配hash slot范围（如0-5400），而应单独分配每个hash slot （总数16384中 ）。克服此限制的最简单方法之一是使用一些Shell脚本。由于集群中只有三个Redis主节点，因此可以这样划分16384个hash slots的范围：

Redis节点master1包含hash slots 0 – 5400

for slot in {0..5400}; do redis-cli -h master1 -p 6379 CLUSTER ADDSLOTS $slot; done;

Redis节点master2包含hash slots 5401 – 10800

for slot in {5400..10800}; do redis-cli -h master2 -p 6380 CLUSTER ADDSLOTS $slot; done;

Redis节点master3包含hash slots 10801 – 16383

for slot in {10801..16383}; do redis-cli -h master3 -p 6381 CLUSTER ADDSLOTS $slot; done;

如果再次运行CLUSTER NODES命令，则最后一列将填充每个主节点服务的适当hash slots （与我们之前分配给节点的hash slot范围完全匹配）。

图8. CLUSTER NODES显示每个主节点服务的hash slots

7.2配置Redis Cluster从节点和复制

为了使我们的Redis集群完整，我们需要向每个运行的Redis主节点中恰好添加一个从节点。尽管本教程的第3部分“ Redis复制”足够好地介绍了复制配置，但是Redis集群的做法有所不同。从一开始，运行和配置从站的过程与主站没有什么不同（唯一的区别是端口号）。

Redis节点slave1 （ redis- slave1.conf ）

port 7379
    cluster-enabled yes
    cluster-config-file nodes.conf
    cluster-node-timeout 5000
    appendonly yes

Redis节点slave2 （ redis-slave2.conf ）

port 7380
    cluster-enabled yes
    cluster-config-file nodes.conf
    cluster-node-timeout 5000
    appendonly yes

Redis节点slave3 （ redis-slave3.conf ）

port 7381
    cluster-enabled yes
    cluster-config-file nodes.conf
    cluster-node-timeout 5000
    appendonly yes

让我们先启动所有三个从属实例，然后再启动CLUSTER MEET命令，以便每个节点都将加入我们正在运行的Redis集群。

redis-server redis-slave1.conf
redis-server redis-slave2.conf
redis-server redis-slave3.conf

作为CLUSTER MEET需要IP地址，我们slave1具有IP地址192.168.4.105， slave2拥有192.168.5.105和slave3有192.168.6.105。

redis-cli -h master1 -p 6379 CLUSTER MEET 192.168.4.105 7379
redis-cli -h master1 -p 6379 CLUSTER MEET 192.168.5.105 7380
redis-cli -h master1 -p 6379 CLUSTER MEET 192.168.6.105 7381

和往常一样，使用CLUSTER NODES命令，我们可以看到Redis集群中的当前节点（共有六个）。输出显示所有节点均为主节点。

图9. CLUSTER NODES所有六个节点显示为主节点

要配置复制，应通过提供主Node ID （名称）在每个Redis从属服务器上执行新的CLUSTER REPLICATE命令。下表总结了所有一起复制所需的部分（通过查询CLUSTER NODES命令输出的结果）。

主主持人	`master1`
主节点ID	3508ffe11ba5fbfbb93db5b21a413799272f5d0f
从节点	`slave1`
redis-cli -h slave1 -p 7379集群副本3508ffe11ba5fbfbb93db5b21a413799272f5d0f

表2

主主持人	`master2`
主节点ID	610976e1ca5382b96718cd7e261d3543e6a99af4
从节点	`slave2`
redis-cli -h slave2 -p 7380集群副本610976e1ca5382b96718cd7e261d3543e6a99af4

表3

主主持人	`master3`
主节点ID	d8a2ae6221624212b76d9cf6c1483452e3c26117
从节点	`slave3`
redis-cli -h slave3 -p 7381集群复制d8a2ae6221624212b76d9cf6c1483452e3c26117

表5

至此，我们的Redis集群已正确配置，并具有我们要创建的拓扑。 CLUSTER NODES命令显示所有连接到主站的从站。

图10. CLUSTER NODES显示连接在一起的主节点和从节点

如我们所见，所有节点都处于健康状态，相互连接并且分配了正确的角色（主节点和从节点）。

7.3验证Redis集群工作正常

与Redis一样，确保Redis集群按预期工作的最佳方法是使用redis-cli发出一些命令。请注意，因为集群中的节点不代理命令，而是重定向客户端（请参阅分片（分区）方案），所以客户端必须支持这样的协议，这就是为什么redis-cli应该与-c命令行选项一起运行（有集群支持）：

redis-cli -h master1 -p 6379 -c

让我们尝试设置存储的键（使用SET命令），然后再查询它们（使用GET命令）。因为我们在三个节点之间分配了hash slots ，所以密钥也将分布在所有这些节点上。名称为some-key的第一个密钥存储在我们连接到的master1节点本身上。

图11.设置密钥some-key将存储在master1

但是，如果我们尝试存储名称为some-another-key ，那么将会发生有趣的事情： redis-cli告诉我们该值将存储在IP地址为192.168.3.105 （ master3 ）的节点上保留此键所属的hash slot 。

图12.设置一个键，另一个键将存储在master3

请注意，命令执行后， redis-cli将自动重定向到节点192.168.3.105 （ master3 ）。一旦我们在群集节点192.168.3.105 （ master3 ）上，我们可以通过发出CLUSTER GETKEYSINSLOT命令来验证hash slot确实包含密钥some-another-key。

图13.验证hash slot 15929是否包含密钥some-another-key

我们也可以验证的Redis从节点slave3已复制的关键some-another-key从主（ master3 ），并返回其值。

图14. Redis从属服务器（ slave3 ）复制了主服务器（ master3 ）的密钥

7.4在正在运行的Redis集群中添加和删除节点

我们在分片（分区）方案部分中已经提到，Redis集群可以在不停机的情况下进行重新配置，并且通常涉及hash slots迁移。让我们向集群添加另一个主节点master4 （IP地址为192.168.7.105 ）并将插槽15929从节点master3到master4 （这是包含密钥some-another-key的hash slot ）。她是Redis节点master4 （ redis- master4.conf ）配置：

port 6384
    cluster-enabled yes
    cluster-config-file nodes.conf
    cluster-node-timeout 5000
    appendonly yes

redis-server redis-master4.conf

redis-cli -h master1 -p 6379 CLUSTER MEET 192.168.7.105 6384

图15. Redis master4已加入集群

hash slots迁移过程包括以下阶段：

在拥有特定hash slot （ master3 ）的群集节点上，应执行命令CLUSTER SETSLOT slot MIGRATING ，其中是新节点master4的Node ID （即d8095be33a2b9d06affcb5583f7150b1341f4c96）。
```
redis-cli -h master3 -p 6381 CLUSTER SETSLOT 15929 MIGRATING
        d8095be33a2b9d06affcb5583f7150b1341f4c96
```
当某个插槽标记为MIGRATING ，该节点将接受所有有关此hash slot查询请求，但前提是给定键存在，否则该查询将转发到作为迁移目标的节点。
在应成为特定hash slot （ master4 ）的新所有者的群集节点上，命令CLUSTER SETSLOT slot IMPORTING ，其中是当前所有者master3的Node ID （即d8a2ae6221624212b76d9cf6c1483452e3c26117）。
```
redis-cli -h master4 -p 6384 CLUSTER SETSLOT 15929 IMPORTING
        d8a2ae6221624212b76d9cf6c1483452e3c26117
```
此时，应使用MIGRATE命令（请参阅http://redis.io/commands/migrate ）将hash slot所有密钥从当前所有者master3到新所有者master4 。因为只有一把钥匙，所以很容易。
```
redis-cli -h master3 -p 6381 MIGRATE master4 6384 some-another-key 0 0
```
最后，当hash slot变为空时（可以通过发出CLUSTER GETKEYSINSLOT命令进行验证），可以将其分配给新节点（ master4 ）。
```
redis-cli -h master3 -p 6381 CLUSTER SETSLOT 15929 NODE
    d8095be33a2b9d06affcb5583f7150b1341f4c96
```

虽然了解详细情况非常有用，但是手动执行这样的过程非常困难且容易出错。但是Redis Cluster软件包提供了一个方便的实用程序，称为redis-trib ，位于Redis发行版的src文件夹中。它是用Ruby编写的，通过简化Redis集群的管理可能会很有帮助（有关更多详细信息，请参见http://redis.io/topics/cluster-tutorial ）。

8. Redis集群命令

Redis Cluster添加了另外一组专用于集群管理，监视和配置的命令。在本教程的第2部分“ Redis命令”中没有涉及这些命令，因为它们在稳定版本中尚不可用。另外，Redis网站上没有足够的文档，但是至少我们可以简要描述每个命令（您已经在实际操作中看到了许多命令）。

命令	CLUSTER SETSLOT插槽NODE <node-id>
描述	将`hash slot`分配给节点。该命令应在拥有此`hash slot`的节点上发出，并且`hash slot`不应包含任何键（应为空）。

表6

命令	集群SETSLOT插槽IMPORTING <node-id>
描述	将`hash slot`标记为从<node-id>导入。 <node-id>应该是此`hash slot`的所有者。

表7

命令	集群SETSLOT插槽MIGRATING <node-id>
描述	将`hash slots`标记为正在迁移到<node-id>。该命令应在拥有此`hash slot`的节点上发出。

表8

命令	集群节点
描述	显示Redis集群中的当前节点集。

表9

命令	集群ADDSLOTS slot1 [slot2]…[slotN]
描述	将`hash slots`分配给Redis节点。

表10

命令	集群DELSLOTS slot1 [slot2]…[slotN]
描述	从Redis节点中删除`hash slots`分配。

表11

命令	群集会议IP端口
描述	将节点添加到Redis集群。

表12

命令	丛集<节点ID>
描述	从Redis集群中删除节点。

表13

命令	集群复制<master-node-id>
描述	使此节点成为主节点<master-node-id>的副本。

表14

命令	集群GETKEYSINSLOT插槽数
描述	从任何特定的键返回名称`hash slot`限制输出来计算密钥数量。如果执行此命令的节点不是slot的所有者，则该命令不返回任何结果。

表15