目录
在分布式系统架构中,Redis作为高性能键值存储中间件,其可用性直接影响业务稳定性。然而,单节点 Redis 存在服务单点风险,一旦宕机将导致缓存层失效,进而可能引发级联故障。Redis 哨兵模式(Sentinel)通过引入轻量级的监控与自动故障转移机制,有效解决了这一问题。
一. 介绍
在一主多从的 Redis 架构中,从节点可以起到数据冗余备份和读写分离的作用。如果主节点遇到故障导致无法提供服务时,可以采用手动方式将其一个从节点提升为主节点,保证 Redis 主从能够正常工作。主从切换通过手动完成比较耗时、费力,并且影响 Redis 正常服务。为此,Reids 提供了哨兵功能,实现了自动化的系统监控和故障恢复功能。
1. 概述
哨兵(Sentinel),主要负责监控主从节点运行是否正常,以及当主节点出现故障时自动将一个从节点转换为新的主节点。哨兵是一个独立的进程。,最基础的通用哨兵架构:
哨兵最基础架构由两部分组成,包括哨兵节点和数据节点。其中,哨兵节点是特殊的 Redis 节点,并不存储数据,出于高可用方面考虑,哨兵架构中通常都是多个哨兵节点共同提供服务。数据节点用于存储 Redis 数据。包括主节点和从节点。
2. 实现原理
哨兵节点的配置文件中需要添加配置:
sentinel monitor master-name IP port quorum
其中,sentinel monitor 是配置哨兵的命令,接着是主节点的名称、IP 地址和端口号,最后的 quorum 用来表示执行故障恢复操作之前至少需要几个哨兵节点同意。一个哨兵节点可以同时监控多个 Reids 主从系统,多个哨兵节点也可以同时监控同一个 Redis 主从系统。
配置修改好之后,就可以启动哨兵节点了。当哨兵节点启动时,会与要监控的主数据库(master)建立连接,连接建立之后,哨兵会定时地执行以下3个任务:
- (1)每 10 秒哨兵会向主节点和从节点发送 info 命令
- (2)每2秒哨兵会向主节点和从节点发送自己的信息。
- (3)每1秒哨兵会向主节点、从节点和其他哨兵发送 ping 命令。
这3个定时任务贯穿哨兵进程的整个生命周期,非常重要。
当哨兵节点启动后,会向主节点发送info命令,通过解析返回的结果可以获得从节点的列表,然后与每个从节点建立连接。
之后,哨兵会每隔 10 秒定时向所有已知主从节点发送 info 命令来获取西悉尼更新并进行相应的操作。
接下来哨兵会向主从节点发送信息与同样监控主从节点的哨兵分享自己的信息。当其他哨兵节点收到信息后,会判断发送信息的哨兵是不是新发现的哨兵,如果是则将其加入已发现的哨兵列表中并创建到该节点的连接,这样就实现了自动发现从节点和其他哨兵节点。
之后哨兵要做的就是监控主从节点是否停止服务,通过发送ping 命令来实现的。
ping 命令是每隔1秒发送一次,如果被 ping 的节点超时一定的时间没有回复,哨兵就会认为其主观下线,是哨兵节点“主观地”判断下线。
如果该节点是主节点,则哨兵会进一步判断是否需要对其进行故障恢复,具体过程如下,该哨兵节点会询问其他哨兵节点来了解它们是否也认为该主节点已经主观下线,如果达到指定数量,则哨兵会认为其客观下线,此时各哨兵节点会进行协商,选举出一个领导者哨兵节点,并由该领导者哨兵节点对其进行故障转移操作。
注意:客观下线是主节点才有的概念,如果从节点和哨兵节点发生故障,被哨兵主观下线后,不会再有后续的客观下线和故障转移操作。
领导者哨兵节点执行故障恢复可以保证同一时间内只有一个哨兵节点在执行故障恢复,避免多个节点同时操作。选举领导者哨兵的过程适用了 Raft 算法,具体的过程如下:
- (1)发现主节点客观下线的哨兵节点(简称为A)向每个哨兵节点发送命令要求对方选自己成为领导者哨兵。
- (2)如果目标哨兵节点没有选过其他哨兵,则会同意将A设置为领导者哨兵。
- (3)如果A发现有超过一半并且超过 quorum 参数值的哨兵节点同意选自己成为领导者哨兵,那么A将成为领导者哨兵。
- (4)当有多个哨兵同时参选时,有可能会出现没有任何节点当选的可能。如果出现此种情况,那么会等待一个随机时间重新开始下一轮参选,直到选出领导者哨兵为止。
选出领导者哨兵后,令领导者哨兵会对主节点进行故障转移恢复。恢复过程可以分为3个步骤:
- (1)在所有从节点中挑选一个节点作为新的主节点。挑选的基准是,首先过滤掉不健康的从节点;然后选择优先级最高的从节点;如果优先级无法区分,则选择赋值偏移量最大的从节点,如果仍无法区分,则选择runid 最小的从节点。
- (2)更新主从状态。通过 slaveof no one 命令,让选出来的从节点成为主节点通过 slaveof 命令让其他节点成为其从节点。
- (3)将已经停止服务的旧的主节点更新为新的主节点的从节点,当此节点恢复后,能够自动以从节点的身份继续服务。
二. 配置环境
环境
操作系统 | IP | 主机名 | 角色 |
Open Euler | 192.168.10.101 | master | 主节点 |
Open Euler | 192.168.10.102 | slave1 | 从节点 |
Open Euler | 192.168.10.103 | slave2 | 从节点 |
Open Euler | 192.168.10.104 | sentinel1 | 哨兵节点 |
Open Euler | 192.168.10.105 | sentinel2 | 哨兵节点 |
Open Euler | 192.168.10.106 | sentinel3 | 哨兵节点 |
关闭防火墙
修改主机名 分别是master、slave1、slave2、setninel1、setninel2、setninel3
三. 部署redis主从
1. 部署redis服务
master、slave1、slave2节点操作
make && make PREFIX=/usr/local/redis install 只是安装了二进制文件到系统中,并没有启动脚本和配置文件。Redis提供了默认的配置文件,将配置文件复制到/etc/目录下,然后编写服务脚本用于启动 Redis 及设置开机启动。当Redis 启动完成后,默认监听 6379 端口。
创建配置文件目录 适用默认配置文件
2. 编写服务脚本
3. 修改配置文件
默认在75行 进行修改 加入监听地址 三个节点都添加自己网卡的IP地址
257行进行修改 启用守护进程
302行添加 日志文件
启动服务
查看监听端口
4. 主从配置
在所有的从节点上操作,slave1、slave2在478行添加主库的IP和端口
5. 验证主从
主节点
从节点
四. 部署哨兵节点
3台哨兵节点的配置一样
编写服务脚本
可在最后一行添加
- sentinel monitor:哨兵命令
- master:主节点名字
- 192.168.207.167 6379 2:主节点 IP 和端口,最后的2表示,当主节点出现故障,至少需要两个哨兵节点同意,才能判定主节点故障
修改配置文件
启动服务
查看进程
查看哨兵状态信息
故障转移
当主节点出现故障时,故障发现和转移是由哨兵来控制的,此时会将主节点切换到其他从节点上。
手动模拟主节点出现故障,停止主节点上的 Redis 服务。
关掉主节点之后,等待一会时间,再次在sentine101上查看哨兵系统状态将会发现,原来的主节点进行了切换。
当主节点进行切换后,一个从节点变成了主节点。此时从节点数量仍然是2,是因为在进行主从切换时,原来的故障的节点会被设置为新主的从节点,哨兵系统并不会对故障节点进行客观下线,而是认为该从节点一致存在。当故障修复之后,将会变为新的从节点投入适用。
查看哨兵epoch
对于哨兵节点,主要是epoch相关配置的变化,进行一次主从切换,epoch相关的参数都会加1
[root@sentinel1 ~]# tail -9 /etc/redis/6379.conf
纯命令
哨兵需要三台
修改主机名
hostnamectl set-hostname master
hostnamectl set-hostname slave1
hostnamectl set-hostname slave2
都安装
dnf -y install gcc
tar zxf redis-6.2
cd redis
make
make PREFIX=/usr/local/redis install
ln -s /usr/local/redis/bin/* /usr/local/bin/
mkdir /etc/redis
ls
cp /redis.conf /etc/redis/6379.conf
vim /etc/systemd/system/redis.service
[Unit]
Description=Redis
After=network.target
[Service]
Type=forking
ExecStart=/usr/local/redis/bin/redis-server /etc/redis/6379.conf
[Install]
WantedBy=multi-user.target
EOF
vim /etc/redis/6379.conf
bind 127.0.0.1 192.168.10.101 三台分别监听的地址 102,103
daemonize yes
logfile "/var/log/redis_6379.log"
systemctl daemon-reload
systemctl start redis
netstat -anpt | grep redis
systemctl enable redis
设置为主从
在slave1、2上添加东西
vim /etc/redis/6379.conf
replicaof 192.168.10.101 6379 478行
systemctl restart redis
验证
主和从
redis-cli
info replication
//slaveof 192.168.10.101 6379 可以将主该为从
10秒 主和从 info命令
2秒
1秒 每1秒向所有的节点发送ping命令
3个哨兵
(1)每 10 秒哨兵会向主节点和从节点发送 info 命令
(2)每2秒哨兵会向主节点和从节点发送自己的信息。
(3)每1秒哨兵会向主节点、从节点和其他哨兵发送 ping 命令。
部署哨兵
dnf -y install gcc
tar zxf redis-6
cd redis-6
make
make PREFIX=/usr/local/redis install
ln -s /usr/local/redis/bin/* /usr/local/bin/
mkdir /etc/redis
cp redis.conf /etc/redis/6379.conf
vim /etc/redis/6379.conf
bind 0.0.0.0 监听所有75行
daemonize yes 启用守护进程257行
sentinel monitor master 192.168.10.101 6379 2 可以在末尾添加
vim /lib/systemd/redis.service
[Unit]
Description=Redis
After=network.target
[Service]
Type=forking
ExecStart=/usr/local/redis/bin/redis-sentinel /etc/redis/6379.conf
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl start redis
netstat -anpt | grep redis
redis-cli
info sentinel
故障测试
停止主节点
systemctl stop redis
再次查看哨兵
info sentinel
发现故障时会自动转移主节点