深入理解Redis Cluster

Redis Cluster采用虚拟槽分区，所有的key根据哈希函数映射到0~16383槽内，计算公式：

slot = CRC16(key) & 16383

每个节点负责维护一部分槽以及槽所映射的键值对。

Redis虚拟槽分区的特点，解耦数据与节点之间的关系，简化了节点扩容和收缩难度。但其存在如下限制：

1. key批量操作支持有限。只支持具有相同slot值的key执行批量操作。

2. 事务操作支持有限。只支持同一个节点上的多个key的事务操作。

3. key是数据分区的最小粒度，因为不能讲一个大的键值对象，如hash，list等映射到不同的节点上。

4. 不支持多数据库，单机下的Redis可以支持16个数据库，但集群之只能使用一个数据库空间，即db 0。

5. 复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构。

如何手动创建一个Redis Cluster

创建三个目录，分别用于存放数据，配置文件和日志。

mkdir -p /opt/redis/data/
mkdir -p /opt/redis/conf/
mkdir -p /opt/redis/log

编辑配置文件

vim redis_6379.conf

port
daemonize yes
pidfile "/opt/redis/data/redis_6379.pid"
loglevel notice
logfile "/opt/redis/log/redis_6379.log"
dbfilename "dump_6379.rdb"
dir "/opt/redis/data"
appendonly yes
appendfilename "appendonly_6379.aof"
cluster-enabled yes
cluster-config-file /opt/redis/conf/nodes-.conf
cluster-node-timeout 

为简化起见，这里只贴出了redis的几个关键参数，其中，后面三个参数与Cluster有关。

cp redis_6379.conf redis_6380.conf
cp redis_6379.conf redis_6381.conf
cp redis_6379.conf redis_6382.conf
cp redis_6379.conf redis_6383.conf
cp redis_6379.conf redis_6384.conf

sed -i 's/6379/6380/g' redis_6380.conf
sed -i 's/6379/6381/g' redis_6381.conf
sed -i 's/6379/6382/g' redis_6382.conf
sed -i 's/6379/6383/g' redis_6383.conf
sed -i 's/6379/6384/g' redis_6384.conf 

启动所有节点

cd /opt/redis/conf
redis-server redis_6379.conf
redis-server redis_6380.conf
redis-server redis_6381.conf
redis-server redis_6382.conf
redis-server redis_6383.conf
redis-server redis_6384.conf

节点启动后，会在conf目录下创建nodes-xxxx.conf文件，文件中记录了节点ID。

[root@slowtech conf]# ls
nodes-.conf  nodes-.conf  nodes-.conf  redis_6379.conf  redis_6381.conf  redis_6383.conf
nodes-.conf  nodes-.conf  nodes-.conf  redis_6380.conf  redis_6382.conf  redis_6384.conf
 
[root@slowtech conf]# cat  nodes-.conf
260a27a4afd7be954f7cb4fe12be10641f379746 :@ myself,master -    connected
vars currentEpoch  lastVoteEpoch 

将节点加入到集群中

redis-cli -p  cluster meet 127.0.0.1
redis-cli -p  cluster meet 127.0.0.1
redis-cli -p  cluster meet 127.0.0.1
redis-cli -p  cluster meet 127.0.0.1
redis-cli -p  cluster meet 127.0.0.1 

cluster meet命令的流程，以第一条命令为例。

1.  6379节点在收到命令后，会为6380节点创建一个clusterNode结构，并将其添加到自己的clusterState.nodes字典里。接着，6379节点向6380节点发送一条MEET消息。

2.  6380节点在收到6379节点的meet消息后，也会为6379节点创建一个clusterNode结构，并将其添加到自己的clusterSta.nodes字典里。并向6379节点返回一条PONG消息。

3.  6379节点在收到这条PONG消息后，会向6380节点返回一个PING消息。

4 . 6380节点收到6379节点返回的PING消息，知道6379节点已经收到自己返回的PONG消息，握手完成。

之后，6379会将6380的消息通过Gossip协议传播给集群中的其它节点，让其它节点也同6380节点握手，最终，6380节点会被集群中的所有节点认识。

查看当前集群的节点信息

127.0.0.1:> cluster nodes
260a27a4afd7be954f7cb4fe12be10641f379746 127.0.0.1:@ myself,master -    connected
645438fcdb241603fbc92770ef08fa6d2d4c7ffc 127.0.0.1:@ master -    connected
bf1aa1e626988a5a35bc2a837c3923d472e49a4c 127.0.0.1:@ master -    connected
5350673149500f4c2fd8b87a8ec1b01651572fae 127.0.0.1:@ master -    connected
7dd5f5cc8d96d08f35ff395d05eb30ac199f7568 127.0.0.1:@ master -    connected
8679f302610e9ea9a464c247f70924e34cd20512 127.0.0.1:@ master -    connected

虽然六个节点已经加入到集群中了，但此时集群仍处于下线状态。

127.0.0.1:> cluster info
cluster_state:fail
cluster_slots_assigned:
cluster_slots_ok:
cluster_slots_pfail:
cluster_slots_fail:
cluster_known_nodes:
cluster_size:
cluster_current_epoch:
cluster_my_epoch:
cluster_stats_messages_ping_sent:
cluster_stats_messages_pong_sent:
cluster_stats_messages_meet_sent:
cluster_stats_messages_sent:
cluster_stats_messages_ping_received:
cluster_stats_messages_pong_received:
cluster_stats_messages_received:

分配槽

将16384个slot平均分配给6379,6380,6381三个节点。

redis-cli -p 6379 cluster addslots {0..5461}

redis-cli -p 6380 cluster addslots {5462..10922}

redis-cli -p 6381 cluster addslots {10923..16383}

集群的整个数据库被分为16384个槽，集群中的每个节点可以处理0个或最多16384个槽。当数据库中的16384个槽都有节点在处理时，集群处于上线状态（ok），反之，如果数据库中有任何一个槽没有得到处理，则集群处理下线状态（fail）。

查看集群状态

# redis-cli -p
127.0.0.1:> cluster info
cluster_state:ok
cluster_slots_assigned:
cluster_slots_ok:
cluster_slots_pfail:
cluster_slots_fail:
cluster_known_nodes:
cluster_size:
cluster_current_epoch:
cluster_my_epoch:
cluster_stats_messages_ping_sent:
cluster_stats_messages_pong_sent:
cluster_stats_messages_meet_sent:
cluster_stats_messages_sent:
cluster_stats_messages_ping_received:
cluster_stats_messages_pong_received:
cluster_stats_messages_received:

查看节点和槽的分配关系

127.0.0.1:> cluster nodes
260a27a4afd7be954f7cb4fe12be10641f379746 127.0.0.1:@ myself,master -    connected -
645438fcdb241603fbc92770ef08fa6d2d4c7ffc 127.0.0.1:@ master -    connected -
bf1aa1e626988a5a35bc2a837c3923d472e49a4c 127.0.0.1:@ master -    connected -
5350673149500f4c2fd8b87a8ec1b01651572fae 127.0.0.1:@ master -    connected
7dd5f5cc8d96d08f35ff395d05eb30ac199f7568 127.0.0.1:@ master -    connected
8679f302610e9ea9a464c247f70924e34cd20512 127.0.0.1:@ master -    connected

使用cluster replicate添加从节点

cluster replicate命令必须在对应的从节点上执行，后面接的是主节点的节点ID。

[root@slowtech conf]# redis-cli -p
127.0.0.1:> cluster replicate 260a27a4afd7be954f7cb4fe12be10641f379746
OK
127.0.0.1:> quit
[root@slowtech conf]# redis-cli -p
127.0.0.1:> cluster replicate 645438fcdb241603fbc92770ef08fa6d2d4c7ffc
OK
127.0.0.1:> quit
[root@slowtech conf]# redis-cli -p
127.0.0.1:> cluster replicate bf1aa1e626988a5a35bc2a837c3923d472e49a4c
OK

快捷命令

echo "cluster replicate `redis-cli -p 6379 cluster nodes | grep 6379 | awk '{print $1}'`" | redis-cli -p  -x
echo "cluster replicate `redis-cli -p 6379 cluster nodes | grep 6380 | awk '{print $1}'`" | redis-cli -p  -x
echo "cluster replicate `redis-cli -p 6379 cluster nodes | grep 6381 | awk '{print $1}'`" | redis-cli -p  -x

查看节点和槽的分配关系

127.0.0.1:> cluster nodes
8679f302610e9ea9a464c247f70924e34cd20512 127.0.0.1:@ myself,slave bf1aa1e626988a5a35bc2a837c3923d472e49a4c    connected
7dd5f5cc8d96d08f35ff395d05eb30ac199f7568 127.0.0.1:@ slave 260a27a4afd7be954f7cb4fe12be10641f379746    connected
5350673149500f4c2fd8b87a8ec1b01651572fae 127.0.0.1:@ slave 645438fcdb241603fbc92770ef08fa6d2d4c7ffc    connected
bf1aa1e626988a5a35bc2a837c3923d472e49a4c 127.0.0.1:@ master -    connected -
645438fcdb241603fbc92770ef08fa6d2d4c7ffc 127.0.0.1:@ master -    connected -
260a27a4afd7be954f7cb4fe12be10641f379746 127.0.0.1:@ master -    connected -

至此，我们基于Redis协议手动创建了一个Cluster，其由6个节点组成，3个主节点负责处理数据，3个从节点负责故障切换。

键到slot的映射算法

HASH_SLOT=CRC16(key)mod16384

重新分片的流程

1. 对目标节点发送cluster setslot <slot> importing <source-node-id>命令，让目标节点准备导入槽的数据。

2. 对源节点发送cluster setslot <slot> migrating <destination-node-id>命令，让源节点准备迁出槽的数据。

3.  源节点循环执行cluster getkeysinslot {slot} {count}命令，获取count个属于槽{slot}的键。

4. 在源节点执行

4. 对于步骤3中获取的每个key，redis-trib.rb都向源节点发送一个MIGRATE <target_ip> <target_port> <key_name> 0 <timeout> 命令，将被选中的键原子性地从源节点迁移至目标节点。

5. 重复执行步骤3和4，直到源节点保存的所有属于槽slot的键值对都被迁移到目标节点为止。

6. redis-trib.rb向集群中的任意一个节点发送CLUSTER SETSLOT <slot> NODE <node-id>命令，将槽slot指派给目标节点。这一消息会发送给整个集群。

客户端ASK重定向流程

Redis集群支持在线迁移slot和数据来完成水平伸缩，当slot对应的数据从源节点到目标节点迁移过程中，客户端需要做到智能识别，保证键命令可正常执行。例如，当一个slot数据从源节点迁移到目标节点时，可能会出现一部分数据在源节点，另一部分在目标节点。

如果出现这种情况，客户端键执行流程将发生变化，如下所示，

1. 客户端根据slot缓存发送命令到源节点，如果存在key则直接执行并返回结果。

2. 如果key不存在，则可能存在于目标节点，这时会回复ASK重定向异常，格式如下：(error) ASK {slot} {targetIP}:{targetPort}。

3. 客户单从ASK重定向异常提出目标节点信息，发送asking命令到目标节点打开客户端连接标识，再执行键命令。如果存在则执行，不存在则返回不存在信息。

ASK与MOVED虽然都是对客户端进的重定向，但是有着本质区别，前者说明集群正在进行slot数据迁移，所以只是临时性的重定向，不会更新slot缓存，但是MOVED重定向说明键对应的槽已经明确指定到新的节点，会更新slot缓存。

模拟Redis Cluster FAILOVER的过程

模拟主节点故障，手动kill 6379节点。

1. 首先，该节点对应的从节点会有日志输出。

:S  Oct ::30.149 # Connection with master lost.
:S  Oct ::30.149 * Caching the disconnected master state.
:S  Oct ::30.845 * Connecting to MASTER 127.0.0.1:
:S  Oct ::30.845 * MASTER <-> SLAVE sync started
:S  Oct ::30.845 # Error condition on socket for SYNC: Connection refused
...
:S  Oct ::49.994 * MASTER <-> SLAVE sync started
:S  Oct ::49.994 # Error condition on socket for SYNC: Connection refused
:S  Oct ::50.898 * FAIL message received from bd341bb4c10e0dbff593bf7bafb1309842fba155 about 72af03587f5e9f064721d3b3a92b1439b3785623
:S  Oct ::50.898 # Cluster state changed: fail

发现连接断开的时间点是10:34:30.149，判断其主观下线的时间为10:34:50，相差20s，这也是cluster-node-timeout的设置。

2. 再来看看6380节点的日志。

:M  Oct ::50.897 * Marking node 72af03587f5e9f064721d3b3a92b1439b3785623 as failing (quorum reached).
:M  Oct ::50.897 # Cluster state changed: fail

6381节点的日志同样如此，超过半数，因此标记6379节点为客观下线。

3. 再来看看从节点的日志

:S  Oct ::51.003 * Connecting to MASTER 127.0.0.1:
:S  Oct ::51.003 * MASTER <-> SLAVE sync started
:S  Oct ::51.003 # Start of election delayed for  milliseconds (rank #, offset ).
:S  Oct ::51.003 # Error condition on socket for SYNC: Connection refused

从节点识别正在复制的主节点进入客观下线后准备选举时间，日志打印了选举延迟566毫秒之后执行。

延迟选举时间到达后，从节点更新配置纪元并发起故障选举。

:S  Oct ::51.605 # Starting a failover election for epoch .

4. 6380和6381主节点为从节点投票

:M  Oct ::51.618 # Failover auth granted to 886c1f990191854df1972c4bc4d928e44bd36937 for epoch 

5. 从节点获取2个主节点投票之后，超过半数执行替换主节点操作，完成故障切换。

:S  Oct ::51.622 # Failover election won: I'm the new master.
:S  Oct ::51.622 # configEpoch set to  after successful failover
:M  Oct ::51.622 # Setting secondary replication ID to 207c65316707a8ec2ca83725ae53ab49fa25dbfb, valid up to offset: . New replication ID is 0ec4aac9562b3f4165244153646d9c9006953736
16387:M  Oct ::51.622 * Discarding previously cached master state.
:M  Oct ::51.622 # Cluster state changed: ok

Failover的流程

一、主观下线

集群中每个节点都会定期向其他节点发送ping消息，接收节点回复pong消息作为响应。如果在cluster-node-timeout时间内通信一直失败，则发送节点会认为接收节点存在故障，把接收节点标记为主观下线（pfail）状态。

二、客观下线

当某个节点判断另一个节点主观下线后，相应的节点状态会跟随消息在集群内传播。通过Gossip消息传播，集群内节点不断收集到故障节点的下线报告。当半数以上持有槽的主节点都标记某个节点是主观下线时，触发客观下线流程。

集群中的节点每次接收到其他节点的pfail状态，都会尝试触发客观下线，流程说明：

1. 首先统计有效的下线报告数量，如果小于集群内持有槽的主节点总数的一半则退出。

2. 当下线报告大于槽主节点数量一半时，标记对应故障节点为客观下线状态。

3. 向集群广播一条fail消息，通知所有的节点将故障节点标记为客观下线，fail消息的消息体只包含故障节点的ID。

广播fail消息是客观下线的最后一步，它承担着非常重要的职责：

1. 通知集群内所有的节点标记故障节点为客观下线状态并立刻生效。

2. 通知故障节点的从节点触发故障转移流程。

三、故障切换

故障节点变为客观下线后，如果下线节点是持有槽的主节点则需要在它的从节点中选出一个替换它，从而保证集群的高可用。下线主节点的所有从节点承担故障恢复的义务，当从节点通过内部定时任务发现自身复制的主节点进入客观下线时，将会触发故障切换流程。

1.资格检查

每个从节点都要检查最后与主节点断线时间，判断是否有资格替换故障的主节点。如果从节点与主节点断线时间超过cluster-node-time*cluster-slave-validity-factor，则当前从节点不具备故障转移资格。参数cluster-slavevalidity-factor用于从节点的有效因子，默认为10。

2.准备选举时间

当从节点符合故障切换资格后，更新触发切换选举的时间，只有到达该时间后才能执行后续流程。

这里之所以采用延迟触发机制，主要是通过对多个从节点使用不同的延迟选举时间来支持优先级问题。复制偏移量越大说明从节点延迟越低，那么它应该具有更高的优先级来替换故障主节点。

3.发起选举

当从节点定时任务检测到达故障选举时间（failover_auth_time）到达后，发起选举流程如下：

1> 更新配置纪元

2> 广播选举消息

在集群内广播选举消息（FAILOVER_AUTH_REQUEST），并记录已发送过消息的状态，保证该从节点在一个配置纪元内只能发起一次选举。

4.选举投票

只有持有槽的主节点才会处理故障选举消息（FAILOVER_AUTH_REQUEST），因为每个持有槽的节点在一个配置纪元内都有唯一的一张选票，当接到第一个请求投票的从节点消息时回复FAILOVER_AUTH_ACK消息作为投票，之后相同配置纪元内其他从节点的选举消息将忽略。

Redis集群没有直接使用从节点进行领导者选举，主要因为从节点数必须大于等于3个才能保证凑够N/2+1个节点，将导致从节点资源浪费。使用集群内所有持有槽的主节点进行领导者选举，即使只有一个从节点也可以完成选举过程。

5.替换主节点

当从节点收集到足够的选票之后，触发替换主节点操作：

1> 当前从节点取消复制变为主节点。

2> 执行clusterDelSlot操作撤销故障主节点负责的槽，并执行clusterAddSlot把这些槽委派给自己。

3> 向集群广播自己的pong消息，通知集群内所有的节点当前从节点变为主节点并接管了故障主节点的槽信息。

故障切换时间

在介绍完故障发现和恢复的流程后，我们估算下故障切换时间：

1> 主观下线（pfail）识别时间=cluster-node-timeout。

2> 主观下线状态消息传播时间<=cluster-node-timeout/2。消息通信机制对超过cluster-node-timeout/2未通信节点会发起ping消息，消息体在选择包含哪些节点时会优先选取下线状态节点，所以通常这段时间内能够收集到半数以上主节点的pfail报告从而完成故障发现。

3> 从节点转移时间<=1000毫秒。由于存在延迟发起选举机制，偏移量最大的从节点会最多延迟1秒发起选举。通常第一次选举就会成功，所以从节点执行转移时间在1秒以内。

根据以上分析可以预估出故障转移时间，如下：

failover-time(毫秒) ≤ cluster-node-timeout + cluster-node-timeout/2 + 1000

因此，故障转移时间跟cluster-node-timeout参数息息相关，默认15秒。

Redis Cluster的相关参数

cluster-enabled <yes/no>：是否开启集群模式。

cluster-config-file <filename>：集群配置文件，由集群自动维护，不建议手动编辑。

cluster-node-timeout <milliseconds>：集群中每个节点都会定期向其他节点发送ping消息，接收节点回复pong消息作为响应。如果在cluster-node-timeout时间内通信一直失败，则发送节点会认为接收节点存在故障，把接收节点标记为主观下线（pfail）状态。默认15000，即15s。

cluster-slave-validity-factor <factor>：每个从节点都要检查最后与主节点断线时间，判断其是否有资格替换故障的主节点。如果从节点与主节点断线时间超过cluster-node-time*cluster-slave-validity-factor，则当前从节点不具备故障转移资格。

cluster-migration-barrier <count>：主节点需要的最小从节点数，只有达到这个数，才会将多余的从节点迁移给其它孤立的主节点使用。

cluster-require-full-coverage <yes/no>：默认情况下当集群中16384个槽，有任何一个没有指派到节点时，整个集群是不可用的。对应在线上，如果某个主节点宕机，而又没有从节点的话，是不允许对外提供服务的。建议将该参数设置为no，避免某个主节点的故障导致其它主节点不可用。

Redis Cluster的相关命令

CLUSTER ADDSLOTS slot [slot ...]：对当前节点手动分配slot。

CLUSTER MEET ip port：将其它节点添加到Redis Cluster中。

CLUSTER INFO：打印Cluster的相关信息。

# redis-cli -c cluster info
cluster_state:ok
cluster_slots_assigned:
cluster_slots_ok:
cluster_slots_pfail:
cluster_slots_fail:
cluster_known_nodes:
cluster_size:
cluster_current_epoch:
cluster_my_epoch:
cluster_stats_messages_ping_sent:
cluster_stats_messages_pong_sent:
cluster_stats_messages_sent:
cluster_stats_messages_ping_received:
cluster_stats_messages_pong_received:
cluster_stats_messages_meet_received:
cluster_stats_messages_received:

CLUSTER KEYSLOT key：查看key对应的slot

127.0.0.1:> cluster keyslot hello
(integer)
127.0.0.1:> cluster keyslot world
(integer)
127.0.0.1:> cluster keyslot hello{tag}
(integer)
127.0.0.1:> cluster keyslot world{tag}
(integer) 

CLUSTER NODES：获取Cluster的节点信息，与当前节点的集群配置文件中的内容基本一致，只不过后者还会维护当前节点的配置纪元。

[root@slowtech conf]# redis-cli -p  -c cluster nodes
72969ae6214dce5783d5b13b1bad34701303e96c 127.0.0.1:@ slave 7396e133fd8143335d5991734e68fcfcfc5adfd1    connected
a0efce44c96f95b2cdaf1101805710f41dfe4d06 127.0.0.1:@ master -    connected -
276cf1128c50faa81a6b073079cc5e2c7a51a4ec 127.0.0.1:@ myself,master -    connected -
b39826ebe9e741c8dc1fea7ee6966a42c5030726 127.0.0.1:@ slave a0efce44c96f95b2cdaf1101805710f41dfe4d06    connected
81f99ce264626895e30a5030ac27b84efedfa622 127.0.0.1:@ slave 276cf1128c50faa81a6b073079cc5e2c7a51a4ec    connected
7396e133fd8143335d5991734e68fcfcfc5adfd1 127.0.0.1:@ master -    connected -
 
[root@slowtech conf]# cat nodes-.conf
72969ae6214dce5783d5b13b1bad34701303e96c 127.0.0.1:@ slave 7396e133fd8143335d5991734e68fcfcfc5adfd1    connected
a0efce44c96f95b2cdaf1101805710f41dfe4d06 127.0.0.1:@ master -    connected -
276cf1128c50faa81a6b073079cc5e2c7a51a4ec 127.0.0.1:@ myself,master -    connected -
b39826ebe9e741c8dc1fea7ee6966a42c5030726 127.0.0.1:@ slave a0efce44c96f95b2cdaf1101805710f41dfe4d06    connected
81f99ce264626895e30a5030ac27b84efedfa622 127.0.0.1:@ slave 276cf1128c50faa81a6b073079cc5e2c7a51a4ec    connected
7396e133fd8143335d5991734e68fcfcfc5adfd1 127.0.0.1:@ master -    connected -
vars currentEpoch  lastVoteEpoch 

CLUSTER REPLICATE node-id：在对应的从节点上执行，后面接的是主节点的节点ID。

CLUSTER SLAVES node-id：查看某个节点的从节点。

[root@slowtech conf]# redis-cli -c cluster slaves a0efce44c96f95b2cdaf1101805710f41dfe4d06
) "b39826ebe9e741c8dc1fea7ee6966a42c5030726 127.0.0.1:6384@16384 slave a0efce44c96f95b2cdaf1101805710f41dfe4d06 0 1539596409000 6 connected"
 
[root@slowtech conf]# redis-cli -c cluster slaves b39826ebe9e741c8dc1fea7ee6966a42c5030726
(error) ERR The specified node is not a master

CLUSTER SLOTS：输出slot与节点的映射关系。

# redis-cli cluster slots
) ) (integer)
   ) (integer)
   ) ) "127.0.0.1"
      ) (integer)
      ) "276cf1128c50faa81a6b073079cc5e2c7a51a4ec"
   ) ) "127.0.0.1"
      ) (integer)
      ) "81f99ce264626895e30a5030ac27b84efedfa622"
) ) (integer)
   ) (integer)
   ) ) "127.0.0.1"
      ) (integer)
      ) "7396e133fd8143335d5991734e68fcfcfc5adfd1"
   ) ) "127.0.0.1"
      ) (integer)
      ) "72969ae6214dce5783d5b13b1bad34701303e96c"
) ) (integer)
   ) (integer)
   ) ) "127.0.0.1"
      ) (integer)
      ) "a0efce44c96f95b2cdaf1101805710f41dfe4d06"
   ) ) "127.0.0.1"
      ) (integer)
      ) "b39826ebe9e741c8dc1fea7ee6966a42c5030726"

READONLY：默认情况下，从节点不对外提供读服务，即使收到了读请求，也会重定向到对应的主节点。若要读节点对外提供读服务，可执行readonly。

# redis-cli -p
127.0.0.1:> get k3
(error) MOVED  127.0.0.1:
127.0.0.1:> readonly
OK
127.0.0.1:> get k3
"hello"

READWRITE： 关闭READONLY选项。

# redis-cli -p
127.0.0.1:> get k3
(error) MOVED  127.0.0.1:
127.0.0.1:> readonly
OK
127.0.0.1:> get k3
"hello"
127.0.0.1:> readwrite
OK
127.0.0.1:> get k3
(error) MOVED  127.0.0.1:

CLUSTER SETSLOT slot IMPORTING|MIGRATING|STABLE|NODE [node-id]：设置slot的状态。

CLUSTER DELSLOTS slot [slot ...]：

注意：

1. 是否开启集群模式，从进程名中也可看出。

[root@slowtech conf]# ps -ef | grep redis
root             : ?        :: redis-server 127.0.0.1: [cluster]
root             : ?        :: redis-server 127.0.0.1: [cluster]
root             : ?        :: redis-server 127.0.0.1: [cluster]
root             : ?        :: redis-server 127.0.0.1: [cluster]
root             : ?        :: redis-server 127.0.0.1: [cluster]
root             : ?        :: redis-server 127.0.0.1: [cluster]
root         : pts/    :: grep --color=auto redis