Redis集群

2301_80613136

于 2024-09-14 16:59:07 发布

阅读量1k

点赞数 10

文章标签： redis 数据库缓存

本文链接：https://blog.csdn.net/2301_80613136/article/details/142262425

版权

文章目录

一，三种Redis群集的模式
二，Redis 主从复制
三，哨兵
四，Redis 群集模式

一，三种Redis群集的模式

1.主从复制

主从复制是Redis高可用架构的基础。它的核心是通过一个主节点（master）将数据同步到多个从节点（slave），实现以下几方面：

多机备份：从节点保存主节点的数据副本，一旦主节点发生故障，从节点仍然可以提供部分读服务。
读操作负载均衡：从节点可以分担读请求，减轻主节点的压力。
简单的故障恢复：在主节点故障时，人工切换从节点为主节点。

缺陷：

故障恢复无法自动化：如果主节点宕机，需要手动切换到从节点，过程较慢且容易出错。
写操作无法负载均衡：所有的写请求只能由主节点处理，导致主节点容易成为瓶颈。
存储能力受限于单机：因为主节点负责所有写操作，存储数据的大小受制于单台服务器的容量。

2.哨兵（Sentinel）

在主从复制的基础上，哨兵模式增加了自动化的故障检测和恢复。哨兵节点会监控主节点和从节点，当主节点出现故障时，它会自动选择一个从节点并将其提升为主节点。这一机制显著提升了Redis的高可用性。

优点：

自动化故障恢复：哨兵能够在主节点故障时自动切换从节点为新的主节点，减少了手动干预的需要。
持续监控：哨兵能监控集群状态并通知管理员，方便问题的预警。

缺陷：

写操作无法负载均衡：和主从复制一样，写操作仍然只能由主节点处理。
存储能力受限于单机：主节点仍然是单点写入，单台机器的存储能力会成为瓶颈。
从节点故障处理不足：哨兵无法对从节点进行自动故障转移。如果在读写分离的场景下从节点宕机，会导致部分读服务不可用，需要额外的监控与手动切换。

3.集群（Cluster）

Redis集群通过将数据分片存储在多个节点上，解决了哨兵模式中写操作无法负载均衡和存储能力受限的问题。每个节点存储一部分数据，并且可以同时处理读写请求。Redis集群的核心优势包括：

写操作负载均衡：数据分布在多个节点上，写请求也可以均匀分布到各个主节点，减少了单节点的写压力。
分布式存储：通过数据分片，每个节点只负责一部分数据，突破了单机存储的限制。
高可用性：当某个节点发生故障时，集群会自动将请求路由到其他可用的节点，确保服务的持续运行。

优点：

写操作和读操作的负载均衡：集群解决了单点写入的问题，支持多节点同时处理写请求。
存储扩展性：可以根据需求水平扩展，添加更多节点来存储数据和处理请求。
自动故障恢复：集群支持节点的自动故障转移和数据重新分配。

缺陷：

实现复杂：相比主从复制和哨兵模式，集群的配置和维护更加复杂。
数据一致性问题：集群模式下，数据的一致性有时需要进行权衡，尤其是在网络分区或部分节点故障的情况下。

二，Redis 主从复制

Redis 的主从复制（Master-Slave Replication）是 Redis 数据库中实现高可用和数据冗余的基础功能之一。它允许 Redis 在主节点（Master）和多个从节点（Slave）之间进行数据同步，从而提高数据的可靠性和可用性。默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

1.作用

1.1 数据冗余

主从复制为 Redis 实现了一种数据热备份的机制，提供了数据冗余。这是 Redis 除持久化（如 RDB、AOF 文件）之外的一种数据保护方式。在主节点出现问题时，从节点上的数据副本可以用来恢复和继续提供服务。

热备份：主从复制中的从节点会实时同步主节点的数据，保证了主节点数据的冗余。即便主节点发生故障，从节点依然能保持最新的数据状态。
提升可靠性：通过这种方式，Redis 数据库可以避免单点故障造成的数据丢失，提高系统的容灾能力。

1.2 故障恢复

当主节点出现故障时，从节点可以迅速接管服务，实现快速的故障恢复。这种机制提升了服务的可用性，减少了停机时间。

快速切换：通过手动或使用 Redis Sentinel 哨兵系统，可以将一个从节点迅速提升为新的主节点，继续提供写操作服务。
服务冗余：多个从节点分担服务，主节点故障时仍然能够继续读取数据，并且可以通过将某个从节点提升为主节点，从而实现写操作的恢复。

1.3 负载均衡

主从复制通过读写分离的方式，能够将写操作集中在主节点，读操作分发到多个从节点，从而有效分担系统负载，特别是在读多写少的场景下优势明显。

读写分离：应用系统可以将写请求发送到主节点，读请求发送到从节点。通过多个从节点提供读服务，可以有效提高系统的并发能力。
提升性能：这种读写分离的方式使得 Redis 能够轻松应对高并发读操作，大大减轻主节点的压力，提高系统的整体吞吐量和响应速度。

1.4 高可用基石

主从复制是 Redis 高可用性方案的基础，它为哨兵模式和集群模式提供了关键支撑。哨兵和集群的高可用性机制都依赖主从复制来实现数据同步、故障恢复和自动切换。

哨兵模式：哨兵通过监控主从复制的状态，在主节点故障时自动完成主从切换，保证服务的持续运行。
集群模式：在集群模式下，主从复制用于保证各个分片（shard）的数据副本，确保在节点宕机时数据依然可用。主从复制是集群中节点高可用性的基础支撑。

2.Redis主从复制的过程

2.1 Slave 向 Master 发送同步请求

当从节点（Slave）启动时，或与主节点断开后重新连接时，Slave 节点会向 Master 节点发送一个 SYNC 命令，请求与主节点进行数据同步。

2.2 Master 启动快照保存和增量数据缓冲

第一次连接或重新连接：当 Master 收到 Slave 发来的 SYNC 请求时，会启动一个后台进程，将当前内存中的数据快照保存到磁盘中（即生成 RDB 文件）。这个过程叫做快照保存，通过 RDB 持久化操作完成。
在生成快照的同时，Master 还会将所有正在执行的写操作（数据修改命令）记录下来，并存放在缓存中，以便稍后一起发送给 Slave。

2.3 Master 向 Slave 发送快照和增量数据

当 Master 完成快照保存（RDB 文件生成）后，它会将该数据文件发送给 Slave 节点。
Slave 节点接收到文件后，会将数据文件先保存到本地硬盘，然后将数据加载到内存中。
接着，Master 会将快照生成过程中记录的所有增量数据操作（即缓存中的写命令）一并发送给 Slave，确保 Slave 节点与 Master 节点的数据完全一致。

2.4 Slave 处理数据并保持与 Master 同步

Slave 节点收到数据文件后，立即进行数据加载并应用增量更新操作。
当数据加载和增量更新完成后，Slave 就进入了常规的复制状态。此时，Master 会实时将所有新的数据修改操作发送给 Slave，确保两者之间的数据保持同步。
如果 Slave 节点出现故障并宕机，在恢复连接后，它会自动重新与 Master 进行同步，重新加载数据文件并接收增量数据。

2.5 Master 同时处理多个 Slave 同步请求

如果 Master 同时收到来自多个 Slave 的同步请求，它会启动一个后台进程，生成一个快照（RDB 文件）并缓存所有写操作，然后将数据文件一次性发送给所有发出请求的 Slave 节点。这样，Master 不需要重复生成快照，可以优化同步性能。
每个 Slave 会各自保存接收到的快照文件并进行数据同步，确保所有的从节点都拥有最新的主节点数据。

3.主从复制配置

主节点 192.168.88.70

从节点1 192.168.88.80

从节点2 192.168.88.90

3.1主redis配置

关闭防火墙，临时关闭增强功能
systemctl stop firewalld
setenforce 0

下载依赖包
yum install -y gcc gcc-c++ make

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

编译安装redis
cd /opt/redis-5.0.7/
make
make PREFIX=/usr/local/redis install

按回车键一直到红框处，改成/

usr/local/redis/bin/redis-server

配置Redis 配置文件
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持久化功能

重启redis
cd /opt/redis-5.0.7/utils
/etc/init.d/redis_6379 restart

3.2从redis配置

安装redis略

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行，指定工作目录		
/opt/redis-5.0.7/sentinel.conf
replicaof 192.168.88.70 6379        #288行，指定要同步的Master节点IP和端口
appendonly yes						        #700行，开启AOF持久化功能

重启redis
cd /opt/redis-5.0.7/utils
/etc/init.d/redis_6379 restart

3.3验证主从

在主redis查看日志
tail -f /var/log/redis_6379.log 

在主redis验证从redis
redis-cli
info replication

或者在主节点上创建数据区去从节点查看有没有

redis-cli
set x1 123
keys *

三，哨兵

哨兵(sentinel):是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的 Master并将所有slave连接到新的 Master。整个运行哨兵的集群的数量不得少于3个节点。

哨兵模式是在主从复制的基础上，加上了故障自动切换，哨兵模式通过监控、自动故障转移和通知机制，帮助Redis集群保持高可用性，确保在主节点故障时能够快速恢复，避免服务长时间中断。

1.作用

1.1 监控

哨兵模式的核心功能是持续监控主节点和从节点的健康状态。它通过周期性地向这些节点发送PING命令，检查它们是否能够正常响应。一旦发现某个节点无法响应或异常时，哨兵就会认为该节点发生了故障。

1.2 自动故障转移

当哨兵模式检测到主节点出现故障后，会启动自动故障转移流程。该流程包括：

选举出一个健康的从节点，将其提升为新的主节点。
将其它从节点重新配置为复制新的主节点。
通过协调，确保整个集群的复制结构恢复正常，尽量减少服务中断。

这个自动化的过程显著减少了人为干预的需求，确保了系统的高可用性。

1.3 通知（提醒)

哨兵还具备通知机制。在故障转移的过程中，哨兵会将故障转移的结果或相关信息通知给客户端，确保客户端能够及时更新和感知集群的状态变化。

2.哨兵模式结构

哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的redis节点，不存储数据。

数据节点：主节点和从节点都是数据节点。

3.故障转移机制

3.1 主节点故障监控与下线判断

哨兵节点的主要职责之一是持续监控主节点的健康状态。这个过程包括：

(1)心跳检测（PING）：每个哨兵节点每秒都会向主节点、从节点及其它哨兵节点发送PING命令，以确认这些节点是否正常响应。

(2)主观下线（SDown）：如果哨兵节点在设定的时间内（通常是几秒钟）没有收到主节点的响应，或收到错误的响应，它会认为主节点“主观下线”（这是该哨兵的单方面判断）。

(3)客观下线（ODown）：当超过半数哨兵节点都认为主节点已失效时，集群会确认主节点“客观下线”，这意味着哨兵群体达成共识，主节点确实不可用，随后启动故障转移流程。

3.2 通过选举机制选择Leader哨兵

当哨兵集群确认主节点客观下线后，哨兵系统会使用Raft选举算法来选出一个哨兵节点作为Leader。这个Leader将负责接下来的故障转移操作。

Raft选举算法：这是一个分布式系统中的一致性算法。它确保集群中的哨兵节点能够通过投票机制选出一个Leader。
选举机制：每个哨兵节点都会尝试成为Leader，但最终只有一个哨兵节点会获得多数选票并成为Leader。Leader有权执行故障转移，并在整个哨兵集群中传播决策。

由于Raft算法的选举需要多个节点参与并达成共识，因此哨兵节点的数量必须不少于3个，这样才能有效避免选举中的平局或分歧，确保系统的可靠性。

3.3 Leader哨兵执行故障转移

一旦Leader哨兵被选出，它会立即开始执行主节点的故障转移。故障转移的过程如下：

(1) 将一个从节点升级为新的主节点

选择从节点：Leader哨兵会从现有的从节点中选择一个状态最健康、数据最完整的从节点，并将其提升为新的主节点。
条件判断：哨兵会根据从节点的同步延迟、可用性等指标选择最佳的从节点作为新的主节点。

(2) 让其他从节点指向新的主节点

更新复制目标：当新的主节点被选出后，Leader哨兵会通知其他从节点开始同步新的主节点的数据。这样，整个集群的复制架构会恢复正常，保证数据的持续一致性。

(3) 原主节点恢复后成为从节点

主节点恢复：如果原主节点恢复，它将不会自动恢复为主节点，而是被降级为从节点，并开始从新的主节点进行数据同步。这个设计防止了原主节点的突然恢复导致数据不一致的风险。

(4) 通知客户端主节点变更

通知机制：Leader哨兵会向所有客户端发送通知，告知它们主节点已经更换。客户端需要更新连接信息，开始与新的主节点通信。Redis客户端通常会重新获取主节点信息，以确保正确的读写操作。

注意：

** 客观下线是主节点才有的；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。**

3.4主节点的选举

(1)过滤掉不健康的（已下线的），没有回复哨兵 ping 响应的从节点。

(2)选择配置文件中从节点优先级配置最高的。（replica-priority，默认值为100）

(3)选择复制偏移量最大，也就是复制最完整的从节点。

4.哨兵模式配置

哨兵模式是在主从复制的基础上发展来的，需要先配置好主从复制

关闭防火墙，临时关闭增强功能
systemctl stop firewalld
setenforce 0

修改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.88.70 6379 2	
#84行，修改指定该哨兵节点监控192.168.88.70:6379主节点
该主节点的名称是mymaster
后面的2的含义是至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移

sentinel down-after-milliseconds mymaster 30000	
#113行，判定服务器down掉的时间周期，默认30000毫秒（30秒）

sentinel failover-timeout mymaster 180000		
#146行，故障节点的最大超时时间为180000（180秒）

启动哨兵模式后台运行，先启动主节点，后期的从节点
cd /opt/redis-5.0.7
redis-sentinel sentinel.conf &

使用netstat检查redis有没有启动
netstat -antlp|grep redis

查看哨兵信息

redis-cli -p 26379 info Sentinel

故障模拟

查看redis-server进程号
ps -ef | grep redis
kill -9 11041

查看日志
tail -f /var/log/sentinel.log

去新的主节点192.168.88.90确认

redis-cli -p 26379 info sentinel

旧的主节点要修改配置文件/etc/redis/6379.conf,第288行要改成新的主节点地址

vim /opt/redis-5.0.7/sentinel.conf
replicaof 192.168.88.90 6379        #288行，指定要同步的Master节点IP和端口

四，Redis 群集模式

集群，即Redis Cluster，是Redis 3.0开始引入的分布式存储方案。

集群由多个节点(Node)组成，Redis的数据分布在这些节点中。集群中的节点分为主节点和从节点：只有主节点负责读写请求和集群信息的维护；从节点只进行主节点数据和状态信息的复制。

1.集群的作用

1.1数据分区：

数据分区(或称数据分片)是集群最核心的功能。

集群将数据分散到多个节点，一方面突破了Redis单机内存大小的限制，存储容量大大增加；另一方面每个主节点都可以对外提供读服务和写服务，大大提高了集群的响应能力。

Redis单机内存大小受限问题，在介绍持久化和主从复制时都有提及；例如，如果单机内存太大，bgsave和bgrewriteaof的fork操作可能导致主进程阻塞，主从环境下主机切换时可能导致从节点长时间无法提供服务，全量复制阶段主节点的复制缓冲区可能溢出。

1.2高可用：

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

2.Redis集群的数据分片

Redis集群引入了哈希槽的概念

Redis集群有16384个哈希槽（编号0-16383）

集群的每个节点负责一部分哈希槽

每个Key通过CRC16校验后对16384取余来决定放置哪个哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作

3.Redis 集群的主从复制模型

在 Redis 集群中，每个主节点（Master）通常会有一个或多个从节点（Slave）。这些从节点会对主节点进行 复制（Replication），确保在主节点发生故障时，可以通过选举从节点来替代主节点，以保持集群的可用性。

3.1集群的用处

（1）数据分区（数据分片）

数据分区是集群技术中最基本也是最重要的功能之一。在Redis集群中，数据被分散存储到多个节点上，每个节点负责存储整个数据集的一个子集。这种设计带来了几个显著的优势：

突破单机内存限制：单个Redis实例受限于其所在服务器的物理内存大小。通过集群，可以将数据分散到多台服务器上，从而有效地扩展Redis的存储容量，使其能够处理更大规模的数据集。
提高并发处理能力：在集群中，每个节点都可以独立地处理读写请求，这大大增加了系统的并发处理能力。当多个客户端同时访问Redis时，请求可以被分散到不同的节点上进行处理，从而减少了单个节点的负载压力。
负载均衡：集群可以自动或手动地实现负载均衡，确保各个节点的负载相对均衡，避免某些节点过载而其他节点空闲的情况。

（2）高可用

高可用是集群技术的另一个重要目标。Redis集群通过支持主从复制和自动故障转移机制，确保了系统的高可用性：

主从复制：在Redis集群中，每个主节点都有一个或多个从节点与之对应。主节点负责处理写请求，并将数据变更同步到其从节点。从节点则负责处理读请求，并提供数据冗余备份。这种主从复制机制不仅提高了读请求的处理能力，还增强了数据的可靠性。
自动故障转移：当主节点发生故障时（如宕机、网络问题等），集群能够自动检测到这一故障，并触发故障转移过程。在故障转移过程中，集群会选举一个从节点作为新的主节点，并重新配置集群的拓扑结构。这样，即使某个节点发生故障，集群仍然能够继续对外提供服务，保证了系统的高可用性。

3.2Redis集群的数据分片

Redis集群通过引入哈希槽（hash slot）的概念来实现数据的分片。整个Redis集群被划分为16384个哈希槽，每个槽编号从0到16383。集群中的每个节点都会负责一部分哈希槽，即每个节点会存储并管理一部分数据。

当客户端需要存取数据时，Redis会根据数据的key来计算一个CRC16校验和，并对16384取余，得到的结果就是一个哈希槽编号。这个编号用于确定数据应该存储在哪个节点上，或者应该从哪个节点上检索数据。这样，客户端就可以直接与存储数据的节点进行通信，而不需要经过其他节点转发，大大提高了数据存取的效率。

(1)假设集群有三个节点组成，各个节点哈希槽范围是：

节点A包含0~5460号哈希槽
节点B包含5461~10922号哈希槽
节点C包含10923~16383号哈希槽

3.3Redis集群中主从复制模型故障

假设集群中有A、B、C三个节点，假设节点B****服务器出现故障，整个集群就会因缺少5461-10922这个范围的哈希槽无法用。 为每个节点添加一个从节点A1、B1、C1整个集群便有三个Master节点和三个slave节点组成，当节点B****服务器出现故障后，集群选举B1位为的新的主节点继续服务。当B和B1都失败后，集群将不可用。

4.Redis 群集模式配置

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

开启群集功能：
其他节点也要配，端口号注意
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行，开启守护进程，以独立进程启动
appendonly yes							          #699行，修改，开启AOF持久化
cluster-enabled yes				 	          #832行，取消注释，开启群集功能
cluster-config-file nodes-6001.conf		#840行，取消注释，群集名称文件设置
cluster-node-timeout 15000				    #846行，取消注释群集超时时间设置


启动redis节点
进入六个节点文件夹，执行命令：redis-server redis.conf ，启动redis节点
redis-server redis.conf
或者
cd /etc/redis/redis-cluster/redis6001
for d in {1..6}
do
cd /etc/redis/redis-cluster/redis600$d
redis-server redis.conf
done
查看redis进程
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
用六台机器的话127.0.0.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"