Redis搭建教程

前言：搭建环境说明

本文所有操作均基于 CentOS 7.9 64 位 操作系统，Redis 版本统一采用 5.0.3（稳定版）。

一、Redis 单节点架构搭建

（一）安装准备与环境配置

Redis 是基于 C 语言开发的，因此在编译 Redis 源码之前，需要确保系统中已经安装了 GCC 环境gcc --version。如果尚未安装，可以通过包管理器进行安装，例如在 CentOS 系统中，执行命令yum install -y gcc。

完成 GCC 环境安装后，从 Redis 官方网站下载指定版本的 Redis 安装包，。我们使用的是redis-5.0.3.tar.gz，使用以下命令进行下载解压：

wget https://download.redis.io/releases/redis-5.0.3.tar.gz
tar -zxvf redis-5.0.3.tar.gz

解压完成后，进入解压后的目录，执行编译命令：

cd redis-5.0.3
make

编译成功后，通过make install命令安装 Redis，并且可以使用PREFIX参数指定安装路径，例如将其安装到/home/soft/redis/redis-5.0.3目录下：

make install PREFIX=/home/soft/redis/redis-5.0.3

为了在任意目录下都能方便地执行 Redis 命令，可以创建软链接：

ln -s /home/soft/redis/redis-5.0.3/src/redis-server /usr/bin/redis-server
ln -s /home/soft/redis/redis-5.0.3/src/redis-cli /usr/bin/redis-cli

（二）配置文件初始化

在 Redis 安装目录下，复制默认的配置文件redis.conf，并进行必要的参数修改。

# 进入reids目录
cd /home/soft/redis/redis-5.0.3
# 在redis目录下创建一个config文件夹，后续我们的redis主从、集群等配置全部放在这里
mkdir config
# 复制redis.conf到config目录中，原config文件可以保留做备份
cp redis.conf config/redis.conf

在redis.conf文件中，修改以下关键参数：

后台运行：将daemonize no改为daemonize yes，使 Redis 以守护进程的方式在后台运行，这样即使关闭终端，Redis 服务也不会停止。
端口设置：默认端口为6379，如果需要修改，可以调整port 6379这一行的端口号。
关闭保护模式：protected‐mode no #关闭保护模式，开启的话，只有本机才可以访问redis
注释bind配置：#bind 127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户端通过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可）
密码配置（可选）：为了增强安全性，可以设置访问密码。找到requirepass字段，去掉注释并设置密码，如requirepass your_password，将your_password替换为实际的密码。
持久化配置：推荐启用 AOF（Append Only File）持久化方式，将appendonly no改为appendonly yes。AOF 持久化会将写操作追加到文件末尾，相比 RDB（Redis Database）快照方式，能更好地保证数据的完整性和一致性，在系统故障恢复时可以最大限度地减少数据丢失。

（三）启动与验证

通过以下命令启动 Redis 服务：

redis-server /home/soft/redis/redis-5.0.3/config/redis.conf

启动成功后，可以使用 Redis 客户端进行连接和测试。执行命令：

redis-cli -h 127.0.0.1 -p 6379 -a your_password

其中，-h指定 Redis 服务器的 IP 地址，-p指定端口号，-a后面跟上之前设置的密码（如果未设置密码，则不需要-a参数）。连接成功后，就可以进行基本的操作测试，例如：

set key1 value1  # 设置键值对
get key1  # 获取键对应的值，应该返回"value1"

为了验证持久化是否生效，可以先通过set命令设置一些数据，然后停止 Redis 服务，再重新启动，使用get命令获取之前设置的数据，如果能成功获取，说明持久化配置成功，数据已经通过 RDB 或 AOF 文件成功恢复。停止 Redis 服务的命令是在 Redis 客户端中执行shutdown，或者使用kill命令终止 Redis 进程。

二、Redis 主从架构搭建

（一）单机多端口模拟集群（生产环境建议分机部署）

为了搭建 Redis 主从架构，首先在单机上通过多端口模拟集群环境。在生产环境中，建议将主从节点部署在不同的物理机上，以提高系统的可靠性和性能。这里先在本地通过创建不同的配置文件来模拟多个 Redis 节点。例如 Redis 安装目录为/home/soft/redis/redis-5.0.3，我们在该目录下创建了config文件夹方便统一管理配置文件，然后再config目录下创建redis-master.conf（主节点配置文件）、redis-slave1.conf和redis-slave2.conf（从节点配置文件）。

复制默认的redis.conf 文件到config/redis-master.conf 、 config/redis-slave1.conf、config/redis-slave2.conf主从架构的配置在单节点的基础上增加了几个配置：

后台运行：将daemonize no改为daemonize yes，使 Redis 以守护进程的方式在后台运行，这样即使关闭终端，Redis 服务也不会停止。
端口设置：默认端口为6379，主从架构我们多个实例需要修改为不同的端口。
关闭保护模式：protected‐mode no #关闭保护模式，开启的话，只有本机才可以访问redis
注释bind配置：#bind 127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户端通过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可）
密码配置（可选）：为了增强安全性，可以设置访问密码。找到requirepass字段，去掉注释并设置密码，如requirepass your_password，将your_password替换为实际的密码。
持久化配置：推荐启用 AOF（Append Only File）持久化方式，将appendonly no改为appendonly yes。AOF 持久化会将写操作追加到文件末尾，相比 RDB（Redis Database）快照方式，能更好地保证数据的完整性和一致性，在系统故障恢复时可以最大限度地减少数据丢失。
pid目录修改：pidfile /var/run/redis_6380.pid 因为我们在同一台机器上运行多个实例，所以这里pid的目录修改为不同的文件，比如由原来的6379改为6390.pid
日志目录设置：logfile "6380.log" 默认不记录日志，这里区分多个实例的日志目录
数据目录设置：dir /home/soft/redis/redis‐5.0.3/data/6380 指定数据存放目录，按照端口号区分不同目录，手动创建data/6380目录
主从配置：replicaof 172.18.254.66 6379 从本机6379的redis实例复制数据replica‐read‐only yes 配置从节点只读。只有从节点需要此配置

（二）启动从节点与状态检查

配置完成后，依次启动主节点和从节点服务。在命令行中执行：

[root@izb0wfpsng1vayz redis-5.0.3]# redis-server config/redis-master.conf 
[root@izb0wfpsng1vayz redis-5.0.3]# redis-server config/redis-slave1.conf 
[root@izb0wfpsng1vayz redis-5.0.3]# redis-server config/redis-slave2.conf 
[root@izb0wfpsng1vayz redis-5.0.3]# ps -ef | grep redis
root      5944     1  0 14:27 ?        00:00:00 redis-server *:6379
root      5949     1  0 14:27 ?        00:00:00 redis-server *:6380
root      5955     1  0 14:27 ?        00:00:00 redis-server *:6381
root      5961   962  0 14:27 pts/0    00:00:00 grep --color=auto redis

启动成功后，可以通过 Redis 客户端来检查主从节点的状态。连接到主节点客户端，执行info replication命令，应显示类似如下信息：

# Replication
role:master
connected_slaves:2
slave0:ip=172.18.254.66,port=6380,state=online,offset=112,lag=0
slave1:ip=172.18.254.66,port=6381,state=online,offset=112,lag=1
master_replid:0139224c5ae4431f024dc13e0d9af6f62d26ea96
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:112
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:112

从上述信息中可以看到，role为master，表示当前节点是主节点，connected_slaves表示连接的从节点数量及相关信息。

接着连接到从节点客户端，执行info replication命令，可看到类似如下信息：

# Replication
role:slave
master_host:172.18.254.66
master_port:6379
master_link_status:up
master_last_io_seconds_ago:9
master_sync_in_progress:0
slave_repl_offset:182
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:0139224c5ae4431f024dc13e0d9af6f62d26ea96
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:182
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:182

这里role为slave，表示当前节点是从节点，master_host和master_port显示了主节点的地址和端口，master_link_status为up表示与主节点连接正常。此外，在主节点上执行写操作，如set key1 value1，然后在从节点上执行get key1，应该能获取到相同的值value1，这表明从节点成功同步了主节点的数据。

（三）手动故障转移（主节点宕机场景）

当主节点发生宕机时，为了保证系统的可用性，需要将从节点手动提升为主节点。假设主节点（端口 6379）宕机，先通过命令行停止主节点服务（如果是意外宕机则跳过此步骤）：

redis-cli -h 172.18.254.66 -p 6379 shutdown

然后选择一个从节点（例如端口 6380 的从节点），将其提升为主节点，执行命令：

redis-cli -h 172.18.254.66 -p 6380 replicaof no one

执行上述命令后，该从节点就变成了新的主节点。此时，其他从节点（如端口 6381 的从节点）需要重新配置，使其指向新的主节点，执行命令：

redis-cli -h 172.18.254.66 -p 6381 replicaof 172.18.254.66 6380

经过这样的配置，在主节点宕机的情况下，系统依然可以正常提供服务，实现了一定程度的高可用性。当原主节点恢复后，需要重新配置其为新主节点的从节点，以恢复完整的主从集群结构。执行命令：

redis-cli -h 172.18.254.66 -p 6379 replicaof 172.18.254.66 6380

这样，原主节点重新成为新主节点的从节点，整个集群恢复正常状态。在实际生产环境中，为了实现自动故障转移，可以引入 Redis Sentinel 机制，它能够自动监控主从节点的状态，当主节点出现故障时自动进行故障转移，无需手动干预。

三、Redis 哨兵集群架构搭建

（一）哨兵配置文件编写

在 Redis 安装目录下，有默认的哨兵配置文件sentinel.conf，拷贝到config目录中进行统一管理。修改配置文件的核心内容如下：

后台运行：将daemonize no改为daemonize yes，使哨兵以守护进程的方式在后台运行。
端口设置：默认端口为26379，哨兵架构我们多个哨兵实例需要修改为不同的端口。
pid目录修改：pidfile /var/run/redis-sentinel-26379.pid
日志目录设置：logfile "26379.log"
数据目录设置：dir /home/soft/redis/redis-5.0.3/data/sentinel/26379
哨兵配置：sentinel monitor mymaster 172.18.254.66 6379 2 这里指定主节点的ip和端口，2表示当有2个哨兵认为master失效时master才算真正的失效。mymaster这个名字随便取，客户端访问时会用到

哨兵配置中的quorum（配置中的 2）是一个关键参数，它决定了判定主节点客观下线并进行故障转移所需的最少哨兵节点数。例如，若有 3 个哨兵节点，quorum设置为 2，那么当至少 2 个哨兵节点都认为主节点主观下线时，主节点才会被判定为客观下线，进而触发故障转移流程。同时，down-after-milliseconds参数用于控制哨兵对节点健康状态检测的敏感度，设置过短可能会因网络波动等短暂异常而误判节点下线，设置过长则可能导致故障发现和转移的延迟增加。

（二）启动哨兵与集群监控

配置完成后，通过以下命令启动哨兵：

cd /home/soft/redis/redis-5.0.3
./src/redis-sentinel ./config/sentinel-26379.conf
./src/redis-sentinel ./config/sentinel-26380.conf
./src/redis-sentinel ./config/sentinel-26381.conf

启动成功后，查看哨兵日志文件（/home/soft/redis/redis-5.0.3/data/sentinel/26379/26379.log），如果看到类似如下信息表示启动成功：

oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
Redis version=5.0.3, bits=64, commit=00000000, modified=0, pid=6146, just started
Configuration loaded
Running mode=sentinel, port=26379.
WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
Sentinel ID is ab33e4c1c68ea25277aa536fcb23f0bd6ac34f0a
+monitor master mymaster 172.18.254.66 6379 quorum 2

如果通过ps -ef|grep redis-sentinel 命令没有找到对应的进程，哨兵可能启动失败，我们可以在执行命令的目录下查看哨兵启动的日志文件，排查错误原因。

我们可以使用redis-cli连接到哨兵，执行命令查看集群状态：

redis-cli -p 26379
127.0.0.1:26379> SENTINEL masters

该命令会返回被监控的主节点信息，包括主节点的 IP、端口、状态、从节点数量等。为了模拟主节点宕机场景，停止主节点服务：

redis-cli -p 6379 shutdown

观察哨兵日志和SENTINEL masters命令的输出，可以看到哨兵会自动检测到主节点下线，并开始选举新的主节点。新的主节点会从从节点中选出，被选中的从节点会被提升为主节点，其他从节点会重新配置，指向新的主节点。当原主节点恢复后，哨兵会自动将其设置为新主节点的从节点，实现集群的自动恢复和高可用性。

（三）高可用性验证

Redis 哨兵集群通过 “主观下线” 和 “客观下线” 机制来确保对主节点状态判断的准确性，避免误判。当一个哨兵节点在down-after-milliseconds设置的时间内未收到主节点的响应时，会将主节点标记为 “主观下线”，但此时并不会立即进行故障转移。只有当超过quorum配置数量的哨兵节点都认为主节点主观下线时，主节点才会被判定为 “客观下线”，从而触发故障转移流程。在故障转移过程中，哨兵会按照一定的规则选择新的主节点。首先，会过滤掉处于连接失败、响应超时等不健康状态的从节点。然后，优先选择slave-priority配置值最小的从节点（slave-priority默认值为 100，值越小优先级越高）作为新主节点。如果多个从节点的slave-priority相同，则选择与原主节点复制偏移量最大的从节点，即数据最完整的从节点。通过这样的机制，Redis 哨兵集群能够在主节点出现故障时，快速、自动地完成故障转移，确保整个 Redis 集群的高可用性，最大程度减少因节点故障导致的服务中断时间，保障业务系统的稳定运行。

四、Redis 集群架构搭建

（一）集群节点规划（3 主 3 从示例）

在搭建 Redis 集群时，首先需要进行节点规划。这里以 3 主 3 从的架构为例进行说明。假设使用 6 台服务器或在单机上通过不同端口模拟 6 个节点，节点端口分别为 7000 - 7005。我们在刚刚安装的redis的/home/soft/redis/redis-5.0.3/config 目录下新建对应redis节点的配置文件夹，比如：mkdir -p /home/soft/redis/redis-5.0.3/config/cluster/7000 创建7000-7005 六个文件夹保存六个节点的配置文件。

对于每个节点，需要修改其对应的 Redis 配置文件。以端口为 7000 的节点为例，在redis.conf文件中添加或修改以下关键配置：

后台运行：将daemonize no改为daemonize yes
端口设置：默认端口为6379，我们修改为对应6个redis节点的端口。
pid目录修改：pidfile /var/run/redis_7000.pid 修改对应端口的pid
日志目录设置：logfile "7000.log"
数据目录设置：dir /home/soft/redis/redis-5.0.3/data/cluster/7000 指定数据文件存放位置，必须要指定不同的目录位置，不然会丢失数据。提前创建好对应的目录。
启动集群模式：cluster-enabled yes
集群节点信息配置：cluster-config-file nodes-7000.conf 配置文件名最好和端口一致
集群节点超时配置：cluster‐node‐timeout 10000 设置节点超时时间为10000毫秒，超过该时间未收到节点响应，则认为节点故障
注释bind配置：#bind 127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户端通过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可）
关闭保护模式：protected‐mode no
开启AOF持久化：appendonly yes
设置Redis访问密码：requirepass 123456
设置集群节点间访问密码：masterauth 123456

同样地，对于其他节点（7001 - 7005），只需将上述配置中的端口号和配置文件名（如nodes-7001.conf、nodes-7002.conf等）相应修改即可。另外，还可以根据实际需求，添加如bind指定绑定的 IP 地址、port设置监听端口、daemonize设置是否以守护进程方式运行、logfile指定日志文件路径、dir指定数据文件存储目录等常规配置。

# 拷贝配置文件到对应的目录中
cp 7000/redis.conf 7001/redis.conf
# 编辑7001目录下的配置，批量替换7000为7001
vim 7001/redis.conf
# 在vim命令的命令模式下执行替换
:%s/7000/7001/g

（二）初始化集群与槽位分配

分别启动6个redis实例，检查是否启动成功

redis-server config/cluster/7000/redis.conf
ps -ef | grep redis

当所有节点的配置完成并启动后，通过redis - cli --cluster命令来初始化集群并进行槽位分配。假设 6 个节点的 IP 地址均为127.0.0.1，执行以下命令：

redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1 -a 123456

上述命令中，--cluster-replicas 1表示为每个主节点分配一个从节点。如果redis节点在不同机器上，执行这条命令需要确认每个redis节点的机器之间的redis实例要能相互访问，可以先简单把所有机器防火墙关掉，如果不关闭防火墙则需要打开redis服务端口和集群节点gossip通信端口17000(默认是在redis端口号上加1W)。

执行该命令后，Redis 会自动进行槽位分配，将 16384 个哈希槽均匀分配到 3 个主节点上。例如，可能的分配结果为：节点 7000 负责 0 - 5460 号槽，节点 7001 负责 5461 - 10922 号槽，节点 7002 负责 10923 - 16383 号槽。同时，从节点会自动关联到对应的主节点，形成 3 主 3 从的集群架构。在分配槽位时，Redis 使用 CRC16 算法对键进行哈希计算，然后对 16384 取模，以确定键属于哪个槽，即HASH_SLOT = CRC16(key) % 16384 。这种分配方式确保了数据能够均匀分布在各个主节点上，实现了集群的数据分片和负载均衡。

集群创建成功的输出结果如下：

（三）集群验证

连接 Redis 集群客户端，可以使用redis - cli - c命令，其中-c参数表示以集群模式连接。例如：

redis-cli -c -h 127.0.0.1 -p 7000 -a 123456

连接成功后，就可以进行数据操作。当写入数据时，如执行set key1 value1，Redis 会根据key1的哈希值计算出对应的槽位，并自动将请求重定向到负责该槽位的节点上进行处理。如果当前连接的节点不是目标节点，Redis 客户端会收到重定向响应，自动连接到正确的节点完成操作。

通过cluster info命令可以查看集群的整体状态，包括集群状态（cluster_state，如ok表示正常）、已分配的槽位数（cluster_slots_assigned）、正常的槽位数（cluster_slots_ok）、疑似故障的槽位数（cluster_slots_pfail）、故障的槽位数（cluster_slots_fail）、已知的节点数（cluster_known_nodes）等信息。例如：

127.0.0.1:7000> 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:352
cluster_stats_messages_pong_sent:361
cluster_stats_messages_sent:713
cluster_stats_messages_ping_received:356
cluster_stats_messages_pong_received:352
cluster_stats_messages_meet_received:5
cluster_stats_messages_received:713

使用cluster nodes命令可以查看集群中各个节点的详细信息，包括节点 ID、IP 地址、端口、节点角色（master或slave）、连接状态、负责的槽位范围等。例如：

127.0.0.1:7000> cluster nodes
99eb805908717f8941ce453fcb0ae721a86e8969 127.0.0.1:7000@17000 myself,master - 0 1756804357000 1 connected 0-5460
af83187c1105c6e1f483f66076aadd2ceaced643 127.0.0.1:7005@17005 slave 99eb805908717f8941ce453fcb0ae721a86e8969 0 1756804360445 6 connected
ff143309f612e7d8d75fb0ba77d3f11ba1805923 127.0.0.1:7004@17004 slave f83af0d4fe2f9103e31ef5d2031d38992574dd3f 0 1756804359443 5 connected
65c1bba7b6c98d8256e013ca4df762987cecb597 127.0.0.1:7001@17001 master - 0 1756804358000 2 connected 5461-10922
f83af0d4fe2f9103e31ef5d2031d38992574dd3f 127.0.0.1:7002@17002 master - 0 1756804359000 3 connected 10923-16383
26ab0783649aabad324e1ed2fdb0bf5d615ffaf7 127.0.0.1:7003@17003 slave 65c1bba7b6c98d8256e013ca4df762987cecb597 0 1756804359000 4 connected

（四）水平扩展

Redis 集群还支持动态添加 / 删除节点与重新分片操作。添加节点时，可以使用redis - cli --cluster add - node命令，将新节点加入集群。例如，我们按照上述步骤新创建一个7006的reids节点，然后加入到原集群中，可以执行：

redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:7000 -a 123456

其中，127.0.0.1:7000是集群中已有的一个节点，用于引导新节点加入集群。

这时我们登录7000节点的客户端，查看集群节点信息，可以看到7006节点已经正确添加，但是并没有分配槽位，所以我们还需要重新分配槽位。

可以使用redis-cli --cluster reshard命令。该命令会引导用户交互式地进行槽位迁移，将指定数量的槽从一个或多个源节点迁移到目标节点，以实现集群的负载均衡或节点扩展 / 收缩。例如，将节点 7000 上的 4500 个槽迁移到新添加的节点 7006 上，可以执行：

redis-cli --cluster reshard 127.0.0.1:7006 -a 123456

按照提示输入源节点 ID（这里是 7000 的节点 ID）、目标节点 ID（7006 的节点 ID）和要迁移的槽数量（4500），即可完成槽位迁移。通过这些操作，Redis 集群能够灵活地适应业务需求的变化，实现高效的数据存储和处理。

[root@izb0wfpsng1vayz redis-5.0.3]# redis-cli --cluster reshard 127.0.0.1:7006 -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
>>> Performing Cluster Check (using node 127.0.0.1:7006)
M: f3866fc1715f1ed769ddd037a5ac84ceacb7c9e0 127.0.0.1:7006
   slots: (0 slots) master
M: 99eb805908717f8941ce453fcb0ae721a86e8969 127.0.0.1:7000
   slots:[0-5460] (5461 slots) master
   1 additional replica(s)
S: af83187c1105c6e1f483f66076aadd2ceaced643 127.0.0.1:7005
   slots: (0 slots) slave
   replicates 99eb805908717f8941ce453fcb0ae721a86e8969
S: ff143309f612e7d8d75fb0ba77d3f11ba1805923 127.0.0.1:7004
   slots: (0 slots) slave
   replicates f83af0d4fe2f9103e31ef5d2031d38992574dd3f
M: f83af0d4fe2f9103e31ef5d2031d38992574dd3f 127.0.0.1:7002
   slots:[10923-16383] (5461 slots) master
   1 additional replica(s)
M: 65c1bba7b6c98d8256e013ca4df762987cecb597 127.0.0.1:7001
   slots:[5461-10922] (5462 slots) master
   1 additional replica(s)
S: 26ab0783649aabad324e1ed2fdb0bf5d615ffaf7 127.0.0.1:7003
   slots: (0 slots) slave
   replicates 65c1bba7b6c98d8256e013ca4df762987cecb597
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
# 需要迁移的槽位数量，我们输入4500
How many slots do you want to move (from 1 to 16384)? 4500
# 需要把这4500个槽位迁移到哪个节点上去？我们输入7006节点的id
What is the receiving node ID? f3866fc1715f1ed769ddd037a5ac84ceacb7c9e0
# 需要从哪些节点的槽位迁移到7006，我们输入all
Please enter all the source node IDs.
  Type 'all' to use all the nodes as source nodes for the hash slots.
  Type 'done' once you entered all the source nodes IDs.
Source node #1: all
# 下面就会执行槽位迁移,准备迁移4500个槽位，source为原有的三个主节点，destination为新加的7006节点
Ready to move 4500 slots.
  Source nodes:
    M: 99eb805908717f8941ce453fcb0ae721a86e8969 127.0.0.1:7000
       slots:[0-5460] (5461 slots) master
       1 additional replica(s)
    M: f83af0d4fe2f9103e31ef5d2031d38992574dd3f 127.0.0.1:7002
       slots:[10923-16383] (5461 slots) master
       1 additional replica(s)
    M: 65c1bba7b6c98d8256e013ca4df762987cecb597 127.0.0.1:7001
       slots:[5461-10922] (5462 slots) master
       1 additional replica(s)
  Destination node:
    M: f3866fc1715f1ed769ddd037a5ac84ceacb7c9e0 127.0.0.1:7006
       slots: (0 slots) master
  Resharding plan:

如果我们想要为7006添加一个从节点7007，可以按照上述操作先将7007加入到集群中，这时7007默认是一个主节点，并且没有分配槽位，我们只需要登录到7007节点，然后执行下面这行命令，将7007配置为7006的从节点即可。

# 登录7007节点
[root@izb0wfpsng1vayz redis-5.0.3]# redis-cli -p 7007 -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
# 查看集群节点信息，此时7007是一个主节点，没有分配槽位
127.0.0.1:7007> cluster nodes
99eb805908717f8941ce453fcb0ae721a86e8969 127.0.0.1:7000@17000 master - 0 1756805935000 1 connected 1499-5460
ff143309f612e7d8d75fb0ba77d3f11ba1805923 127.0.0.1:7004@17004 slave f83af0d4fe2f9103e31ef5d2031d38992574dd3f 0 1756805936959 3 connected
f83af0d4fe2f9103e31ef5d2031d38992574dd3f 127.0.0.1:7002@17002 master - 0 1756805936000 3 connected 12422-16383
b47680bc4f777c78691ffe2ddd4bf48874b860bd 127.0.0.1:7007@17007 myself,master - 0 1756805932000 0 connected
af83187c1105c6e1f483f66076aadd2ceaced643 127.0.0.1:7005@17005 slave 99eb805908717f8941ce453fcb0ae721a86e8969 0 1756805935000 1 connected
f3866fc1715f1ed769ddd037a5ac84ceacb7c9e0 127.0.0.1:7006@17006 master - 0 1756805935000 7 connected 0-1498 5461-6961 10923-12421
65c1bba7b6c98d8256e013ca4df762987cecb597 127.0.0.1:7001@17001 master - 0 1756805935956 2 connected 6962-10922
26ab0783649aabad324e1ed2fdb0bf5d615ffaf7 127.0.0.1:7003@17003 slave 65c1bba7b6c98d8256e013ca4df762987cecb597 0 1756805935000 2 connected
# 将7007设置为7006的从节点。后面的id是7006的节点id
127.0.0.1:7007> cluster replicate f3866fc1715f1ed769ddd037a5ac84ceacb7c9e0
OK
# 重新查看节点信息，7007已经是一个从节点
127.0.0.1:7007> cluster nodes
99eb805908717f8941ce453fcb0ae721a86e8969 127.0.0.1:7000@17000 master - 0 1756805968032 1 connected 1499-5460
ff143309f612e7d8d75fb0ba77d3f11ba1805923 127.0.0.1:7004@17004 slave f83af0d4fe2f9103e31ef5d2031d38992574dd3f 0 1756805968000 3 connected
f83af0d4fe2f9103e31ef5d2031d38992574dd3f 127.0.0.1:7002@17002 master - 0 1756805967000 3 connected 12422-16383
b47680bc4f777c78691ffe2ddd4bf48874b860bd 127.0.0.1:7007@17007 myself,slave f3866fc1715f1ed769ddd037a5ac84ceacb7c9e0 0 1756805966000 0 connected
af83187c1105c6e1f483f66076aadd2ceaced643 127.0.0.1:7005@17005 slave 99eb805908717f8941ce453fcb0ae721a86e8969 0 1756805968000 1 connected
f3866fc1715f1ed769ddd037a5ac84ceacb7c9e0 127.0.0.1:7006@17006 master - 0 1756805968000 7 connected 0-1498 5461-6961 10923-12421
65c1bba7b6c98d8256e013ca4df762987cecb597 127.0.0.1:7001@17001 master - 0 1756805969034 2 connected 6962-10922
26ab0783649aabad324e1ed2fdb0bf5d615ffaf7 127.0.0.1:7003@17003 slave 65c1bba7b6c98d8256e013ca4df762987cecb597 0 1756805966000 2 connected

五、架构对比与生产环境建议

（一）选型参考

架构	优点	缺点	适用场景
单节点	简单易用，资源占用低	无高可用，单点故障	开发测试、小规模场景
主从架构	读写分离，数据备份	手动故障转移，主节点瓶颈	中等并发，需容灾
哨兵集群	自动故障转移，高可用	依赖哨兵节点稳定性	生产环境基础配置
集群架构	水平扩展，分布式存储	配置复杂，客户端需支持	大规模数据、高并发

（二）生产环境最佳实践

哨兵节点建议部署在独立服务器，避免与 Redis 节点共宿，这样可以减少资源竞争，提高整个系统的稳定性。当 Redis 节点出现高负载等情况时，不会影响哨兵节点对其状态的监控和故障转移操作；反之，哨兵节点的异常也不会直接导致 Redis 服务的中断。
集群模式需开启 appendonly yes 保证持久化，定期备份 RDB/AOF 文件。开启 AOF 持久化可以最大限度地保证数据的完整性，即使在系统故障时也能通过 AOF 文件进行数据恢复。定期备份 RDB/AOF 文件则是一种额外的数据保护措施，防止因文件损坏、误操作等原因导致数据丢失，以便在需要时能够从备份文件中快速恢复数据。
配置 protected-mode yes 限制外部访问，结合防火墙增强安全性。通过设置protected-mode yes，Redis 会限制非本地客户端的访问，只有在配置了正确的访问密码或者通过本地回环地址访问时才允许连接。再结合防火墙策略，只开放必要的 IP 地址和端口访问 Redis 服务，进一步增强系统的安全性，防止未经授权的访问和恶意攻击。

通过以上步骤，可完整搭建从基础单节点到高可用集群的 Redis 架构，满足不同业务场景的性能与稳定性需求。实际部署时需根据数据量、并发量及容灾要求选择合适方案，并持续监控节点状态与日志，确保集群高效运行。例如，可以使用 Redis 自带的INFO命令获取节点的运行状态信息，包括内存使用、连接数、主从同步状态等；结合监控工具如 Prometheus + Grafana 实现对 Redis 集群的实时监控和告警功能，及时发现并处理潜在的问题，保障业务系统的稳定运行。

前言：搭建环境说明​