Redis 主从复制，哨兵与集群

一.redis主从复制

1.redis 主从复制架构

2.主从复制特点

3.主从复制的基本原理

4.命令行配置

5.实现主从复制

6.删除主从复制

7.主从复制故障恢复

8.主从复制完整过程

9.主从同步优化配置

二.哨兵模式（Sentinel）

1.主要组件和概念

2.哨兵模式的工作原理

3.优点和适用场景

4.实现哨兵模式

三.集群（redis cluster）

1.架构特点

2.组成部分

3.工作流程

4.实现集群

虽然Redis可以实现单机的数据持久化，但无论是RDB也好或者AOF也好，都解决不了单点宕机问题，即一旦单台 redis服务器本身出现系统故障、硬件故障等问题后，就会直接造成数据的丢失

此外,单机的性能也是有极限的,因此需要使用另外的技术来解决单点故障和性能扩展的问题。

一.redis主从复制

1.redis 主从复制架构

主从模式（master/slave），可以实现Redis数据的跨主机备份。

程序端连接到高可用负载的VIP，然后连接到负载服务器设置的Redis后端real server，此模式不需要在程序里面配置Redis服务器的真实IP地址，当后期Redis服务器IP地址发生变更只需要更改redis 相应的后端real server即可，可避免更改程序中的IP地址设置。

2.主从复制特点

一个master可以有多个slave
一个slave只能有一个master
数据流向是从master到slave单向的

3.主从复制的基本原理

配置设置：

主节点（Master）：配置允许从节点连接，并记录所有数据变更（写操作）。
从节点（Slave）：配置连接到主节点，并接收主节点发送的数据副本。

复制流程：

主节点持续记录执行的写操作（包括SET、DEL等），并将这些写操作以命令的形式发送给所有连接的从节点。
从节点接收到这些命令并执行，以确保其数据与主节点保持同步。

初始化同步：

新的从节点在连接到主节点时，可以选择全量复制（将主节点的所有数据复制一份到从节点）或者部分复制（只复制从连接后的数据变更）。

心跳检测和重连：

主从节点之间通过心跳机制保持连接。如果从节点与主节点断开连接，它会尝试重新连接并请求同步缺失的数据。

读写分离：

从节点可以用于处理只读操作，以减轻主节点的负载。客户端可以选择性地连接到从节点进行读取操作，从而分担主节点的读取压力。

当配置Redis复制功能时，强烈建议打开主服务器的持久化功能。否则的话，由于延迟等问题，部署的主节点Redis服务应该要避免自动启动。

参考案例: 导致主从服务器数据全部丢失

1.假设节点A为主服务器，并且关闭了持久化。并且节点B和节点c从节点A复制数据
2.节点A崩溃，然后由自动拉起服务重启了节点A.由于节点A的持久化被关闭了，所以重启之后没有任何数据
3.节点B和节点c将从节点A复制数据，但是A的数据是空的，于是就把自身保存的数据副本删除。

在关闭主服务器上的持久化，并同时开启自动拉起进程的情况下，即便使用Sentinel来实现Redis的高可用性，也是非常危险的。因为主服务器可能拉起得非常快，以至于Sentinel在配置的心跳时间间隔内没有检测到主服务器已被重启，然后还是会执行上面的数据丢失的流程。无论何时，数据安全都是极其重要的，所以应该禁止主服务器关闭持久化的同时自动启动。

4.命令行配置

命令	解释
info replication	查看主从状态
repliacaof	添加主从配置例子： repliacaof 192.168.91.100 6379
CONFIG SET masterauth 123456	设置密码
REPLICAOF no one	取消主从配置

5.实现主从复制

主服务器：192.168.240.13

[root@localhost ~]#vim /etc/redis/6379.conf 
70 bind 0.0.0.0
#将监听端口改为任意端口
requirepass  12345
#设置密码
172 logfile /var/log/redis_6379.log
#指定日志文件目录
264 dir /var/lib/redis/6379
#指定工作目录
700 appendonly yes
#开启AOF持久化功能

从服务器：192.168.240.14

#安装redis略
#修改配置文件

70 bind 0.0.0.0
#将监听端口改为任意端口
172 logfile /var/log/redis_6379.log
#指定日志文件目录
264 dir /var/lib/redis/6379
#指定工作目录
288  replicaof 192.168.91.100 6379
#设置 主从配置
masterauth   123456
#如果有密码  设置此行

700 appendonly yes
#开启AOF持久化功能

5.1关闭防火墙和selinux

[root@localhost ~]# systemctl stop firewalld
[root@localhost ~]# setenforce 0

5.2 进入从的配置文件

 replicaof 192.168.240.13  6379
             #主服务器地址  #端口号
如果需要添加密码，在主服务器配置文件中添加密码
requirepass  a
在从服务器配置文件中加入
masterauth a

5.3 重新启动从服务器，并进入redis数据库查看主从状态

slave 状态只读无法写入数据

systemctl restart redis
redis-cli
127.0.0.1:6379> info replication

从服务器

role:slave
表示当前 Redis 服务器的角色是从服务器。

master_host:192.168.240.13
指定当前从服务器正在复制的主服务器的 IP 地址。

master_port:6379
指定当前从服务器正在复制的主服务器的端口号。

master_link_status:up
表示从服务器与主服务器之间的连接状态为正常（连接已建立）。

master_last_io_seconds_ago:8
指示从服务器上次与主服务器进行通信的时间，单位为秒，这里表示距离上次通信已经过去了8秒。

master_sync_in_progress:0
表示当前没有正在进行中的主从同步操作。

slave_repl_offset:24865
指示从服务器当前的复制偏移量，即从主服务器已经复制到的数据量。

slave_priority:100
从服务器的复制优先级，这里设置为100，表示当前从服务器在进行故障转移时的优先级。

slave_read_only:1
表示从服务器是否设置为只读模式，这里设置为1，表示从服务器不接受写操作。

connected_slaves:0
指示当前连接到该从服务器的从服务器数量，这里为0，表示该从服务器没有其他从服务器连接。

master_replid:9c941d96163ba330053c1cb212c8ab5af806adb4
主服务器的复制 ID，用于标识主服务器的唯一标识符。

master_replid2:0000000000000000000000000000000000000000
辅助用于复制的 ID，通常为 40 个零，表示在执行故障转移时用作附加标识。

master_repl_offset:24865
主服务器的复制偏移量，表示当前主服务器已经复制给从服务器的数据量。

second_repl_offset:-1
第二个复制偏移量，通常不使用，这里值为 -1。

repl_backlog_active:1
表示复制后备日志（replication backlog）是否处于活动状态（active），即是否正在使用。

repl_backlog_size:1048576
复制后备日志的大小，这里为 1048576 字节（1 MB），表示可用于复制的最大历史数据量。

repl_backlog_first_byte_offset:24796
复制后备日志的第一个字节的偏移量，表示第一个有效数据在复制后备日志中的位置。

repl_backlog_histlen:70
复制后备日志的历史长度，表示当前复制后备日志中存储的历史数据条目数。

主服务器

role:master

#表示当前 Redis 服务器的角色是主服务器。
connected_slaves:1

#表示当前连接的从服务器数量，这里有一个从服务器连接到了主服务器。
slave0:ip=192.168.240.14,port=6379,state=online,offset=24935,lag=1

#描述了从服务器的详细信息：
   ip=192.168.240.14,port=6379：从服务器的 IP 地址和端口号。
   state=online：从服务器的状态，这里是在线状态。
   offset=24935：从服务器当前复制的偏移量（offset），即从主服务器同步的数据偏移量。
   lag=1：从服务器与主服务器的复制延迟，即从服务器在处理复制数据时的滞后量（以秒为单位）。
master_replid:9c941d96163ba330053c1cb212c8ab5af806adb4

#主服务器的复制 ID，用于标识主服务器的唯一标识符。
master_replid2:0000000000000000000000000000000000000000

#辅助用于复制的 ID，通常为 40 个零，表示在执行故障转移时用作附加标识。
master_repl_offset:24935

#主服务器的复制偏移量，表示当前主服务器已经复制给从服务器的数据量。
second_repl_offset:-1

#第二个复制偏移量，通常不使用，这里值为 -1。
repl_backlog_active:1

#表示复制后备日志（replication backlog）是否处于活动状态（active），即是否正在使用。
repl_backlog_size:1048576

#复制后备日志的大小，这里为 1048576 字节（1 MB），表示可用于复制的最大历史数据量。
repl_backlog_first_byte_offset:24796

#复制后备日志的第一个字节的偏移量，表示第一个有效数据在复制后备日志中的位置。
repl_backlog_histlen:140

#复制后备日志的历史长度，表示当前复制后备日志中存储的历史数据条目数。

测试：

6.删除主从复制

在从服务器执行 REPLIATOF NO ONE 指令可以取消主从复制

#取消复制,在slave上执行REPLIATOF NO ONE,会断开和master的连接不再主从复制, 但不会清除slave
上已有的数据
127.0.0.1:6379> REPLICAOF no one

7.主从复制故障恢复

master故障后，只能手动提升一个slave为新master，不支持自动切换。

之后将其它的slave节点重新指定新的master为master节点

Master的切换会导致master_replid发生变化，slave之前的master_replid就和当前master不一致从而会引发所有 slave的全量同步。

8.主从复制完整过程

1）从服务器连接主服务器，发送PSYNC命令
2）主服务器接收到PSYNC命令后，开始执行BGSAVE命令生成RDB快照文件并使用缓冲区记录此后执行的所有
写命令
3）主服务器BGSAVE执行完后，向所有从服务器发送RDB快照文件，并在发送期间继续记录被执行的写命令
4）从服务器收到快照文件后丢弃所有旧数据，载入收到的快照至内存
5）主服务器快照发送完毕后,开始向从服务器发送缓冲区中的写命令
6）从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令
7）后期同步会先发送自己slave_repl_offset位置，只同步新增加的数据，不再全量同步

复制缓冲区配置参数

#复制缓冲区大小,建议要设置足够大
repl-backlog-size 1mb 

#Redis同时也提供了当没有slave需要同步的时候，多久可以释放环形队列：
repl-backlog-ttl   3600

9.主从同步优化配置

Redis在2.8版本之前没有提供增量部分复制的功能，当网络闪断或者slave Redis重启之后会导致主从之间的全量同步，即从2.8版本开始增加了部分复制的功能。

repl-diskless-sync:
功能: 控制是否使用无盘同步 RDB 文件。当设置为 yes 时，主服务器不会将 RDB 文件保存到磁盘上，而是直接通过 socket 文件发送给从服务器。
建议配置: 根据实际情况选择，如果希望减少磁盘 I/O 操作并且网络条件良好，可以考虑设置为 yes。

repl-diskless-sync-delay:
功能: 在使用无盘同步时，从服务器等待接收 RDB 数据的时间延迟。
建议配置: 默认值为 5 秒通常是一个合理的设置，可以根据网络延迟和从服务器的性能调整。

repl-ping-slave-period:
功能: 从服务器向主服务器发送 ping 的时间间隔，用于保持连接。
建议配置: 默认值为 10 秒通常是合适的，可以根据网络稳定性调整，不建议设置得太短以避免过多的网络开销。

repl-timeout:
功能: 设置主从连接的超时时间，超过此时间没有收到响应将认为连接断开。
建议配置: 默认值为 60 秒通常是合适的，可以根据网络环境和延迟进行微调。

repl-disable-tcp-nodelay:
功能: 控制是否启用 TCP_NODELAY。启用后可以减少网络带宽消耗，但可能会增加同步延迟。
建议配置: 根据数据的一致性要求和网络性能进行选择。通常选择 no，以确保数据同步的及时性和准确性。

repl-backlog-size:
功能: 主服务器用于保存复制数据的写入缓冲区大小。
建议配置: 根据从服务器断开连接后能容忍的最长时间和主服务器的写入速率来设置。建议按照需求调整，确保足够的缓冲区来支持断线重连时的数据传输。

repl-backlog-ttl:
功能: 如果一段时间后没有从服务器连接到主服务器，定义主服务器写入缓冲区的超时时间。建议配置: 根据系统的需求设置合适的时间，以免长时间未使用的资源占用内存。

slave-priority:
功能: 设置从服务器的优先级，用于在主服务器故障后选举新的主服务器。
建议配置: 如果有多个从服务器，可以设置不同的优先级以影响选举结果。

min-replicas-to-write:
功能: 设置主服务器至少需要多少个可用从服务器，否则拒绝执行写操作。
建议配置: 根据系统的容错需求进行设置，确保即使部分从服务器不可用也能保持系统的可写性。

min-slaves-max-lag:
功能: 当从服务器的复制延迟超过设定值时，主服务器不再接受写操作。
建议配置: 根据系统的性能和复制链路的稳定性设置合适的延迟阈值，以避免数据不一致性问题。

二.哨兵模式（Sentinel）

edis 哨兵模式是一种用于高可用性（High Availability, HA）的解决方案，它允许 Redis 在主从复制的基础上，提供自动故障恢复和故障转移的功能。主要用途是监控 Redis 实例，并在主节点失效时自动将一个从节点晋升为新的主节点，以保证服务的持续可用性。

1.主要组件和概念

哨兵（Sentinel）：

哨兵是一个运行在独立进程中的程序，其主要任务是监控 Redis 实例的状态（主节点和从节点），并在主节点失效时执行自动故障转移。

主节点（Master）：

Redis 中的主节点负责接收写操作，并将数据同步到所有从节点。

从节点（Slave）：

从节点是主节点的复制品，它们复制主节点的数据，并在需要时可以晋升为新的主节点。

2.哨兵模式的工作原理

哨兵模式包括多个哨兵进程和多个 Redis 节点（主节点和从节点）。哨兵进程定期检查 Redis 实例的健康状态，并在发现故障时采取自动化的措施。

监控：

每个哨兵进程会定期检查监控的 Redis 实例的健康状态，包括主节点和从节点。

故障检测：

如果一个哨兵进程发现主节点不可用（比如网络故障、进程崩溃等），它会开始执行一系列故障检测步骤，以确保主节点确实不可用。

选举新主节点：

当主节点被确认为不可用时，哨兵会通过一种投票机制选举一个从节点作为新的主节点。这个过程会考虑每个哨兵的优先级和配置，确保选举出的主节点具有一致性和可靠性。

故障转移：

一旦新的主节点被选出，哨兵会协调所有的 Redis 客户端和其他哨兵，使它们知道新的主节点的位置。这个过程称为故障转移（failover），通常会在几秒钟内完成。

配置同步：

新的主节点上任后，哨兵还会确保所有从节点正确地重新配置为新的主节点的从节点，并开始从新的主节点同步数据。

3.优点和适用场景

自动化的高可用性：哨兵模式使得 Redis 集群在主节点故障时可以自动化地完成故障转移，减少了人工介入和服务中断的可能性。
实时监控和通知：哨兵可以实时监控 Redis 的健康状况，并在必要时通过警报或通知管理员进行干预。
简化扩展和维护：通过自动处理故障转移，哨兵模式简化了 Redis 集群的扩展和维护工作。

4.实现哨兵模式

哨兵的前提是已经实现了一个redis的主从复制的运行环境，从而实现一个一主两从基于哨兵的高可用

redis架构

注意: master 的配置文件中masterauth 和slave 都必须相同

所有主从节点的redis.conf中关健配置

主服务器：192.168.240.13 端口：6379 哨兵1

从服务器1：192.168.240.14 端口：6379 哨兵2

从服务器2：192.168.240.12 端口：6379 哨兵3

1）关闭防火墙关闭selinux

[root@localhost ~]# systemctl stop firewalld
[root@localhost ~]# setenforce 0

2）配置主从复制

3）编辑哨兵的配置文件

sentinel配置

Sentinel实际上是一个特殊的redis服务器,有些redis指令支持,但很多指令并不支持.默认监听在26379/tcp端口.

哨兵可以不和Redis服务器部署在一起，但一般部署在一起以节约成本

所有redis节点使用相同的以下示例的配置文件

[root@localhost redis-5.0.7]# cp sentinel.conf   /apps/redis/etc/
[root@localhost redis-5.0.7]# vim /apps/redis/etc/sentinel.conf
bind 0.0.0.0   #修改监听端口 
port 26379     #不用修改默认
daemonize yes  # 不用修改如果是systemd 启动模式， 修改后启动不了
pidfile "/apps/resdis/run/redis-sentinel.pid"  #指定pid文件
logfile "/apps/redis/log/sentinel_26379.log"  # 指定日志文件
dir "/tmp"  #工作目录不用修改

sentinel monitor mymaster 10.0.0.8 6379 2
#mymaster是集群的名称，此行指定当前mymaster集群中master服务器的地址和端口
#2为法定人数限制(quorum)，即有几个sentinel认为master down了就进行故障转移，一般此值是所有sentinel节点(一般总数是>=3的 奇数,如:3,5,7等)的一半以上的整数值，比如，总数是3，即3/2=1.5，取整为2,是master的ODOWN客观下线的依据

sentinel auth-pass mymaster 123456
#mymaster集群中master的密码，注意此行要在上面行的下面

sentinel down-after-milliseconds mymaster 30000
#(SDOWN)判断mymaster集群中所有节点的主观下线的时间，    单位：毫秒，建议3000（3秒） 否则等待时间过长

sentinel parallel-syncs mymaster 1
#发生故障转移后，可以同时向新master同步数据的slave的数量，数字越小总同步时间越长，但可以减轻新master的负载压力

sentinel failover-timeout mymaster 180000
#所有slaves指向新的master所需的超时时间，单位：毫秒

sentinel deny-scripts-reconfig yes #禁止修改脚本

修改文件的内容

[root@localhost etc]#grep -vE "^#|^$"  sentinel.conf 
bind 0.0.0.0
port 26379
daemonize  yes
pidfile /apps/redis/run/redis-sentinel.pid
logfile "/apps/redis/log/sentinel.log"
dir /tmp
sentinel monitor mymaster 192.168.240.13 6379 2
sentinel auth-pass  mymaster  123456
sentinel down-after-milliseconds mymaster 3000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel deny-scripts-reconfig yes

4）准备service 文件 注意先开主再开从 全部节点都需要

cat  >> /lib/systemd/system/redis-sentinel.service  <<eof
[Unit]
Description=Redis Sentinel
After=network.target
[Service]
ExecStart=/apps/redis/bin/redis-sentinel /apps/redis/etc/sentinel.conf --supervised systemd
ExecStop=/bin/kill -s QUIT $MAINPID
User=redis
Group=redis
RuntimeDirectory=redis
RuntimeDirectoryMode=0755
[Install]
WantedBy=multi-user.target
eof
[root@localhost etc]# systemctl daemon-reload 
[root@localhost etc]# systemctl start redis-sentinel.service

5）将主服务器上的sentinel.conf传输到两台从服务器

scp  -r /apps/redis/etc/sentinel.conf   192.168.240.14://apps/redis/etc/
scp  -r /apps/redis/etc/sentinel.conf   192.168.240.12://apps/redis/etc/

6）将所有节点上的sentinel.conf文件权限属主属组改为redis

[root@localhost ~]# cd /apps/redis/etc/
[root@localhost etc]# ls
redis.conf  sentinel.conf
[root@localhost etc]# chown redis.redis  sentinel.conf
[root@localhost etc]# ll
总用量 76
-rw-r--r--. 1 redis redis 61857 7月   9 16:09 redis.conf
-rw-r--r--. 1 redis redis  9804 7月  10 17:48 sentinel.conf

7）刷新配置文件，先开启主上的哨兵在开启从

[root@localhost etc]# systemctl daemon-reload 
[root@localhost etc]# systemctl start redis-sentinel.service
[root@localhost etc]# systemctl status redis-sentinel.service

8）主从服务器上查看日志文件

tail -f /apps/redis/log/sentinel.log
ss -natp |grep 26379

主服务器

从服务器

9）测试，关闭主服务器redis

systemctl stop redis

查看日志

主服务器

从服务器1成为新的主服务器

从服务器1

从服务器1成为新的主服务器

从服务器2

从服务器1成为新的主服务器，从2指向新主

当再次开启原主服务器时

这是不会抢占主的位置会成为新主的从服务器

5.哨兵模式查看状态以及报错

在sentinel状态中尤其是最后一行，涉及到masterIP是多少，有几个slave，有几个sentinels，必须是符合全部服务器数量

[root@redis-master ~]#redis-cli -p 26379
127.0.0.1:26379> INFO sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=10.0.0.8:6379,slaves=2,sentinels=3 #两个slave,三个sentinel服务器,如果sentinels值不符合,检查myid可能冲突


###  去看  配置文件中的 id  要所有节点不一样
[root@localhost etc]#tail -f  /apps/redis/etc/sentinel.conf 
# Generated by CONFIG REWRITE
maxclients 4064
protected-mode no
supervised systemd
sentinel leader-epoch mymaster 1
sentinel known-replica mymaster 192.168.91.100 6379
sentinel known-replica mymaster 192.168.91.102 6379
sentinel known-sentinel mymaster 192.168.91.101 26379 114478912af9bd3d63ae07ae0b6f288564f40140
sentinel known-sentinel mymaster 192.168.91.102 26379 177dbc2f08df08a97cd69a4b4142870a38a3cb71
sentinel current-epoch 1

三.集群（redis cluster）

1.架构特点

分布式数据存储：

Redis Cluster 将数据分布在多个节点上，每个节点负责存储部分数据。这样可以通过增加节点来扩展存储容量和吞吐量。

高可用性：

Redis Cluster 提供了自动分片和数据复制机制，确保即使部分节点故障，集群仍能继续工作。每个数据片段都会被复制到其他节点，以提供数据的备份和冗余。

自动故障转移：

当某个主节点失效时，Redis Cluster 会自动选举一个备用节点作为新的主节点，保证数据的可用性和服务的持续运行。这种自动故障转移能力减少了对管理员干预的需求。

节点间通信：

Redis Cluster 使用二进制协议进行节点间通信，确保数据的快速和高效传输。

客户端路由：

客户端通过 Redis Cluster 的路由功能连接到集群中的合适节点。Redis Cluster 使用哈希槽（hash slot）来映射键到特定的节点，每个节点负责处理一部分哈希槽的数据请求。

2.组成部分

节点（Node）：

Redis Cluster 由多个 Redis 节点组成，每个节点都运行一个 Redis 实例。节点分为主节点和从节点，主节点负责处理数据的写入和读取，从节点负责复制主节点的数据。

哈希槽（Hash Slot）：

Redis Cluster 将数据分割成 16384 个哈希槽（0 到 16383）。每个键通过 CRC16 校验和算法映射到一个具体的哈希槽上。每个节点负责处理一部分哈希槽的数据。

复制（Replication）：

每个主节点会有 1 到多个从节点，从节点通过复制主节点的数据来实现数据的备份和高可用性。如果主节点失效，从节点可以被提升为新的主节点。

客户端和代理（Client and Proxy）：

客户端通过 Redis Cluster 的客户端库连接到集群。客户端库负责实现路由逻辑，根据键的哈希槽映射到正确的节点上。在一些部署中，代理（如 Redis Sentinel 或者自定义代理）可以处理与 Redis Cluster 之间的连接和故障检测，确保客户端与集群的稳定通信。

3.工作流程

节点加入：

当一个新节点加入 Redis Cluster 时，它会请求集群的其他节点获取关于哈希槽分布的信息，并且被分配一个或多个哈希槽。

数据存储：

客户端将键发送到 Redis Cluster，根据键的哈希槽决定发送到哪个节点。每个节点负责管理自己负责的哈希槽上的数据。

故障处理：

当主节点失效时，集群中的其他节点会检测到这个情况，并开始选举一个从节点作为新的主节点。这个过程通常很快，确保了集群对故障的快速响应和恢复。

4.实现集群

开启多实例来实现redis

redis的集群一般需要6个节点，3主3从。方便起见，这里所有节点在同一台服务器上模拟：以端口号进行区分：3个主节点端口号：6001/6002/6003，对应的从节点端口号：6004/6005/6006
但是可能随机搭配

1）关闭防火墙和selinux

[root@localhost ~]# systemctl stop firewalld
[root@localhost ~]# setenforce 0

2）新建集群文件目录

[root@localhost ~]# cd /apps/redis
[root@localhost redis]# ls
bin  data  etc  log  run
[root@localhost redis]# mkdir -p redis-cluster/redis600{1..6}
for i in {1..6}
do
cp /data/redis-5.0.7/redis.conf /apps/redis/redis-cluster/redis600$i
cp /data/redis-5.0.7/src/redis-cli /data/redis-5.0.7/src/redis-server /apps/redis/redis-cluster/redis600$i
done
[root@localhost redis]# cd redis-cluster/
[root@localhost redis-cluster]# tree

3）修改配置文件

[root@localhost redis-cluster]# vim redis6001/redis.conf 
70 bind 0.0.0.0
#将监听端口改为任意端口
172 logfile /apps/redis/log/redis6001.log
#指定日志文件目录
264 dir /apps/redis/data/
#指定工作目录
pidfile /apps/redis/run/redis_6001.pid
#pid文件建议文件修改
protected-mode no						#88行，修改，关闭保护模式
port 6001								#92行，修改，redis监听端口，
daemonize yes							#136行，开启守护进程，以独立进程启动  如果是 systemd 启动不需要修改
cluster-enabled yes						#832行，取消注释，开启群集功能
cluster-config-file nodes-6001.conf		#840行，取消注释，群集名称文件设置
cluster-node-timeout 15000				#846行，取消注释群集超时时间设置
appendonly yes

[root@localhost redis-cluster]# cd redis6001
[root@localhost redis6001]# for i in {2..6}
> do
> \cp -f  ./redis.conf   /apps/redis/redis-cluster/redis600${i}
> done

sed  -i   's/6001/6002/'   /apps/redis/redis-cluster/redis6002/redis.conf
sed  -i   's/6001/6003/'   /apps/redis/redis-cluster/redis6003/redis.conf
sed  -i   's/6001/6004/'   /apps/redis/redis-cluster/redis6004/redis.conf
sed  -i   's/6001/6005/'   /apps/redis/redis-cluster/redis6005/redis.conf
sed  -i   's/6001/6006/'   /apps/redis/redis-cluster/redis6006/redis.conf

4）先停止原来的redis服务

[root@localhost redis6001]#systemctl stop redis
# 先停止之前的服务
[root@localhost redis6001]#ss -natp |grep 6379

5）启动redis（1-6）服务器

[root@localhost redis6002]# cd /apps/redis/redis-cluster/redis6001
for d in {1..6}
do
cd /apps/redis/redis-cluster/redis600$d
redis-server redis.conf
done

[root@localhost redis6006]#ps -ef | grep redis
[root@localhost redis6006]#ss -natp |grep "\b600[1-6]\b"

[root@localhost redis6006]#redis-cli --cluster create 127.0.0.1:6001 127.0.0.1:6002 127.0.0.1:6003 127.0.0.1:6004 127.0.0.1:6005 127.0.0.1:6006 --cluster-replicas 1
#六个实例分为三组，每组一主一从，前面的做主节点，后面的做从节点。下面交互的时候 需要输入 yes 才可以创建。
--replicas 1 表示每个主节点有1个从节点。

6）进入redis服务查看主从状态

[root@localhost redis6006]# redis-cli -p 6001  -c
#加-c参数，节点之间就可以互相跳转
127.0.0.1:6001> cluster slots