Redis集群高可用（主从，哨兵，集群模式）

2023-12-19 21:14:02

（1）数据分区：数据分区(或称数据分片)是集群最核心的功能。集群将数据分散到多个节点，一方面突破了Redis单机内存大小的限制，存储容量大大增加；另一方面每个主节点都可以对外提供读服务和写服务，大大提高了集群的响应能力。 Redis单机内存大小受限问题，在介绍持久化和主从复制时都有提及；例如，如果单机内存太大，bgsave和bgrewriteaof的fork操作可能导致主进程阻塞，主从环境下主机切换时可能导致从节点长时间无法提供服务，全量复制阶段主节点的复制缓冲区可能溢出。

（2）高可用：集群支持主从复制和主节点的自动故障转移（与哨兵类似）；当任一节点发生故障时，集群仍然可以对外提供服务。

02-Redis集群.txt

Redis集群是Redis提供的分布式数据库方案，它通过分片（sharding）来实现数据共享，并提供复制和故障转移。以下是Redis集群的工作方式的主要特点：

分片（Sharding）： Redis集群将整个数据集分成16384个哈希槽（hash slots）。每个节点负责一部分哈希槽，从而分散了数据的存储和访问压力。
多主节点： 在Redis集群中，可以有多个主节点，每个主节点负责处理一部分数据。这样可以水平扩展系统的性能，提高读写操作的吞吐量。
节点间通信： 节点之间通过内部网络进行通信。Redis集群使用集群总线（cluster bus）来进行节点之间的消息传递和协调，以保持集群的一致性和可用性。
故障检测和转移： Redis集群通过定期的PING/PONG消息来检测节点的存活状态。如果一个主节点不可用，集群会通过投票机制选举新的主节点，并进行故障转移，以保持数据的可用性。
客户端分片： 客户端通过哈希算法将数据的key散列到相应的哈希槽，并直接与负责该槽的节点通信。这样，客户端可以直接与多个节点交互，而不必通过中间代理。
自动重新平衡： 当节点的数量发生变化时，Redis集群能够自动重新平衡哈希槽的分配，以适应新的节点配置。

总体而言，Redis集群通过分片和多节点的方式实现了高性能、高可用性的分布式存储系统，同时具备自动故障转移和动态扩展的能力。这使得Redis集群成为处理大规模数据和高并发访问的理想选择。

高可用方案

主从复制（Master-Slave Replication）:

工作原理： 主从复制通过将主节点的写操作同步到一个或多个从节点来实现数据的复制。从节点接收主节点的数据变更，从而保持与主节点相同的数据。
主从复制是高可用Redis的基础，哨兵和集群都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。
配置： 在Redis配置文件中，通过指定slaveof选项或使用SLAVEOF命令将一个从节点指定为主节点的复制品。
故障处理： 当主节点不可用时，可以手动将一个从节点提升为主节点。这需要管理员手动介入。
缺陷：故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。

验证 Redis 主从复制

验证 Redis 主从复制的步骤涉及确保主节点的数据被成功复制到一个或多个从节点，并且从节点处于正常运行状态。以下是验证 Redis 主从复制的基本步骤：

查看主从节点连接状态: 在主节点上执行以下命令，查看连接到主节点的从节点信息：

redis-cli info replication

确保输出显示正确的从节点数量、它们的 IP 地址、端口以及它们的状态为 "online"。

观察主节点的复制信息: 在主节点的日志文件中，查看是否有关于复制的相关日志，例如：

tail -f /var/log/redis/redis-server.log

确保主节点没有出现明显的错误，并且有关同步的日志表明同步是成功的。

查看从节点的日志: 在从节点的日志文件中，查看是否有关于同步的日志，例如：

tail -f /var/log/redis/redis-server.log

确保从节点没有出现明显的错误，并且有关同步的日志表明同步是成功的。

检查复制偏移量: 在主节点上执行以下命令，查看主从节点的复制偏移量：

redis-cli info replication | grep "master_repl_offset"

然后在每个从节点上执行相同的命令，确保它们的复制偏移量与主节点一致。

执行命令验证: 在主节点上执行一些写入操作，例如 SET 命令，然后确保这些操作在所有从节点上被正确地复制和执行。
模拟从节点故障: 模拟从节点故障（例如，停止从节点的 Redis 服务），然后观察主节点日志，确保主节点能够检测到从节点的断开，并在从节点重新连接时进行正确的同步。
检查同步延迟: 在从节点上执行以下命令，查看从节点与主节点之间的同步延迟：

redis-cli info replication | grep "lag"

确保同步延迟不是过高，以确保从节点的数据与主节点尽可能保持同步。

通过执行这些步骤，可以验证 Redis 主从复制是否正常运行。确保从节点与主节点同步，复制偏移量正确，并且在主从节点之间进行写入操作时，数据在从节点上正确地复制和执行。

哨兵模式（Sentinel）:

工作原理： 哨兵是一个独立的进程，用于监控主节点和从节点的健康状态。当出现故障时通过投票机制选择新的 Master并将所有slave连接到新的 Master。所以整个运行哨兵的集群的数量不得少于3个节点。
在主从复制的基础上，哨兵实现了自动化的故障恢复。
配置： 哨兵配置包括监控的主节点信息，以及故障转移的参数。每个Redis节点都运行哨兵。
自动化切换： 在主节点故障时，哨兵能够自动完成切换，提高系统的可用性。
缺陷：写操作无法负载均衡；存储能力受到单机的限制；哨兵无法对从节点进行自动故障转移，在读写分离场景下，从节点故障会导致读服务不可用，需要对从节点做额外的监控、切换操作。

哨兵模式的作用

以下是哨兵模式的主要作用：

监控： Sentinel会定期检查与其相关联的Redis节点的健康状态。它可以检测到主节点是否宕机或无法正常工作。

自动故障检测： 当哨兵检测到主节点不可用时，它会自动进行故障检测，并选择一个适当的备用节点升级为新的主节点。

自动故障转移： 在检测到主节点故障后，哨兵会自动选择一个备用节点升级为新的主节点，确保系统持续运行而无需手动干预。

配置中心： Sentinel还充当配置中心，负责维护有关Redis实例的信息。它会监控并记录有关节点的信息，包括主节点、备用节点以及其他相关配置。

通知系统： 当主节点状态发生变化时，哨兵会通过消息通知其他系统组件，以便它们能够及时调整到新的主节点。

哨兵模式的引入可以提高Redis的可用性，减少因主节点故障而导致的服务中断时间。通过自动监测和故障转移，哨兵模式使得Redis集群能够更好地应对故障，保持系统的稳定性。

哨兵结构构成

哨兵模式由多个哨兵节点组成，这些节点共同协作以监控和管理Redis实例。以下是哨兵结构的主要组成部分：

主节点（Master）： Redis集群中的主节点负责处理写操作和向从节点同步数据。哨兵模式监控的目标之一就是主节点的健康状态。
从节点（Slave）： 从节点是主节点的备份，负责复制主节点的数据。哨兵模式也会监控从节点，以确保它们正常运行，并在需要时选择一个合适的从节点升级为新的主节点。
哨兵节点（Sentinel）： 哨兵节点是负责监控和管理Redis实例的特殊节点。多个哨兵节点分布在网络中，它们相互通信以共同完成监控和决策任务。一个典型的哨兵集群包括至少三个哨兵节点，以确保在出现网络分区或节点故障的情况下仍能够做出决策。

监控主节点和从节点： 哨兵节点会定期向主节点和从节点发送检查请求，以确保它们的健康状态。
故障检测和转移： 当哨兵节点检测到主节点不可用时，它会协调决策，选择一个从节点升级为新的主节点，实现自动故障转移。
配置中心： 哨兵节点负责维护关于Redis实例的配置信息，包括主节点、从节点、故障转移的配置等。
通知系统： 哨兵节点会通过消息通知其他哨兵节点和相关组件有关主节点状态的变化。

故障转移机制

监控： 哨兵节点定期向主节点和从节点发送PING命令，以检测它们的健康状态。哨兵还会通过订阅频道来接收有关其他哨兵节点和Redis实例状态变化的通知。
故障检测： 如果哨兵节点检测到主节点不可用，它会将其标记为主观下线（subjectively down）。主观下线是指哨兵认为主节点可能出现了故障，但这个判断是基于个别哨兵节点的观察。
投票和协商： 当一个哨兵节点将主节点标记为主观下线后，它会向其他哨兵节点发送通知，询问它们的看法。通过投票和协商，哨兵节点会形成对主节点状态的共识，从而达成一致的判断。
客观下线： 当大多数哨兵节点都认为主节点不可用时，主节点就会被标记为客观下线（objectively down）。客观下线是一个全局性的判断，表示整个集群认为主节点已经故障。
选举新主节点： 一旦主节点被客观下线，哨兵节点会从当前的从节点中选择一个作为新的主节点。这个选择过程包括考虑从节点的健康状态、复制偏移量等因素。
故障转移： 选举出新的主节点后，哨兵节点会通知Redis集群中的其他节点，进行切换操作。从节点切换为主节点，并开始接受写操作。客户端和其他Redis实例被更新以连接到新的主节点。

通过这个机制，哨兵模式可以在主节点故障时自动进行故障检测、协商和切换操作，实现快速的故障转移，确保系统的可用性。这种自动化的机制减少了对人工干预的需求，提高了整个Redis集群的稳定性和可靠性。

主节点的选择

发现主观下线： 当一个哨兵节点检测到主节点不可用，它会将主节点标记为主观下线。这是一个本地的判断，表示哨兵个体认为主节点可能故障。
发送通知： 一旦哨兵节点将主节点标记为主观下线，它会向其他哨兵节点发送通知，询问它们对主节点状态的看法。
投票和协商： 哨兵节点通过互相通信，进行投票和协商，以达成对主节点是否故障的共识。这涉及到哨兵节点之间的通信和协调，确保它们对主节点状态的判断是一致的。
客观下线： 当大多数哨兵节点都认为主节点不可用时，主节点就被标记为客观下线。这是一个全局的共识，表示整个Redis集群认为主节点已经故障。
选举新主节点： 一旦主节点被客观下线，哨兵节点会从当前的从节点中选择一个作为新的主节点。这个选择过程包括考虑从节点的健康状态、复制偏移量等因素。通常情况下，选择最健康的从节点作为新的主节点。
通知其他节点： 选举出新的主节点后，哨兵节点会向Redis集群中的其他节点发送通知，宣布新的主节点。这包括通知客户端和其他Redis实例，以便它们更新连接信息。
切换操作： 新的主节点开始接受写操作，而原来的主节点（如果重新上线）将成为从节点，开始进行复制同步。这个切换操作是为了确保Redis集群继续正常工作。

集群模式:

工作原理： Redis集群模式将数据分为多个槽（slots），每个槽分配给集群中的不同节点。节点间通过Gossip协议进行通信。每个节点负责处理一部分槽上的数据。
集群由多个节点(Node)组成，Redis的数据分布在这些节点中。集群中的节点分为主节点和从节点：只有主节点负责读写请求和集群信息的维护；从节点只进行主节点数据和状态信息的复制。
通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。
配置： 集群配置包括节点信息、槽分配等。Redis提供了redis-trib.rb工具用于集群的创建和管理。
自动化分片和故障恢复： 集群模式支持自动分片和故障恢复。当有节点故障或新节点加入时，集群会自动进行重新分片和数据迁移。

选择依据：

规模和性能需求： 主从复制适用于小规模应用，而集群模式适用于大规模应用。哨兵模式在中等规模下提供了一定的自动化。
可用性需求： 集群模式和哨兵模式提供更高的可用性，因为它们支持自动化的故障转移。
部署和管理： 主从复制相对简单，而集群模式需要更复杂的配置和管理。

选择合适的方案取决于具体应用的需求和规模。对于较小规模的应用，主从复制或哨兵模式可能更易于管理，而对于大规模和高可用性需求，集群模式可能更为适合。

Redis集群的作用

分布式存储和负载均衡：

将数据分散存储在多个节点上，避免了单一节点的瓶颈问题。
实现了水平扩展，允许在需要时增加或减少节点数量，以适应负载变化。

高可用性和故障容忍：

Redis集群采用主从复制和分片技术，提高了系统的可用性。即使其中一个节点失效，集群依然可以继续工作。
在主节点故障时，自动进行故障转移，将从属节点提升为新的主节点。

自动数据迁移：

当增加或减少节点时，Redis集群能够自动进行数据迁移，确保数据分布均匀，并且不需要手动干预。

提高读写性能：

通过将数据分布在多个节点上，Redis集群可以并行处理多个请求，提高了读写操作的整体性能。

无中心化管理：

Redis集群没有单一的中心节点，每个节点都是平等的。这种去中心化的设计避免了单点故障和性能瓶颈。

支持事务操作：

Redis集群模式通过实现分布式事务来支持跨节点的事务操作。虽然Redis本身是单线程的，但可以通过一致性哈希等技术在多个节点上实现分布式事务。

在线扩容和缩容：

可以在线添加新节点，使得集群能够适应业务的增长。
可以在线移除节点，以适应负载减少或节点维护的需求。

集群监控和管理：

Redis集群提供了监控和管理工具，可以查看每个节点的状态、负载和性能指标。这些工具使得集群的维护更加方便。

Redis集群的数据分片

Redis集群通过数据分片（sharding）将数据分布在多个节点上，以实现水平扩展和提高系统性能。数据分片是通过一致性哈希（Consistent Hashing）来实现的，具体过程如下：

确定槽位（Slots）：

Redis集群将整个数据范围分为16384个槽位（0-16383）。
每个槽位都可以存储一个键值对。

为节点分配槽位：

将槽位均匀地分配给集群中的各个节点。
每个节点负责管理一部分槽位的数据。

一致性哈希映射：

当客户端请求写入或读取数据时，Redis集群使用一致性哈希算法将键映射到一个具体的槽位。
根据槽位的分配，确定哪个节点负责该槽位。

数据路由：

客户端向集群发出命令，命令包含键。
集群使用一致性哈希计算键属于哪个槽位。
根据槽位的分配，找到负责该槽位的节点。

节点间通信：

如果命令需要写入数据，客户端与负责槽位的节点直接通信。
如果命令只涉及读取数据，也可以直接从负责槽位的节点读取。

动态扩容和缩容：

当需要扩容时，可以添加新的节点，并将一些槽位重新分配给新节点。
当需要缩容时，可以将一些槽位从一个节点移动到另一个节点。
数据迁移由Redis集群自动处理，不需要停机。

通过这种方式，Redis集群能够将大量数据分布在多个节点上，从而提高了整体的读写性能和存储容量。同时，一致性哈希的使用确保了在节点变化时最小化数据的迁移量，降低了数据迁移的开销。数据分片是Redis集群模式的核心特性之一，使得Redis能够适应高并发和大规模数据存储的需求。

#以3个节点组成的集群为例：
节点A包含0到5460号哈希槽
节点B包含5461到10922号哈希槽
节点C包含10923到16383号哈希槽

#Redis集群的主从复制模型
集群中具有A、B、C三个节点，如果节点B失败了，整个集群就会因缺少5461-10922这个范围的槽而不可以用。
为每个节点添加一个从节点A1、B1、C1整个集群便有三个Master节点和三个slave节点组成，在节点B失败后，集群选举B1位为的主节点继续服务。当B和B1都失败后，集群将不可用。

实例

搭建主从复制

环境准备

Master节点： 192.168.41.31 Slave1节点： 192.168.41.32 Slave2节点： 192.168.41.33

关闭防火墙和安全机制
systemctl stop firewalld
setenforce 0

安装redis

yum install -y gcc gcc-c++ make

tar zxvf redis-5.0.7.tar.gz -C /opt/

wget -p /opt http://download.redis.io/releases/redis-5.0.9.tar.gz
cd /opt/redis-5.0.7/
make
make PREFIX=/usr/local/redis install

cd /opt/redis-5.0.7/utils
./install_server.sh
......
Please select the redis executable path [/usr/local/bin/redis-server] /usr/local/redis/bin/redis-server      

ln -s /usr/local/redis/bin/* /usr/local/bin/

修改配置

-----修改 Redis 配置文件（Master节点操作）-----
vim /etc/redis/6379.conf   redis.conf
bind 0.0.0.0                        #70行，修改监听地址为0.0.0.0，全接收
daemonize yes                        #137行，开启守护进程
logfile /var/log/redis_6379.log        #172行，指定日志文件目录
dir /var/lib/redis/6379                #264行，指定工作目录
appendonly yes                        #700行，开启AOF持久化功能


/etc/init.d/redis_6379 restart


-----修改 Redis 配置文件（Slave节点操作）-----
vim /etc/redis/6379.conf
bind 0.0.0.0                        #70行，修改监听地址为0.0.0.0
daemonize yes                        #137行，开启守护进程
logfile /var/log/redis_6379.log        #172行，指定日志文件目录
dir /var/lib/redis/6379                #264行，指定工作目录        
replicaof 192.168.10.23 6379        #288行，指定要同步的Master节点IP和端口
appendonly yes                        #700行，开启AOF持久化功能


/etc/init.d/redis_6379 restart

验证

#Master添加键值对
redis-cli
set mykey "Hello, Redis!"
#slave上测试
redis-cli
get mykey

查看日志验证效果

在Master节点上看日志：
tail -f /var/log/redis_6379.log 
Replica 192.168.10.14:6379 asks for synchronization
Replica 192.168.10.15:6379 asks for synchronization

在Master节点上验证从节点：
redis-cli info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.10.14,port=6379,state=online,offset=1246,lag=0
slave1:ip=192.168.10.15,port=6379,state=online,offset=1246,lag=1

搭建哨兵模式

-----修改 Redis 哨兵模式的配置文件（所有节点操作）-----
vim /opt/redis-5.0.7/sentinel.conf
protected-mode no                                #17行，关闭保护模式
port 26379                                        #21行，Redis哨兵默认的监听端口
daemonize yes                                    #26行，指定sentinel为后台启动
logfile "/var/log/sentinel.log"                    #36行，指定日志存放路径
dir "/var/lib/redis/6379"                        #65行，指定数据库存放路径
sentinel monitor mymaster 192.168.41.31 6379 2    #84行，修改 指定该哨兵节点监控192.168.41.31:6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移
sentinel down-after-milliseconds mymaster 30000    #113行，判定服务器down掉的时间周期，默认30000毫秒（30秒）
sentinel failover-timeout mymaster 180000        #146行，故障节点的最大超时时间为180000（180秒）


-----启动哨兵模式-----
先启master，再启slave
cd /opt/redis-5.0.7/
redis-sentinel sentinel.conf &


-----查看哨兵信息-----
redis-cli -p 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=192.168.41.31:6379,slaves=2,sentinels=3

故障模拟

#查看redis-server进程号：
ps -ef | grep redis
#模拟主节点宕机：
手动停止或关闭Redis主节点。你可以使用redis-cli连接到主节点，然后执行SHUTDOWN命令来停止Redis服务。
模拟主节点故障：

假设你的主节点运行在IP地址为192.168.41.31，端口为6379。可以模拟主节点故障，例如通过使用redis-cli连接到主节点并执行SHUTDOWN命令：

redis-cli -h 192.168.41.31 -p 6379 SHUTDOWN

验证的结果

#观察Sentinel日志
tail -f /var/log/sentinel.log

这段日志记录了Redis Sentinel在进行主节点故障转移时的一系列事件。以下是每个条目的解释：

+promoted-slave：

75472:X 19 Dec 2023 16:48:25.308 # +promoted-slave slave 192.168.41.32:6379 192.168.41.32 6379 @ mymaster 192.168.41.31 6379

这表示一个从属节点（slave）被提升为新的主节点。在这里，从属节点的IP地址为192.168.41.32，端口为6379。

+failover-state-reconf-slaves：

75472:X 19 Dec 2023 16:48:25.308 # +failover-state-reconf-slaves master mymaster 192.168.41.31 6379

这表示Sentinel开始将其他从属节点重新配置以连接到新的主节点。

+slave-reconf-sent：

75472:X 19 Dec 2023 16:48:25.369 * +slave-reconf-sent slave 192.168.41.33:6379 192.168.41.33 6379 @ mymaster 192.168.41.31 6379

表示一个从属节点（slave）正在接收来自新主节点的重新配置信息。

-odown：

75472:X 19 Dec 2023 16:48:25.516 # -odown master mymaster 192.168.41.31 6379

表示旧的主节点被标记为主观下线（ODOWN）。

+slave-reconf-inprog / +slave-reconf-done：

75472:X 19 Dec 2023 16:48:26.414 * +slave-reconf-inprog slave 192.168.41.33:6379 192.168.41.33 6379 @ mymaster 192.168.41.31 6379
75472:X 19 Dec 2023 16:48:26.414 * +slave-reconf-done slave 192.168.41.33:6379 192.168.41.33 6379 @ mymaster 192.168.41.31 6379

表示一个从属节点的重新配置过程已经开始（+slave-reconf-inprog），并最终完成（+slave-reconf-done）。

+failover-end：

75472:X 19 Dec 2023 16:48:26.481 # +failover-end master mymaster 192.168.41.31 6379

表示故障转移结束。

+switch-master：

75472:X 19 Dec 2023 16:48:26.481 # +switch-master mymaster 192.168.41.31 6379 192.168.41.32 6379

表示主节点切换完成，新的主节点的IP地址为192.168.41.32，端口为6379。

+slave：

75472:X 19 Dec 2023 16:48:26.482 * +slave slave 192.168.41.33:6379 192.168.41.33 6379 @ mymaster 192.168.41.32 6379
75472:X 19 Dec 2023 16:48:26.482 * +slave slave 192.168.41.31:6379 192.168.41.31 6379 @ mymaster 192.168.41.32 6379

表示其他从属节点已经重新配置，成功连接到新的主节点。

这个日志显示了整个主节点故障转移的过程，从从属节点的提升到其他从属节点的重新配置，再到最终的主节点切换和从属节点的重新连接。

#使用redis-cli工具查询Redis Sentinel的信息
redis-cli -p 26379 INFO Sentinel

#解析结果会包含关于Sentinel的各种信息，例如：

Sentinel ID：唯一标识符，用于识别Sentinel节点。
Sentinels：列出了与当前Sentinel节点通信的其他Sentinel节点的详细信息。
Masters：列出了Sentinel正在监视的Redis主节点的详细信息，包括主节点的名字、IP地址、端口等。
Slaves：如果有的话，列出了Sentinel监视的从属节点的详细信息，包括从属节点的名字、IP地址、端口等。

这是通过redis-cli工具查询Redis Sentinel的信息，并解析结果如下：

sentinel_masters:1：表示当前Sentinel节点正在监视一个Redis主节点。
sentinel_tilt:0：表示当前Sentinel节点没有处于倾斜状态（tilt）。倾斜状态是一种异常状态，可能会导致Sentinel停止监控和执行自动故障转移。
sentinel_running_scripts:0：表示当前Sentinel节点没有正在运行的脚本。
sentinel_scripts_queue_length:0：表示当前Sentinel节点的脚本队列长度为0，即没有待执行的脚本。
sentinel_simulate_failure_flags:0：表示当前Sentinel节点没有模拟故障的标志位被设置。这个值用于在测试环境中模拟不同的故障场景。
master0:name=mymaster,status=ok,address=192.168.41.32:6379,slaves=2,sentinels=3：表示当前有一个名为mymaster的主节点，状态为"ok"，位于IP地址为192.168.41.32，端口为6379。该主节点有2个从属节点（slaves）和3个Sentinel节点在监视它。

搭建集群模式

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

cd /etc/redis/
mkdir -p redis-cluster/redis600{1..6}

for i in {1..6}
do
cp /opt/redis-5.0.7/redis.conf /etc/redis/redis-cluster/redis600$i
cp /opt/redis-5.0.7/src/redis-cli /opt/redis-5.0.7/src/redis-server /etc/redis/redis-cluster/redis600$i
done

#开启群集功能：
#其他5个文件夹的配置文件以此类推修改，注意6个端口都要不一样。
cd /etc/redis/redis-cluster/redis6001
vim redis.conf
#bind 127.0.0.1                            #69行，注释掉bind 项，默认监听所有网卡
protected-mode no                        #88行，修改，关闭保护模式
port 6001                                #92行，修改，redis监听端口，
daemonize yes                            #136行，开启守护进程，以独立进程启动
cluster-enabled yes                        #832行，取消注释，开启群集功能
cluster-config-file nodes-6001.conf        #840行，取消注释，群集名称文件设置
cluster-node-timeout 15000                #846行，取消注释群集超时时间设置
appendonly yes                            #700行，修改，开启AOF持久化

#启动redis节点
分别进入那六个文件夹，执行命令：redis-server redis.conf ，来启动redis节点
cd /etc/redis/redis-cluster/redis6001
redis-server redis.conf

for d in {1..6}
do
cd /etc/redis/redis-cluster/redis600$d
redis-server redis.conf
done

ps -ef | grep redis

#启动集群
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个从节点。

#测试群集
redis-cli -p 6001 -c                    #加-c参数，节点之间就可以互相跳转
127.0.0.1:6001> cluster slots            #查看节点的哈希槽编号范围
1) 1) (integer) 5461
   2) (integer) 10922                                    #哈希槽编号范围
   3) 1) "127.0.0.1"
      2) (integer) 6003                                    #主节点IP和端口号
      3) "fdca661922216dd69a63a7c9d3c4540cd6baef44"
   4) 1) "127.0.0.1"
      2) (integer) 6004                                    #从节点IP和端口号
      3) "a2c0c32aff0f38980accd2b63d6d952812e44740"
2) 1) (integer) 0
   2) (integer) 5460
   3) 1) "127.0.0.1"
      2) (integer) 6001
      3) "0e5873747a2e26bdc935bc76c2bafb19d0a54b11"
   4) 1) "127.0.0.1"
      2) (integer) 6006
      3) "8842ef5584a85005e135fd0ee59e5a0d67b0cf8e"
3) 1) (integer) 10923
   2) (integer) 16383
   3) 1) "127.0.0.1"
      2) (integer) 6002
      3) "816ddaa3d1469540b2ffbcaaf9aa867646846b30"
   4) 1) "127.0.0.1"
      2) (integer) 6005
      3) "f847077bfe6722466e96178ae8cbb09dc8b4d5eb"

127.0.0.1:6001> set name zhangsan
-> Redirected to slot [5798] located at 127.0.0.1:6003
OK

127.0.0.1:6001> cluster keyslot name                    #查看name键的槽编号

redis-cli -p 6004 -c
127.0.0.1:6004> keys *                            #对应的slave节点也有这条数据，但是别的节点没有
1) "name"

文章来源:https://blog.csdn.net/qq_51545656/article/details/135089506
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系我的编程经验分享网邮箱：veading@qq.com进行投诉反馈，一经查实，立即删除！