1、什么是redis-sentinel,和redis主从复制相比,它具有什么优势
1.1、redis主从复制
Redis主从复制是一种用于数据冗余和可伸缩性的机制,它将一台Redis服务器的数据复制到其他Redis服务器。在这种模式下,数据会实时地从一个主节点(Master)同步到一个或多个从节点(Slave)。
然而,单纯的redis主从复制存在一个明显的缺点------即当主节点(Master)发生故障不可用时,尽管数据因为实时的进行复制而不会丢失(或者丢失极少),但将从节点(Slave)升级为主节点(Master)需要人工介入,手动进行切换。因此,这不但增加了运维的人工成本,并且还无法保障业务连续性。综上,这也是redis主从复制作为redis的冗余方案之一,最大的一个制约因素。
1.2、redis-sentinel的优势
Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案,从本质上来说,Redis-Sentinel是一个独立运行的进程,专门用于监控Redis集群中的主从节点。当主节点(Master)出现故障时,Redis-Sentinel能够自动选择并提升一个从节点(Slave)为新的主节点,以保证服务的持续可用性,Redis-Sentinel通过心跳机制检测节点的运行状态,并使用投票算法进行故障判断和主备切换决策。所以,redis-sentinel方案解决的是redis主从复制无法自动进行主从切换(故障转移)的问题。
2、搭建示例
2.1、实验拓扑
2.2、实施步骤
2.2.1、部署"一主二从"式的redis主从复制架构
【redis-master节点(操作系统为OpenEuler-22.03 -LTS-SP2)】
1、通过命令"yum install redis
"安装redis;
2、通过命令"systemctl status redis
"查看redis状态,保证安装完成后redis进程处于关闭的状态;
3、通过命令"touch /etc/redis-master.conf
"创建一个配置文件,并在配置文件中输入以下内容:
bash
port 6379
daemonize yes
pidfile "/var/run/redis_6379.pid"
logfile "/var/log/redis_6379.log"
dir "/var/lib/redis"
# 开启持久化
save 900 1
save 300 10
save 60 10000
# 关闭保护模式
protected-mode no
# 绑定IP地址
bind 127.0.0.1 192.168.174.136
配置文件内容的含义如下:
【redis-slave节点(操作系统为OpenEuler-22.03 -LTS-SP2)】
1、通过命令"yum install redis
"安装redis;
2、通过命令"systemctl status redis
"查看redis状态,保证安装完成后redis进程处于关闭的状态;
3、通过命令"touch /etc/redis-master.conf
"创建一个配置文件,并在配置文件中输入以下内容(与Master节点的配置文件相比,绝大部分内容一样,只是绑定的IP地址不同,且多出了一个slaveof参数用于指向Master节点的IP地址,代表自己是slave节点):
bash
port 6379
daemonize yes
pidfile "/var/run/redis_6379.pid"
logfile "/var/log/redis_6379.log"
dir "/var/lib/redis"
# 开启持久化
save 900 1
save 300 10
save 60 10000
# 关闭保护模式
protected-mode no
# 绑定IP地址
bind 127.0.0.1 192.168.174.131
#指定主节点
slaveof 192.168.174.136 6379
【redis-slave节点(操作系统为OpenEuler-22.03 -LTS-SP2)】
1、通过命令"yum install redis
"安装redis;
2、通过命令"systemctl status redis
"查看redis状态,保证安装完成后redis进程处于关闭的状态;
3、通过命令"touch /etc/redis-master.conf
"创建一个配置文件,并在配置文件中输入以下内容(与Master节点的配置文件相比,绝大部分内容一样,只是绑定的IP地址不同,且多出了一个slaveof参数用于指向Master节点的IP地址,代表自己是slave节点):
bash
port 6379
daemonize yes
pidfile "/var/run/redis_6379.pid"
logfile "/var/log/redis_6379.log"
dir "/var/lib/redis"
# 开启持久化
save 900 1
save 300 10
save 60 10000
# 关闭保护模式
protected-mode no
# 绑定IP地址
bind 127.0.0.1 192.168.174.130
#指定主节点
slaveof 192.168.174.136 6379
2.2.2、部署redis-sentinel节点
【redis-sentinel节点(操作系统为debian-12)】
1、通过命令"apt install redis-sentinel
"安装redis-sentinel(debian系Linux的redis-sentinel都需要单独进行安装,而红帽系Linux系统中的redis-sentinel已经集成在redis安装包及其依赖中,无需单独安装 );
2、通过以下命令创建"redis-sentinel-1.conf 、redis-sentinel-2.conf 、redis-sentinel-3.conf"三个配置文件:
bash
touch /etc/redis-sentinel-1.conf
touch /etc/redis-sentinel-2.conf
touch /etc/redis-sentinel-3.conf
3、在三个配置文件中分别加入以下内容(3个文件除端口号、进程文件名和日志文件名设定不同,其余配置一样):
【redis-sentinel-1.conf】
bash
port 26379
daemonize yes
pidfile /var/run/redis-sentinel-1.pid
logfile /var/log/redis-sentinel-1.log
dir /var/lib/redis
# 监控主服务器
sentinel monitor mymaster 192.168.174.136 6379 2
# 判断主服务器下线的时间
sentinel down-after-milliseconds mymaster 10000
# 故障转移的超时时间
sentinel failover-timeout mymaster 10000
# 在执行故障转移时,最多可以有多少个从服务器同时对新的主服务器进行同步
sentinel parallel-syncs mymaster 1
【redis-sentinel-2.conf】
bash
port 26380
daemonize yes
pidfile /var/run/redis-sentinel-2.pid
logfile /var/log/redis-sentinel-2.log
dir /var/lib/redis
# 监控主服务器
sentinel monitor mymaster 192.168.174.136 6379 2
# 判断主服务器下线的时间
sentinel down-after-milliseconds mymaster 10000
# 故障转移的超时时间
sentinel failover-timeout mymaster 10000
# 在执行故障转移时,最多可以有多少个从服务器同时对新的主服务器进行同步
sentinel parallel-syncs mymaster 1
【redis-sentinel-3.conf】
bash
port 26381
daemonize yes
pidfile /var/run/redis-sentinel-3.pid
logfile /var/log/redis-sentinel-3.log
dir /var/lib/redis
# 监控主服务器
sentinel monitor mymaster 192.168.174.136 6379 2
# 判断主服务器下线的时间
sentinel down-after-milliseconds mymaster 10000
# 故障转移的超时时间
sentinel failover-timeout mymaster 10000
# 在执行故障转移时,最多可以有多少个从服务器同时对新的主服务器进行同步
sentinel parallel-syncs mymaster 1
2.2.3、启动相关服务
1、依次在对应节点输入以下命令来启动服务:
【redis-master节点】
bash
redis-server /etc/redis-master.conf &
【两个redis-slave节点】
bash
redis-server /etc/redis-slave.conf &
【redis-sentinel节点】
bash
redis-sentinel /etc/redis/redis-sentinel-1.conf &
redis-sentinel /etc/redis/redis-sentinel-2.conf &
redis-sentinel /etc/redis/redis-sentinel-3.conf &
3、分别在以下节点验证主从复制和redis-sentinel是否正常
【redis-master节点】
通过命令"netstat -lnpt | grep 6379
"查看端口监听状态:
通过命令"redis-cli -p 6379 info replication
"查看主节点(Master)是否发现了两个从节点(Slave):
【两个redis-slave节点】
通过命令"netstat -lnpt | grep 6379
"查看端口监听状态:
通过命令"redis-cli -p 6379 info replication
"查看从节点(Master)指向的主节点(Master)信息和状态:
【redis-sentinel节点】
通过命令"netstat -lnpt
"查看端口监听状态:
通过命令"redis-cli -p 26379 info sentinel
"查看当前sentinel进程的节点监控信息(-p参数下除26379端口外,也可以设置为26380和26381端口):
3、验证数据同步和故障转移
3.1数据同步
在Master节点进行如下操作:
分别查看两个slave节点:
3.2、验证故障转移
在Master节点上输入命令"killall redis-server
"杀死redis-server进程:
在sentinel节点上输入命令"redis-cli -p 26379 info sentinel
"查看Master节点的自动变化情况:
需要注意的是,如果此时原有的136节点恢复了正常服务,它会变为当前主节点(130节点)的从节点,而不会抢占为主节点。
在redis主从复制中,某个节点是主节点还是从节点,是由配置文件的内容决定的,而当主节点故障发生时,人工干预的方式是去修改配置文件,redis-seninel只是将这一过程有监听程序自动化了,而不需要人工干预,通过查看136节点(原来的主节点)的配置文件,我们可以看到这个过程:
4、实验注意事项
4.1、各个节点之间的redis版本必须严格保持一致
各个节点之间的redis版本必须严格保持一致,如果不一致,例如redis4和redis5之间构成了一个redis-sentinel架构,虽然无故障发生时,数据同步时正常的,但故障发生后,重新启用故障节点的进程,该节点就会出现数据无法恢复的情况,也无法通过同步复制写入新的数据。通过查看相关日志(对应redis节点配置文件中logfile参数所定义的日志文件),可以发现是因为版本之间的不兼容,导致RDB文件中的数据无法被正确读取和恢复:
4.2、已知在OpenEuler系统中,哨兵模式无法转移故障的场景
通过在OpenEuler-22.03 -LTS-SP2实验中发现,如果redis-sentinel进程和redis主节点或从节点(redis-server进程)都在同一台服务器上,当人为将主节点上redis-server进程杀死时,尽管三个位于各自主从节点上的redis-sentinel进程都会各自将Master视作主观下线,但无法触发客观下线的投票,或故障转移的投票被否决,这会导致故障无法转移而业务中断。
当然这样的部署方式本身就存在不合理的地方,因为将redis-sentinel进程和redis-server进程部署在同一台服务器的做法无法发挥出该有的高可用特性,但在实验过程中,出现了这样的情况,暂不清楚其他的Linux系统和redis版本是否也会出现这样的现象。
5、相关知识
5.1、主观下线和客观下线
在Redis中,主观下线和客观下线是哨兵(Sentinel)机制中的两个重要概念,用于判断Redis实例(特别是主服务器)的健康状态和是否需要进行故障转移。
- 主观下线(Subjective Down,
SDOWN):是指某个哨兵节点独立地认为某个Redis实例(包括主服务器或从服务器)已经不可达; - 客观下线(Objective Down,
ODOWN):是指多个哨兵节点都认为某个Redis实例(特指主服务器)已经不可达,并且这一判断达到了法定人数(quorum)的要求(触发投票机制)。
在redis-sentinel的相关日志中,其实就可以看到redis-sentinel进程大量判断某个节点主观下线或者客观下线的相关记录:
5.2、redis的持久化
Redis 持久化是指将 Redis 内存中的数据存储到磁盘上,以确保在 Redis 服务器重启或发生其他故障时,数据不会丢失。Redis 提供了两种主要的持久化方式:RDB(Redis DataBase)和 AOF(Append Only File)。
【RDB 持久化】
RDB 持久化通过创建并保存 Redis 数据集的快照来工作。在指定的时间间隔内,执行数据集快照,并生成一个 .rdb 文件。Redis 重启时,通过加载这个 .rdb 文件来恢复数据。其具有以下特点:
- RDB 是一个紧凑的二进制文件,保存了 Redis 在某个时间点上的数据集。
- RDB 持久化非常适合用于备份,全量复制等场景。
- RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
- RDB 会丢失最后一次快照之后写入的数据。
【AOF 持久化】
AOF 持久化是通过保存 Redis 服务器所执行的写命令来记录数据库状态的。当 Redis 服务器重启时,会重新执行这些写命令来恢复数据。其具有以下特点:
- AOF 持久化以日志的形式记录 Redis 所执行的写命令,因此它可以保存更多的数据。
- AOF 文件的更新频率通常比 RDB 文件的更新频率高,因为 AOF 需要记录每条写命令。
- AOF 持久化的写入性能通常比 RDB 持久化低,因为需要记录每条写命令。
- AOF 持久化在数据恢复时,需要重放所有写命令,因此恢复速度通常比 RDB 慢。
- AOF 提供了三种不同的写回策略(always, everysec, no),可以根据应用的需求进行调整。