二十一、Redis进阶-Redis集群记录

配置集群

使用集群需要将相关配置打开，这些配置建议写在单独的配置文件中。

cluster-enabled 是否开启集群

cluster-config-file 集群节点配置文件路径（启动后自动生成该文件）。

cluster-node-timeout 超时时间

客户端命令

启动集群后，客户端连接，查看集群相关命令

info cluster查看集群是否启用

127.0.0.1:9003> info cluster
# Cluster
cluster_enabled:1

cluster_enabled为1表示启用

cluster nodes 查看集群中所有节点信息

127.0.0.1:9003> cluster nodes
8ae9e888cd78d05f507a0854ca448bdec9a9c2db 127.0.0.1:9003@19003 myself,slave 591a32f5077a38828ef27073750717678314be7e 0 1599409070000 2 connected
8b0ba372622f2b668402f76fbafe382045992540 127.0.0.1:9005@19005 master - 0 1599409071000 7 connected 0-5460
591a32f5077a38828ef27073750717678314be7e 127.0.0.1:9001@19001 master - 0 1599409072000 2 connected 5461-10922
cf2c6c30ce292036343d6b0422d0eb009b04baf8 127.0.0.1:9000@19000 slave 8b0ba372622f2b668402f76fbafe382045992540 0 1599409073509 7 connected
c16c9e3a6f7c262a15659d21fc01e3ff8ff160db 127.0.0.1:9002@19002 master - 0 1599409072479 3 connected 10923-16383
f155a57e3565835051456b97a3e3625552228e9c 127.0.0.1:9004@19004 slave c16c9e3a6f7c262a15659d21fc01e3ff8ff160db 0 1599409071000 3 connected

插槽分配

在一个集群中，所有键会被分配给16384个插槽(slot)，而每个主数据库会负责处理其中的一部分插槽。

M: cf2c6c30ce292036343d6b0422d0eb009b04baf8 127.0.0.1:9000
  slots:[0-5460] (5461 slots) master
M: 591a32f5077a38828ef27073750717678314be7e 127.0.0.1:9001
  slots:[5461-10922] (5462 slots) master
M: c16c9e3a6f7c262a15659d21fc01e3ff8ff160db 127.0.0.1:9002
  slots:[10923-16383] (5461 slots) master

可以看到，9000负责0-5460个插槽。初始化集群时分配给每个节点的插槽都是连续的，事实上Redis对此并没有限制，可以将任意插槽分配级任意的节点负责。

**键与插槽的关系。**Redis将每个键的键名的有效部分使用CRC16算法计算出哈希值，然后对剩余的16384取余。有效键名如下：

1）如果键名包含 {符号，且在{符合后面存在} }符号，并且和{和}之间有至少一个字符，则有效部分是指{和}之间的内容；

2）如果不满足上一条规则，那么整个键名为有效部分。

如：键hello.world的有效部分为“hello.word”，键{user102}:last.name的有效部分为"user102"

插槽的分配情况：

1）插槽之前没有被分配过，现在想分配给指定节点

2）插槽之前被分配过，现在想移动到指定节点

cluster slots查看插槽分配情况

127.0.0.1:9003> cluster slots
1) 1) (integer) 0
   2) (integer) 5460
   3) 1) "127.0.0.1"
      2) (integer) 9005
      3) "8b0ba372622f2b668402f76fbafe382045992540"
   4) 1) "127.0.0.1"
      2) (integer) 9000
      3) "cf2c6c30ce292036343d6b0422d0eb009b04baf8"
2) 1) (integer) 5461
   2) (integer) 10922
   3) 1) "127.0.0.1"
      2) (integer) 9001
      3) "591a32f5077a38828ef27073750717678314be7e"
   4) 1) "127.0.0.1"
      2) (integer) 9003
      3) "8ae9e888cd78d05f507a0854ca448bdec9a9c2db"
3) 1) (integer) 10923
   2) (integer) 16383
   3) 1) "127.0.0.1"
      2) (integer) 9002
      3) "c16c9e3a6f7c262a15659d21fc01e3ff8ff160db"
   4) 1) "127.0.0.1"
      2) (integer) 9004
      3) "f155a57e3565835051456b97a3e3625552228e9c"

关于更多详情，官方文档很清楚

故障恢复

在一个集群中，每个节点都会定期向其他节点发送PING名，并通过有没有收到回复来判断目标是否已经下线。

具体来说，集群中的每个节点每隔1秒就会随机选择5个节点，然后选择其中最久没有响应节点发送PING命令。

一定时间内目标节点没能响应回复，则发起PING命令的节点会认为目标节点疑似下线。 如何确定某一个节点下线：

1）一旦节点A认为节点B疑似下线，就会在集群中传播该消息，所有其他节点收到消息后都会记录这一信息；

2）当集群中的某一节点C收集到半数以上的节点节点认为B是疑似下线的状态时，就会将B标记为下线，并且向集群中的其他节点传播该信息，从而使用B在整个集群中下线。

在集群中，当一个主数据库下线时，就会出现一部分插槽无法写入的问题。如果该主数据库至少有一个从数据库，集群就进行故障恢复操作来将其中一个从数据库切换为主数据库。其过程与哨兵类似，不再记录。

关于Reids的部分记录到这里完毕了。