从零到一，构建坚如磐石的Redis 7高可用集群：全程实录与关键技术详解

冷不防 2024-04-28 08:08 16阅读 0赞

## 1、引言 ##

在日常的开发中，无论是主从复制还是哨兵模式，都在高并发的场景中存在致命的缺点：

1.  主从复制：当Master Redis机器挂掉之后，Slave依旧可以读取数据，但是由于Master不能写数据了，所以就会导致这个时间段的数据直接存入数据库或者丢失。
2.  哨兵模式：当进行Master机器扩展的时候，需要手动的配置哨兵集群，然后重新启动哨兵Redis，当哨兵Redis机器过多时，就会非常复杂且耗时。

Redis集群模式可以解决上述存在的问题，同时集群模式也是市面上推荐的方式。

### 1.1、Redis集群简介 ###

Redis集群是一个提供在多个Redis节点间共享数据的程序集。**它并不支持处理多个keys的命令，因为这需要在不同的节点间移换数据，从而达不到Redis那样的性能，特别是在高负载的情况下，可能会导致不可预料的错误。**

Redis集群通过分区来提供一定程度的可用性。在实际环境中，当某个节点宕机或者不可达时，集群仍然能够继续处理命令。集群的主要优势在于它可以自动分隔数据到不同的节点，并在整个集群的部分节点失败或者不可达的情况下，仍然能够继续处理命令。

所有的Redis主节点彼此互联，采用PING-PONG机制进行通信，内部使用二进制协议优化传输速度和带宽。节点的失败是通过集群中超过半数的节点检测确认失效时才生效。客户端与Redis节点直连，不需要中间proxy层，客户端只需要连接集群中任何一个可用的节点即可。

### 1.2、集群搭建的重要性与优势 ###

（1）重要性：

*  **数据可靠性**：集群搭建能够确保数据在多个节点间进行备份和同步，从而防止单点故障导致的数据丢失。当某个节点出现故障时，其他节点可以接管其工作，确保系统的连续性和数据的完整性。
 *  **性能提升**：通过集群搭建，可以将数据分布在多个节点上，实现负载均衡。这不仅可以提高系统的吞吐量，降低延迟，还能够应对高并发读写请求，从而提升系统的整体性能。
 *  **扩展性**：随着业务的发展，数据量可能会急剧增长。集群搭建使得Redis能够水平扩展，通过动态添加或删除节点来适应不同的数据量和性能需求。

（2）优势：

*  **高可用性与容错性**：Redis集群通过数据分片和数据复制来提供高可用性和容错性。即使部分节点发生故障，集群仍然能够继续工作，并通过数据复制从其他节点获取数据，保证服务的连续性。
 *  **简化管理**：集群搭建可以统一管理和监控多个Redis节点，降低了单独管理每个节点的复杂性。此外，通过集群管理工具，可以方便地执行节点添加、删除、扩容等操作，提高了运维效率。
 *  **资源利用优化**：集群可以根据节点的负载情况动态分配数据，实现资源的均衡利用。这不仅可以避免某些节点过载，还可以确保整个集群的性能得到充分发挥。

### 1.3、集群搭建前的准备工作 ###

*  了解Redis 7的主从复制，可以看我之前的博客：[Redis 7.0版本主从复制机制][Redis 7.0]
 *  熟悉使用Docker拉去镜像、启动容器。

## 2、Redis集群基础知识 ##

![在这里插入图片描述][c054c5a1d5534391a4e55869029b2c68.png]  
（1）Key的分布式模型  
Hash\_Slot = CRC16(key) % 16384  
集群的密钥空间被分成16384个槽，有效的设置了16384个主节点的集群大小上限，官方建议最大节点大小为1000个节点。  
（2）槽位Slot  
Redis集群没有使用一致性Hash而是引入了Hash槽的概念，Redis集群有16384个Hash槽，每个Key通过CRC16检验后对16384去模来决定放置在哪个槽中，每个节点负责一部分Hash槽。  
可以将集群看作一个小区，每个节点都是一栋楼，而Slot就是每栋楼中的房间，每个Slot会存在一个Slot号，也就是房间号。

Redis集群的原理主要基于数据分片和节点间的通信机制，以实现数据的分布式存储和访问。

### 2.1、数据分片 ###

Redis集群将数据分散存储在多个节点上，通过一种称为“哈希槽”（hash slot）的机制来实现数据分片。在Redis集群中，一共有16384个哈希槽，每个节点负责处理一部分哈希槽。当客户端需要访问某个key时，Redis会根据key的哈希值计算其所属的哈希槽，然后找到负责处理该哈希槽的节点进行访问。这种数据分片的方式使得数据可以均匀地分布在各个节点上，提高了系统的存储能力和并发处理能力。

### 2.2、节点通信 ###

Redis集群中的节点通过Gossip协议进行彼此通信，以维护集群的元数据和状态信息。Gossip协议是一种去中心化的通信机制，节点之间不断交换信息，最终使得每个节点都拥有集群的完整视图。在Redis集群中，每个节点都会定期向其他节点发送ping消息，以检测节点的存活状态，并交换集群的元数据。当某个节点出现故障时，其他节点可以通过通信机制感知到，并采取相应的措施进行故障转移和数据恢复。

### 2.3、智能路由 ###

Redis集群提供了智能路由功能，使得客户端可以透明地访问集群中的数据。当客户端发送一个请求到任意一个节点时，该节点会根据请求的key计算其所属的哈希槽，并判断自己是否负责处理该哈希槽。如果负责，则直接处理该请求；如果不负责，则根据集群的元数据将请求转发到正确的节点上。这种智能路由机制使得客户端无需关心数据的具体存储位置，简化了访问过程。

### 2.4、数据副本与故障转移 ###

为了确保数据的高可用性和可靠性，Redis集群中的每个节点都可以配置一个或多个从节点进行数据复制。主节点负责处理写请求，而从节点则同步主节点的数据，用于处理读请求和提供故障转移的能力。当主节点出现故障时，Redis集群可以通过自动故障转移机制将从节点提升为主节点，以保证服务的连续性。

### 2.5、重定向 ###

在Redis集群中，重定向是客户端与节点间通信的重要机制。当客户端尝试访问一个key时，如果它连接的节点并不负责处理该key所属的哈希槽，那么该节点会向客户端返回一个重定向错误，并告知客户端正确的节点地址。客户端在接收到重定向错误后，会重新连接到正确的节点，并重新发送请求。

重定向机制使得客户端能够透明地访问集群中的数据，无需关心数据的具体存储位置。同时，它也为Redis集群提供了灵活的数据迁移和故障转移能力，使得集群能够应对节点宕机、数据迁移等场景，保持服务的连续性和可用性。  
![在这里插入图片描述][85bf56ee28724db49c18fa46a82716db.png]

## 3、环境准备 ##

### 3.1、安装Docker ###

（1）Windows系统  
对于Windows系统安装Docker，可以参考我以前的博客：[Windows安装Docker运行中间件(详细）][Windows_Docker]，这篇博客详细的介绍了Windows 10如何安装Docker到打包、部署容器。

（2）Linux系统或者服务器  
对于Linux类型的系统，只需要执行以下命令就可以安装Docker了。

yum install docker

### 3.2、安装Redis服务器 ###

（1）创建目录

## 以下路径都是根据自己电脑自定义的
    ## Master节点目录
    mkdir /usr/tt/master
    mkdir /usr/tt/master/conf
    mkdir /usr/tt/master/data
    
    ## Slave节点目录
    mkdir /usr/tt/slave
    mkdir /usr/tt/slave/conf
    mkdir /usr/tt/slave/data

（2）上传redis.conf文件（**可选**）  
在使用Docker拉取的Redis镜像中，需要绑定一个redis.conf文件，一般拉取下来是没有的，所以需要我们上传一个或者自己写一个，上传的redis.conf文件，可以去Redis官网下载好后上传服务器，而自己编写一个redis.conf只需要简单的写如下属性：

bind 0.0.0.0
    port 8900
    cluster-enabled yes
    appendonly yes
    cluster-config-file node_6379.conf
    cluster-node-timeout 20000

上传的redis.conf也只需要修改这么几个属性就可以了。  
开启集群最重要的一个配置就是`cluster-enabled yes`这个属性。

### 4、集群搭建步骤 ###

> 创建从8900~8902端口的三台主机redis.conf文件。  
> 再创建从8903~8905端口的三台从机redis.conf文件。

主机和从机的配置文件除了`port`和`cluster-confi-file`两个属性不一样，其他的都可以采用默认的配置。

在上述步骤都成功实现后，就可以开始搭建Redis集群了。

### 4.1、配置Redis集群模式 ###

无论是Master还是Slave，在Redis集群模式中，至少启动三台（Master、Slave各三台）。

#### 4.1.1、启动容器 ####

这个地方的端口我配置的不是6379，我在redis.conf文件中配置了`port`属性，所以端口就从6379改为了8900。需要的可以自行修改。

## 使用配置文件
    docker run -d --name tt_Master_Redis_1 -p 8900:8900\
    -v /usr/tt/master_1/conf/redis.conf:/etc/redis/redis.conf \
    -v /usr/tt/master_1/data:/data \
    d1397258b209 \
    redis-server /etc/redis/redis.conf
    
    ## 不使用配置文件，直接使用Docker命令启动
    docker run -d --name tt_Master_Redis_1 -p 8900:8900 d1397258b209 \
    redis-server --port 6379 \
    --cluster-enabled yes \
    --cluster-config-file nodes.conf \
    --appendonly yes

按照以上方式启动三主三从，主机和从机的启动方式都是一样的。

#### 4.1.2、查看容器状态 ####

在容器内部使用`docker logs 容器ID`查看Redis启动日志。

1:C 09 Mar 2024 11:24:32.023 # WARNING: Changing databases number from 16 to 1 since we are in cluster mode
    1:C 09 Mar 2024 11:24:32.023 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
    1:C 09 Mar 2024 11:24:32.023 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
    1:C 09 Mar 2024 11:24:32.023 * Redis version=7.2.4, bits=64, commit=00000000, modified=0, pid=1, just started
    1:C 09 Mar 2024 11:24:32.023 * Configuration loaded
    1:M 09 Mar 2024 11:24:32.024 * monotonic clock: POSIX clock_gettime
    1:M 09 Mar 2024 11:24:32.024 * Running mode=cluster, port=8900.
    1:M 09 Mar 2024 11:24:32.024 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
    1:M 09 Mar 2024 11:24:32.025 * No cluster configuration found, I'm c4d671d53518db7d41c1d3db15f9a56f480f2845
    1:M 09 Mar 2024 11:24:32.028 * Server initialized
    1:M 09 Mar 2024 11:24:32.028 * Reading RDB base file on AOF loading...
    1:M 09 Mar 2024 11:24:32.028 * Loading RDB produced by version 7.2.4
    1:M 09 Mar 2024 11:24:32.028 * RDB age 68 seconds
    1:M 09 Mar 2024 11:24:32.028 * RDB memory usage when created 1.51 Mb
    1:M 09 Mar 2024 11:24:32.028 * RDB is base AOF
    1:M 09 Mar 2024 11:24:32.028 * Done loading RDB, keys loaded: 0, keys expired: 0.
    1:M 09 Mar 2024 11:24:32.028 * DB loaded from base file appendonly.aof.1.base.rdb: 0.000 seconds
    1:M 09 Mar 2024 11:24:32.028 * DB loaded from append only file: 0.000 seconds
    1:M 09 Mar 2024 11:24:32.028 * Opening AOF incr file appendonly.aof.1.incr.aof on server start
    1:M 09 Mar 2024 11:24:32.028 * Ready to accept connections tcp

只要出现`Running mode=cluster, port=8900.`这段命令，并且使用Client能够访问到Redis，则表示Redis以集群模式启动成功。

#### 4.1.3、为什么最小是三主三从？ ####

如果在Redis中搭建集群最小的规模不是三主三从，在使用Redis Cluster命令初始化集群的时候就会报错：

*** ERROR: Invalid configuration for cluster creation.                                                                                                                                                                                                                      
    *** Redis Cluster requires at least 3 master nodes.                                                                                                                                                                                                                         
    *** This is not possible with 2 nodes and 1 replicas per node.                                                                                                                                                                                                              
    *** At least 6 nodes are required.

上面的错误就会告诉我们，集群的最小规模是三主三从。

### 4.2、使用Redis Cluster命令行工具搭建集群 ###

在完成上述操作后，还有很重要的一步：**查看Redis容器IP地址，查看Redis容器IP地址，查看Redis容器IP地址。**

**因为我们使用的是Docker虚拟化部署的Redis服务器，所以Redis内部集群之间的访问不是云服务器（我的Docker部署在云服务器上）的地址，而是Docker为Redis服务器分配了IP地址。在现实的开发中，这个地址就是远程Redis主机的IP地址。**

说实话，这是我踩到的一个坑，我硬是解决了两天，我一直认为是自己的配置文件配错了或者是云服务器的端口和IP地址没有映射成功，就一直在改配置文件，也同时在网上找了很多博主写的博客，几乎没找到有说过这一步的。

#### 4.2.1、查看容器的IP地址（重要） ####

查看容器的IP地址，我们可以在Redis容器成功启动后，使用`docker inspect 容器ID/容器名称 | grep IPAddress`命令来查看Docker为容器分配的IP地址。

docker inspect tt_Master_Redis_1 | grep IPAddress

查看结果可以得到：

"SecondaryIPAddresses": null,
    "IPAddress": "172.17.0.7",
    "IPAddress": "172.17.0.7",

`172.17.0.7`这个IP地址就是Docker为tt\_Master\_Redis\_1这个容器分配的IP地址。

#### 4.2.2、搭建集群 ####

在搭建好三主三从的六台Redis服务后，我们可以随便进入一个Redis服务的内部：

docker exec -it 容器ID /bin/bash

进入后直接执行以下指令：

redis-cli --cluster create \
    Master_1地址:端口 Slave_1地址:端口 \
    Master_2地址:端口 Slave_2地址:端口 \
    Master_3地址:端口 Slave_3地址:端口 \
    --cluster-replicas 1

在回车后等待一段时间让Redis自动初始化集群信息。初始化完成后就会看到下列内容：

>>> Performing hash slots allocation on 6 nodes...
    Master[0] -> Slots 0 - 5460
    Master[1] -> Slots 5461 - 10922
    Master[2] -> Slots 10923 - 16383
    Adding replica 172.17.0.7:8902 to 172.17.0.5:8900
    Adding replica 172.17.0.10:8905 to 172.17.0.8:8903
    Adding replica 172.17.0.9:8904 to 172.17.0.6:8901
    M: a799a8c4e709eea899b186163d068eb8637bf1ab 172.17.0.5:8900
       slots:[0-5460] (5461 slots) master
    M: 90bf16a87c85a4f11e54c128896be90be083ff25 172.17.0.8:8903
       slots:[5461-10922] (5462 slots) master
    M: bdacb0a18f092f814c92e87444f2c363c48486a1 172.17.0.6:8901
       slots:[10923-16383] (5461 slots) master
    S: 184a44ad4883cb7a4bf1852340a413f24931400a 172.17.0.9:8904
       replicates bdacb0a18f092f814c92e87444f2c363c48486a1
    S: 61212f108d61cd69a9e7725b326f92be27949340 172.17.0.7:8902
       replicates a799a8c4e709eea899b186163d068eb8637bf1ab
    S: c4d671d53518db7d41c1d3db15f9a56f480f2845 172.17.0.10:8905
       replicates 90bf16a87c85a4f11e54c128896be90be083ff25
    Can I set the above configuration? (type 'yes' to accept): yes
    >>> Nodes configuration updated
    >>> Assign a different config epoch to each node
    >>> Sending CLUSTER MEET messages to join the cluster
    Waiting for the cluster to join
    ....
    >>> Performing Cluster Check (using node 172.17.0.5:8900)
    M: a799a8c4e709eea899b186163d068eb8637bf1ab 172.17.0.5:8900
       slots:[0-5460] (5461 slots) master
       1 additional replica(s)
    S: 184a44ad4883cb7a4bf1852340a413f24931400a 172.17.0.9:8904
       slots: (0 slots) slave
       replicates bdacb0a18f092f814c92e87444f2c363c48486a1
    S: 61212f108d61cd69a9e7725b326f92be27949340 172.17.0.7:8902
       slots: (0 slots) slave
       replicates a799a8c4e709eea899b186163d068eb8637bf1ab
    M: 90bf16a87c85a4f11e54c128896be90be083ff25 172.17.0.8:8903
       slots:[5461-10922] (5462 slots) master
       1 additional replica(s)
    M: bdacb0a18f092f814c92e87444f2c363c48486a1 172.17.0.6:8901
       slots:[10923-16383] (5461 slots) master
       1 additional replica(s)
    S: c4d671d53518db7d41c1d3db15f9a56f480f2845 172.17.0.10:8905
       slots: (0 slots) slave
       replicates 90bf16a87c85a4f11e54c128896be90be083ff25
    [OK] All nodes agree about slots configuration.
    >>> Check for open slots...
    >>> Check slots coverage...
    [OK] All 16384 slots covered.

在`Can I set the above configuration?`询问的时候，一定要回答`yes`，回答其他的都是`no`。  
看到以上信息则表示Redis集群初始化成功。

如果回答了yes之后，一直处于等待的状态，可能是存在三个问题：

1.  **Redis服务器的IP地址和端口不正确**，我之前就是不知道Docker内部还会分配IP，导致一直是等待状态。
2.  防火墙是否对当前IP和端口进行了拦截。
3.  当前机器的网络是否能和Redis服务器连通，同时Redis服务器也能与本机连通。

### 4.3、验证集群状态 ###

我们可以在客户端使用`cluster nodes`和`cluster info`命令来查看集群的信息：

（1）cluster info  
当在客户端执行了这个命令后，就会出现下列的配置信息，如果出现`cluster_state:ok`这个信息，就代表集群配置成功。

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:10
    cluster_my_epoch:1
    cluster_stats_messages_ping_sent:3162
    cluster_stats_messages_pong_sent:3225
    cluster_stats_messages_fail_sent:32
    cluster_stats_messages_auth-ack_sent:4
    cluster_stats_messages_sent:6423
    cluster_stats_messages_ping_received:3220
    cluster_stats_messages_pong_received:3132
    cluster_stats_messages_meet_received:5
    cluster_stats_messages_fail_received:28
    cluster_stats_messages_auth-req_received:6
    cluster_stats_messages_received:6391
    total_cluster_links_buffer_limit_exceeded:0

（2）cluster nods  
这个命令是查看集群节点信息的命令，在客户端执行了这个命令后，就可以看到整个集群的节点信息。

184a44ad4883cb7a4bf1852340a413f24931400a 172.17.0.9:8904@18904 master - 0 1709986378959 8 connected 10923-16383
    61212f108d61cd69a9e7725b326f92be27949340 172.17.0.7:8902@18902 slave a799a8c4e709eea899b186163d068eb8637bf1ab 0 1709986377454 1 connected
    90bf16a87c85a4f11e54c128896be90be083ff25 172.17.0.8:8903@18903 slave c4d671d53518db7d41c1d3db15f9a56f480f2845 0 1709986378457 10 connected
    a799a8c4e709eea899b186163d068eb8637bf1ab 172.17.0.5:8900@18900 myself,master - 0 1709986378000 1 connected 0-5460
    bdacb0a18f092f814c92e87444f2c363c48486a1 172.17.0.6:8901@18901 slave 184a44ad4883cb7a4bf1852340a413f24931400a 0 1709986377554 8 connected
    c4d671d53518db7d41c1d3db15f9a56f480f2845 172.17.0.10:8905@18905 master - 0 1709986377053 10 connected 5461-10922

（3）docker logs  
也可以通过查看容器的日志来查看集群配置信息，只是看起来有点杂乱。

1:C 09 Mar 2024 11:08:28.465 # WARNING: Changing databases number from 16 to 1 since we are in cluster mode
    1:C 09 Mar 2024 11:08:28.465 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
    1:C 09 Mar 2024 11:08:28.465 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
    1:C 09 Mar 2024 11:08:28.465 * Redis version=7.2.4, bits=64, commit=00000000, modified=0, pid=1, just started
    1:C 09 Mar 2024 11:08:28.465 * Configuration loaded
    1:M 09 Mar 2024 11:08:28.465 * monotonic clock: POSIX clock_gettime
    1:M 09 Mar 2024 11:08:28.466 * Running mode=cluster, port=8900.
    1:M 09 Mar 2024 11:08:28.466 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
    1:M 09 Mar 2024 11:08:28.466 * No cluster configuration found, I'm a799a8c4e709eea899b186163d068eb8637bf1ab
    1:M 09 Mar 2024 11:08:28.483 * Server initialized
    1:M 09 Mar 2024 11:08:28.493 * Creating AOF base file appendonly.aof.1.base.rdb on server start
    1:M 09 Mar 2024 11:08:28.583 * Creating AOF incr file appendonly.aof.1.incr.aof on server start
    1:M 09 Mar 2024 11:08:28.583 * Ready to accept connections tcp
    1:M 09 Mar 2024 11:39:59.432 * configEpoch set to 1 via CLUSTER SET-CONFIG-EPOCH
    1:M 09 Mar 2024 11:39:59.489 * IP address for this node updated to 172.17.0.5
    1:M 09 Mar 2024 11:40:04.411 * Cluster state changed: ok
    1:M 09 Mar 2024 11:40:04.550 * Replica 172.17.0.7:8902 asks for synchronization
    1:M 09 Mar 2024 11:40:04.550 * Partial resynchronization not accepted: Replication ID mismatch (Replica asked for 'd49c5f6d07f4e8d3758b047ef307c00eaf889057', my replication IDs are 'bf40ebc4b012894cc0574dabd6dc0d69ab8520ca' and '0000000000000000000000000000000000000000')
    1:M 09 Mar 2024 11:40:04.550 * Replication backlog created, my new replication IDs are '2f71b44f909b7c9f29c0014135168d9111b3a3b3' and '0000000000000000000000000000000000000000'
    1:M 09 Mar 2024 11:40:04.550 * Delay next BGSAVE for diskless SYNC
    1:M 09 Mar 2024 11:40:09.740 * Starting BGSAVE for SYNC with target: replicas sockets
    1:M 09 Mar 2024 11:40:09.740 * Background RDB transfer started by pid 26
    26:C 09 Mar 2024 11:40:09.741 * Fork CoW for RDB: current 0 MB, peak 0 MB, average 0 MB
    1:M 09 Mar 2024 11:40:09.741 * Diskless rdb transfer, done reading from pipe, 1 replicas still up.
    1:M 09 Mar 2024 11:40:09.790 * Background RDB transfer terminated with success
    1:M 09 Mar 2024 11:40:09.790 * Streamed RDB transfer with replica 172.17.0.7:8902 succeeded (socket). Waiting for REPLCONF ACK from replica to enable streaming
    1:M 09 Mar 2024 11:40:09.790 * Synchronization with replica 172.17.0.7:8902 succeeded
    1:M 09 Mar 2024 11:43:11.568 # Cluster state changed: fail
    1:M 09 Mar 2024 11:43:16.053 * Marking node c4d671d53518db7d41c1d3db15f9a56f480f2845 () as failing (quorum reached).
    1:M 09 Mar 2024 11:43:16.053 * Marking node 61212f108d61cd69a9e7725b326f92be27949340 () as failing (quorum reached).
    1:M 09 Mar 2024 11:43:16.053 * Marking node 184a44ad4883cb7a4bf1852340a413f24931400a () as failing (quorum reached).
    1:M 09 Mar 2024 11:43:16.053 * Marking node 90bf16a87c85a4f11e54c128896be90be083ff25 () as failing (quorum reached).
    1:M 09 Mar 2024 11:43:16.363 * Clear FAIL state for node c4d671d53518db7d41c1d3db15f9a56f480f2845 ():replica is reachable again.
    1:M 09 Mar 2024 11:43:16.494 * Marking node bdacb0a18f092f814c92e87444f2c363c48486a1 () as failing (quorum reached).
    1:M 09 Mar 2024 11:43:17.115 * FAIL message received from 90bf16a87c85a4f11e54c128896be90be083ff25 () about c4d671d53518db7d41c1d3db15f9a56f480f2845 ()
    1:M 09 Mar 2024 11:43:17.522 * Clear FAIL state for node 184a44ad4883cb7a4bf1852340a413f24931400a ():replica is reachable again.
    1:M 09 Mar 2024 11:43:17.962 # Failover auth denied to 61212f108d61cd69a9e7725b326f92be27949340 (): its master is up
    1:M 09 Mar 2024 11:43:17.962 * Failover auth granted to c4d671d53518db7d41c1d3db15f9a56f480f2845 () for epoch 7
    1:M 09 Mar 2024 11:43:17.962 * Clear FAIL state for node 61212f108d61cd69a9e7725b326f92be27949340 ():replica is reachable again.
    1:M 09 Mar 2024 11:43:18.582 * Failover auth granted to 184a44ad4883cb7a4bf1852340a413f24931400a () for epoch 8
    1:M 09 Mar 2024 11:43:25.320 * FAIL message received from c4d671d53518db7d41c1d3db15f9a56f480f2845 () about 184a44ad4883cb7a4bf1852340a413f24931400a ()
    1:M 09 Mar 2024 11:43:25.649 * Clear FAIL state for node bdacb0a18f092f814c92e87444f2c363c48486a1 ():replica is reachable again.
    1:M 09 Mar 2024 11:43:26.053 * Clear FAIL state for node 90bf16a87c85a4f11e54c128896be90be083ff25 ():replica is reachable again.
    1:M 09 Mar 2024 11:43:26.621 * Failover auth granted to 90bf16a87c85a4f11e54c128896be90be083ff25 () for epoch 9
    1:M 09 Mar 2024 11:43:26.652 # Failover auth denied to bdacb0a18f092f814c92e87444f2c363c48486a1 (): already voted for epoch 9
    1:M 09 Mar 2024 11:43:28.290 * Clear FAIL state for node c4d671d53518db7d41c1d3db15f9a56f480f2845 ():replica is reachable again.
    1:M 09 Mar 2024 11:43:35.721 * Clear FAIL state for node 184a44ad4883cb7a4bf1852340a413f24931400a (): is reachable again and nobody is serving its slots after some time.
    1:M 09 Mar 2024 11:43:35.722 * Cluster state changed: ok
    1:M 09 Mar 2024 11:45:34.514 * FAIL message received from 184a44ad4883cb7a4bf1852340a413f24931400a () about c4d671d53518db7d41c1d3db15f9a56f480f2845 ()
    1:M 09 Mar 2024 11:45:38.692 * Clear FAIL state for node c4d671d53518db7d41c1d3db15f9a56f480f2845 ():replica is reachable again.
    1:M 09 Mar 2024 11:54:53.487 * Marking node 61212f108d61cd69a9e7725b326f92be27949340 () as failing (quorum reached).
    1:M 09 Mar 2024 11:54:53.997 * Clear FAIL state for node 61212f108d61cd69a9e7725b326f92be27949340 ():replica is reachable again.
    1:M 09 Mar 2024 11:54:54.037 * FAIL message received from c4d671d53518db7d41c1d3db15f9a56f480f2845 () about 61212f108d61cd69a9e7725b326f92be27949340 ()
    1:M 09 Mar 2024 11:54:59.813 * Clear FAIL state for node 61212f108d61cd69a9e7725b326f92be27949340 ():replica is reachable again.
    1:M 09 Mar 2024 11:58:24.592 # Cluster state changed: fail
    1:M 09 Mar 2024 11:58:34.477 * Marking node 90bf16a87c85a4f11e54c128896be90be083ff25 () as failing (quorum reached).
    1:M 09 Mar 2024 11:58:34.546 * FAIL message received from 184a44ad4883cb7a4bf1852340a413f24931400a () about 61212f108d61cd69a9e7725b326f92be27949340 ()
    1:M 09 Mar 2024 11:58:34.546 * FAIL message received from 184a44ad4883cb7a4bf1852340a413f24931400a () about bdacb0a18f092f814c92e87444f2c363c48486a1 ()
    1:M 09 Mar 2024 11:58:34.546 * FAIL message received from 184a44ad4883cb7a4bf1852340a413f24931400a () about c4d671d53518db7d41c1d3db15f9a56f480f2845 ()
    1:M 09 Mar 2024 11:58:35.097 * Clear FAIL state for node c4d671d53518db7d41c1d3db15f9a56f480f2845 ():replica is reachable again.
    1:M 09 Mar 2024 11:58:35.796 * Failover auth granted to c4d671d53518db7d41c1d3db15f9a56f480f2845 () for epoch 10
    1:M 09 Mar 2024 11:58:36.497 * Clear FAIL state for node 61212f108d61cd69a9e7725b326f92be27949340 ():replica is reachable again.
    1:M 09 Mar 2024 11:58:36.796 * Clear FAIL state for node bdacb0a18f092f814c92e87444f2c363c48486a1 ():replica is reachable again.
    1:M 09 Mar 2024 11:58:37.097 * Clear FAIL state for node 90bf16a87c85a4f11e54c128896be90be083ff25 ():replica is reachable again.
    1:M 09 Mar 2024 11:58:39.505 * Cluster state changed: ok

这个命令就可以看到从机接入的时刻和容器启动的时刻。

### 4.4、写入数据 ###

在写入数据时，我们需要回忆起一个东西，就是上面提到的`Key的分布式模型`。  
当Redis集群创建好之后，我们可以再查看集群信息的时候看到Slot的分区情况：

Master[0] -> Slots 0 - 5460
    Master[1] -> Slots 5461 - 10922
    Master[2] -> Slots 10923 - 16383

三个主节点将`16384`个Slot平均分配。  
当我们写入数据的时候，Redis会根据`Hash_Slot = CRC16(key) % 16384`这个方式将keyName分配到对应的主节点上，如果数据没有分配到当前节点上，则会进行`重定向`到集群中对应的机器上。

#### 4.4.1、写入时报错 ####

当我们通过`redis-cli`命令连接Redis服务器，在插入数据时，可能会出现以下错误：

127.0.0.1:8900> set name zhangsan
    (error) MOVED 5798 172.17.0.10:8905

这是因为我们使用`redis-cli`命令连接Redis服务器的时候使用的是以下语句：

redis-cli 192.168.240.3 -p 8900

使用这种方式是不会进行重定向的，需要使用以下的命令进行连接Redis服务器：

redis-cli 192.168.240.3 -p 8900 -c

#### 4.4.2、正常写入 ####

（1）通过Redis分布式Key的计算分配在本机上：

redis> set name zhangsan
    OK

（2）没有分配到本机上需要进行重定向：

redis> set name lisi
    -MOVED 5930 192.168.240.3:8901

5930表示是`192.168.240.3:8901`这台主机上的Slot槽，所以这就被重定向到了`192.168.240.3:8901`这台主机上。

[Redis 7.0]: https://blog.csdn.net/qq_45515182/article/details/136491470?spm=1001.2014.3001.5501
[c054c5a1d5534391a4e55869029b2c68.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/28/d3fd8514bf9a4732b6b1e77405b4e8aa.png
[85bf56ee28724db49c18fa46a82716db.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/28/54739117823d48f6ab164770d2442577.png
[Windows_Docker]: https://blog.csdn.net/qq_45515182/article/details/135464708?spm=1001.2014.3001.5501