共计 16263 个字符，预计需要花费 41 分钟才能阅读完成。
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 6379
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-6379.conf
cluster-node-timeout 15000
为简化起见，这里只贴出了 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-6379.conf nodes-6381.conf nodes-6383.conf redis_6379.conf redis_6381.conf redis_6383.conf
nodes-6380.conf nodes-6382.conf nodes-6384.conf redis_6380.conf redis_6382.conf redis_6384.conf
[root@slowtech conf]# cat nodes-6379.conf
260a27a4afd7be954f7cb4fe12be10641f379746 :0@0 myself,master – 0 0 0 connected
vars currentEpoch 0 lastVoteEpoch 0
将节点加入到集群中
redis-cli -p 6379 cluster meet 127.0.0.1 6380
redis-cli -p 6379 cluster meet 127.0.0.1 6381
redis-cli -p 6379 cluster meet 127.0.0.1 6382
redis-cli -p 6379 cluster meet 127.0.0.1 6383
redis-cli -p 6379 cluster meet 127.0.0.1 6384
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:6379> cluster nodes
260a27a4afd7be954f7cb4fe12be10641f379746 127.0.0.1:6379@16379 myself,master – 0 1539088861000 1 connected
645438fcdb241603fbc92770ef08fa6d2d4c7ffc 127.0.0.1:6380@16380 master – 0 1539088860000 2 connected
bf1aa1e626988a5a35bc2a837c3923d472e49a4c 127.0.0.1:6381@16381 master – 0 1539088860730 0 connected
5350673149500f4c2fd8b87a8ec1b01651572fae 127.0.0.1:6383@16383 master – 0 1539088861000 4 connected
7dd5f5cc8d96d08f35ff395d05eb30ac199f7568 127.0.0.1:6382@16382 master – 0 1539088862745 3 connected
8679f302610e9ea9a464c247f70924e34cd20512 127.0.0.1:6384@16384 master – 0 1539088862000 5 connected
虽然六个节点已经加入到集群中了，但此时集群仍处于下线状态。
127.0.0.1:6379> cluster info
cluster_state:fail
cluster_slots_assigned:0
cluster_slots_ok:0
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:6
cluster_size:0
cluster_current_epoch:5
cluster_my_epoch:1
cluster_stats_messages_ping_sent:799
cluster_stats_messages_pong_sent:826
cluster_stats_messages_meet_sent:5
cluster_stats_messages_sent:1630
cluster_stats_messages_ping_received:826
cluster_stats_messages_pong_received:804
cluster_stats_messages_received:1630
分配槽
将 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 6379
127.0.0.1:6379> cluster info
cluster_state:ok
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:6
cluster_size:3
cluster_current_epoch:5
cluster_my_epoch:1
cluster_stats_messages_ping_sent:6212
cluster_stats_messages_pong_sent:6348
cluster_stats_messages_meet_sent:5
cluster_stats_messages_sent:12565
cluster_stats_messages_ping_received:6348
cluster_stats_messages_pong_received:6217
cluster_stats_messages_received:12565
查看节点和槽的分配关系
127.0.0.1:6379> cluster nodes
260a27a4afd7be954f7cb4fe12be10641f379746 127.0.0.1:6379@16379 myself,master – 0 1539094639000 1 connected 0-5461
645438fcdb241603fbc92770ef08fa6d2d4c7ffc 127.0.0.1:6380@16380 master – 0 1539094636362 2 connected 5462-10922
bf1aa1e626988a5a35bc2a837c3923d472e49a4c 127.0.0.1:6381@16381 master – 0 1539094639389 0 connected 10923-16383
5350673149500f4c2fd8b87a8ec1b01651572fae 127.0.0.1:6383@16383 master – 0 1539094637000 4 connected
7dd5f5cc8d96d08f35ff395d05eb30ac199f7568 127.0.0.1:6382@16382 master – 0 1539094638000 3 connected
8679f302610e9ea9a464c247f70924e34cd20512 127.0.0.1:6384@16384 master – 0 1539094638381 5 connected
使用 cluster replicate 添加从节点
cluster replicate 命令必须在对应的从节点上执行，后面接的是主节点的节点 ID。
[root@slowtech conf]# redis-cli -p 6382
127.0.0.1:6382> cluster replicate 260a27a4afd7be954f7cb4fe12be10641f379746
OK
127.0.0.1:6382> quit
[root@slowtech conf]# redis-cli -p 6383
127.0.0.1:6383> cluster replicate 645438fcdb241603fbc92770ef08fa6d2d4c7ffc
OK
127.0.0.1:6383> quit
[root@slowtech conf]# redis-cli -p 6384
127.0.0.1:6384> cluster replicate bf1aa1e626988a5a35bc2a837c3923d472e49a4c
OK
快捷命令
echo “cluster replicate `redis-cli -p 6379 cluster nodes | grep 6379 | awk ‘{print $1}’`” | redis-cli -p 6382 -x
echo “cluster replicate `redis-cli -p 6379 cluster nodes | grep 6380 | awk ‘{print $1}’`” | redis-cli -p 6383 -x
echo “cluster replicate `redis-cli -p 6379 cluster nodes | grep 6381 | awk ‘{print $1}’`” | redis-cli -p 6384 -x
查看节点和槽的分配关系
127.0.0.1:6384> cluster nodes
8679f302610e9ea9a464c247f70924e34cd20512 127.0.0.1:6384@16384 myself,slave bf1aa1e626988a5a35bc2a837c3923d472e49a4c 0 1539094947000 5 connected
7dd5f5cc8d96d08f35ff395d05eb30ac199f7568 127.0.0.1:6382@16382 slave 260a27a4afd7be954f7cb4fe12be10641f379746 0 1539094947000 3 connected
5350673149500f4c2fd8b87a8ec1b01651572fae 127.0.0.1:6383@16383 slave 645438fcdb241603fbc92770ef08fa6d2d4c7ffc 0 1539094946000 4 connected
bf1aa1e626988a5a35bc2a837c3923d472e49a4c 127.0.0.1:6381@16381 master – 0 1539094948000 0 connected 10923-16383
645438fcdb241603fbc92770ef08fa6d2d4c7ffc 127.0.0.1:6380@16380 master – 0 1539094947306 2 connected 5462-10922
260a27a4afd7be954f7cb4fe12be10641f379746 127.0.0.1:6379@16379 master – 0 1539094948308 1 connected 0-5461
至此，我们基于 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. 首先，该节点对应的从节点会有日志输出。
16387:S 15 Oct 10:34:30.149 # Connection with master lost.
16387:S 15 Oct 10:34:30.149 * Caching the disconnected master state.
16387:S 15 Oct 10:34:30.845 * Connecting to MASTER 127.0.0.1:6379
16387:S 15 Oct 10:34:30.845 * MASTER <-> SLAVE sync started
16387:S 15 Oct 10:34:30.845 # Error condition on socket for SYNC: Connection refused
…
16387:S 15 Oct 10:34:49.994 * MASTER <-> SLAVE sync started
16387:S 15 Oct 10:34:49.994 # Error condition on socket for SYNC: Connection refused
16387:S 15 Oct 10:34:50.898 * FAIL message received from bd341bb4c10e0dbff593bf7bafb1309842fba155 about 72af03587f5e9f064721d3b3a92b1439b3785623
16387:S 15 Oct 10:34:50.898 # Cluster state changed: fail
发现连接断开的时间点是 10:34:30.149，判断其主观下线的时间为 10:34:50，相差 20s，这也是 cluster-node-timeout 的设置。
2. 再来看看 6380 节点的日志。
16383:M 15 Oct 10:34:50.897 * Marking node 72af03587f5e9f064721d3b3a92b1439b3785623 as failing (quorum reached).
16383:M 15 Oct 10:34:50.897 # Cluster state changed: fail
6381 节点的日志同样如此，超过半数，因此标记 6379 节点为客观下线。
3. 再来看看从节点的日志
16387:S 15 Oct 10:34:51.003 * Connecting to MASTER 127.0.0.1:6379
16387:S 15 Oct 10:34:51.003 * MASTER <-> SLAVE sync started
16387:S 15 Oct 10:34:51.003 # Start of election delayed for 566 milliseconds (rank #0, offset 154).
16387:S 15 Oct 10:34:51.003 # Error condition on socket for SYNC: Connection refused
从节点识别正在复制的主节点进入客观下线后准备选举时间，日志打印了选举延迟 566 毫秒之后执行。
延迟选举时间到达后，从节点更新配置纪元并发起故障选举。
16387:S 15 Oct 10:34:51.605 # Starting a failover election for epoch 7.
4. 6380 和 6381 主节点为从节点投票
16385:M 15 Oct 10:34:51.618 # Failover auth granted to 886c1f990191854df1972c4bc4d928e44bd36937 for epoch 7
5. 从节点获取 2 个主节点投票之后，超过半数执行替换主节点操作，完成故障切换。
16387:S 15 Oct 10:34:51.622 # Failover election won: I’m the new master.
16387:S 15 Oct 10:34:51.622 # configEpoch set to 7 after successful failover
16387:M 15 Oct 10:34:51.622 # Setting secondary replication ID to 207c65316707a8ec2ca83725ae53ab49fa25dbfb, valid up to offset: 155. New replication ID is 0ec4aac9562b3f4165244153646d9c9006953736
16387:M 15 Oct 10:34:51.622 * Discarding previously cached master state.
16387:M 15 Oct 10:34: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:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:6
cluster_size:3
cluster_current_epoch:6
cluster_my_epoch:1
cluster_stats_messages_ping_sent:702
cluster_stats_messages_pong_sent:664
cluster_stats_messages_sent:1366
cluster_stats_messages_ping_received:659
cluster_stats_messages_pong_received:702
cluster_stats_messages_meet_received:5
cluster_stats_messages_received:1366
CLUSTER KEYSLOT key：查看 key 对应的 slot
127.0.0.1:6379> cluster keyslot hello
(integer) 866
127.0.0.1:6379> cluster keyslot world
(integer) 9059
127.0.0.1:6379> cluster keyslot hello{tag}
(integer) 8338
127.0.0.1:6379> cluster keyslot world{tag}
(integer) 8338
CLUSTER NODES：获取 Cluster 的节点信息，与当前节点的集群配置文件中的内容基本一致，只不过后者还会维护当前节点的配置纪元。
[root@slowtech conf]# redis-cli -p 6380 -c cluster nodes
72969ae6214dce5783d5b13b1bad34701303e96c 127.0.0.1:6382@16382 slave 7396e133fd8143335d5991734e68fcfcfc5adfd1 0 1539594959692 4 connected
a0efce44c96f95b2cdaf1101805710f41dfe4d06 127.0.0.1:6381@16381 master – 0 1539594962724 3 connected 10923-16383
276cf1128c50faa81a6b073079cc5e2c7a51a4ec 127.0.0.1:6380@16380 myself,master – 0 1539594958000 2 connected 5461-10922
b39826ebe9e741c8dc1fea7ee6966a42c5030726 127.0.0.1:6384@16384 slave a0efce44c96f95b2cdaf1101805710f41dfe4d06 0 1539594961000 6 connected
81f99ce264626895e30a5030ac27b84efedfa622 127.0.0.1:6383@16383 slave 276cf1128c50faa81a6b073079cc5e2c7a51a4ec 0 1539594961713 5 connected
7396e133fd8143335d5991734e68fcfcfc5adfd1 127.0.0.1:6379@16379 master – 0 1539594960703 1 connected 0-5460
[root@slowtech conf]# cat nodes-6380.conf
72969ae6214dce5783d5b13b1bad34701303e96c 127.0.0.1:6382@16382 slave 7396e133fd8143335d5991734e68fcfcfc5adfd1 0 1539592972569 4 connected
a0efce44c96f95b2cdaf1101805710f41dfe4d06 127.0.0.1:6381@16381 master – 0 1539592969000 3 connected 10923-16383
276cf1128c50faa81a6b073079cc5e2c7a51a4ec 127.0.0.1:6380@16380 myself,master – 0 1539592969000 2 connected 5461-10922
b39826ebe9e741c8dc1fea7ee6966a42c5030726 127.0.0.1:6384@16384 slave a0efce44c96f95b2cdaf1101805710f41dfe4d06 0 1539592971000 6 connected
81f99ce264626895e30a5030ac27b84efedfa622 127.0.0.1:6383@16383 slave 276cf1128c50faa81a6b073079cc5e2c7a51a4ec 0 1539592971000 5 connected
7396e133fd8143335d5991734e68fcfcfc5adfd1 127.0.0.1:6379@16379 master – 0 1539592971558 1 connected 0-5460
vars currentEpoch 6 lastVoteEpoch 0
CLUSTER REPLICATE node-id：在对应的从节点上执行，后面接的是主节点的节点 ID。
CLUSTER SLAVES node-id：查看某个节点的从节点。
[root@slowtech conf]# redis-cli -c cluster slaves a0efce44c96f95b2cdaf1101805710f41dfe4d06
1) “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
1) 1) (integer) 5461
2) (integer) 10922
3) 1) “127.0.0.1”
2) (integer) 6380
3) “276cf1128c50faa81a6b073079cc5e2c7a51a4ec”
4) 1) “127.0.0.1”
2) (integer) 6383
3) “81f99ce264626895e30a5030ac27b84efedfa622”
2) 1) (integer) 0
2) (integer) 5460
3) 1) “127.0.0.1”
2) (integer) 6379
3) “7396e133fd8143335d5991734e68fcfcfc5adfd1”
4) 1) “127.0.0.1”
2) (integer) 6382
3) “72969ae6214dce5783d5b13b1bad34701303e96c”
3) 1) (integer) 10923
2) (integer) 16383
3) 1) “127.0.0.1”
2) (integer) 6381
3) “a0efce44c96f95b2cdaf1101805710f41dfe4d06”
4) 1) “127.0.0.1”
2) (integer) 6384
3) “b39826ebe9e741c8dc1fea7ee6966a42c5030726”
READONLY：默认情况下，从节点不对外提供读服务，即使收到了读请求，也会重定向到对应的主节点。若要读节点对外提供读服务，可执行 readonly。
# redis-cli -p 6382
127.0.0.1:6382> get k3
(error) MOVED 4576 127.0.0.1:6379
127.0.0.1:6382> readonly
OK
127.0.0.1:6382> get k3
“hello”
READWRITE：关闭 READONLY 选项。
# redis-cli -p 6382
127.0.0.1:6382> get k3
(error) MOVED 4576 127.0.0.1:6379
127.0.0.1:6382> readonly
OK
127.0.0.1:6382> get k3
“hello”
127.0.0.1:6382> readwrite
OK
127.0.0.1:6382> get k3
(error) MOVED 4576 127.0.0.1:6379
CLUSTER SETSLOT slot IMPORTING|MIGRATING|STABLE|NODE [node-id]：设置 slot 的状态。
CLUSTER DELSLOTS slot [slot …]：
注意：
1. 是否开启集群模式，从进程名中也可看出。
[root@slowtech conf]# ps -ef | grep redis
root 17497 1 0 20:18 ? 00:00:00 redis-server 127.0.0.1:6379 [cluster]
root 17720 1 0 20:21 ? 00:00:00 redis-server 127.0.0.1:6380 [cluster]
root 17727 1 0 20:21 ? 00:00:00 redis-server 127.0.0.1:6381 [cluster]
root 17734 1 0 20:21 ? 00:00:00 redis-server 127.0.0.1:6382 [cluster]
root 17741 1 0 20:21 ? 00:00:00 redis-server 127.0.0.1:6383 [cluster]
root 17748 1 0 20:21 ? 00:00:00 redis-server 127.0.0.1:6384 [cluster]
root 18154 15726 0 20:29 pts/5 00:00:00 grep –color=auto redis
：
