Redis的哨兵集群(一主两从三哨兵、部署教程和知识总结)

自己写的笔记，收藏就完事了，以后实战或者面试肯定用得到，hhh

Ps: 如果对Redis搭建不熟悉,可以看我之前的一个博客: Redis的单机部署(Linux环境)-CSDN博客

一、哨兵机制

1.1 主要功能:

故障检测：哨兵定期检查主服务器（master）和从服务器（slaves）是否正常工作。它通过发送命令并等待响应来检测服务器是否在线且运行正常。如果某个服务器未能正确响应，哨兵会认为该服务器是处于下线状态。
自动故障转移：如果主服务器发生故障，哨兵会自动进行故障转移操作。它会从现有的从服务器中选举出一个新的主服务器，并指示其他从服务器改变同步方向，同步新的主服务器的数据。这样能确保系统的快速恢复和数据的最大程度保存。
配置提供者：哨兵还充当配置提供者的角色。客户端可以询问哨兵当前哪个是主服务器，从而连接到正确的服务器进行读写操作。
通知：哨兵可以在检测到故障或其他重要事件时通过API向管理员或其他应用发送通知。

1.2 哨兵的工作原理：

监控：哨兵会监控所有的 Redis 主从服务器实例，检查它们的健康状态。
选举：如果主服务器无法响应，哨兵之间会进行选举，决定哪一个哨兵负责执行自动故障转移。
故障转移：负责故障转移的哨兵会自动选择一个从服务器，提升为新的主服务器，并配置其他从服务器重新指向这个新的主服务器。

二、准备部署环境

2.1 配置信息


服务类型	IP地址	端口
Redis (Master)	192.168.195.59	6379 (默认)
Redis (Slave)	192.168.195.60	6379
Redis (Slave)	192.168.195.61	6379
Sentinel	192.168.195.59	26379 (默认)
Sentinel	192.168.195.60	26379
Sentinel	192.168.195.61	26379

Ps:

1、采用一主两从三哨兵方案部署, 因虚拟机资源有限3台哨兵搭建和Redis搭再同一台机器上, 建议生产环境使用不同的机器部署, 防止单点故障问题。

2、通常建议至少部署三个哨兵实例，这样即使一个哨兵实例发生故障，其他两个可以继续进行故障检测和转移决策。

三、Redis主从集群搭建

Ps: 再搭建哨兵集群之前,需要先部署一个主从的一个Redis集群,下面是部署一主两从的一个集群搭建过程。

3.1 在三台机器上分配安装Redis服务

这里就简单说一下过程, 详细安装方式可以参照: Redis的单机部署(Linux环境)-CSDN博客

1.下载Redis的安装包

2.解压安装包并进行make编译

3.对配置文件redis.conf 进行修改

4.启动Redis服务,指定配置文件

3.2 集群的相关配置修改

1.首先对主节点的配置文件进行修改

#设置主节点访问密码
#命令解释:把 masterauth Test2024 添加在 bind ip 内容的下两行 
sed -i "/^bind .*/a\\ \n\\masterauth Test2024" redis_conf

(1). 这里解释一下为啥主节点自己也要配置密码呢? 因为当主节点发生故障后,哨兵把其他机器选举为主节点, 该机器恢复正常后要加入集群就需要该密码配置了. 其次建议Redis的密码都设置一样,避免其他的错误出现。

2.从节点的配置文件修改

下面设置从节点Redis配置文件, 登录到192.168.195.60和192.168.195.61这两台机器上并修改

他们的配置文件内容。

# 设置主节点IP地址,并且保证他们之间的网络通畅
sed -i "/^bind .*/a\\ \n\\slaveof 192.168.195.59 6379" redis_conf

#设置主节点Redis的访问密码
sed -i "/^bind .*/a\\ \n\\masterauth Test2024" redis_conf

PS: 必须要保证几台机器的网络畅通,并且可以访问到彼此的Redis服务。

3.3. 完成上述修配置文件修改后, 对Redis进行重启

PS: 当然按先主后从顺序进行重启

# 按先主后从顺序进行重启, 三台机器重启完成后,使用客户端工具redis-cli 登录到Redis

#cd 到你的Redis目录下,登录Redis
./src/redis-cli -p 6379 -a Test2024

3.4 使用 info Replication 命令查看Redis的信息,

1.可以看到已经有两个节点连接上了该主节点

2.可以在主节点新增一个key-value

#设置key-value
set name zhangsan

#获取key-value 在从节点机器登录上Redis查看数据有没有同步过来
get name

以上就基本完成了一主两从的环境搭建,可以开始搭建哨兵来监控主节点了

四、哨兵集群搭建

4.1 修改哨兵的配置文件

对三台机器上的哨兵配置文件进行修改,内容如下

#cd 至redis的安装目录
cd /usr/local/redis-6.0.10

#创建哨兵的工作目录
mkdir -p /usr/local/redis-6.0.10/redis-sentinel-working

#可自行vi命令编辑 sentinel_conf 

#配置哨兵的工作目录
sed -i "s/^dir .*/dir /usr/local/redis-6.0.10/redis-sentinel-working /"  sentinel_conf

#配置哨兵的日志文件
sed -i "s/^logfile .*/logfile  /usr/local/redis-6.0.10/redis-sentinel.log /" sentinel_conf

#配置哨兵的端口号 配置文件中默认就是26379 
sed -i "s/^port .*/port 26379 /" sentinel_conf

#设置主节点ip 端口 mymaster 192.168.195.59 6379 2 
sed -i "s/^sentinel monitor .*/sentinel monitor mymaster 192.168.195.59 6379  2 /" sentinel_conf

#设置redis访问密码
sed -i "/^sentinel monitor .*/a\\ \n\\sentinel auth-pass mymaster Test2024" sentinel_conf

PS: 解释一下sentinel monitor 这个参数

1. mymaster 是主节点的名称, 我这里是采用Redis推荐的默认值, 如果修改的话, 要注意其他位置同步修改。

2. ip port 这个就是主节点的Redis的IP和端口。

3.结尾是一个2表示至少需要有 2 个哨兵同意主节点已经下线，才会启动自动故障转移过程。要根据哨兵数量来设置,默认值是2,过少可能会误判,过高则可能在部分哨兵失效时无法执行故障转移。一般推荐的设置是部署哨兵总数的一半加一，以确保故障转移的决策得到多数哨兵的支持。

4.2 启动哨兵服务

当三台机器的哨兵配置完成后,就可以启动哨兵来监控我们的主从集群了

1.第一种方式使用命令去启动哨兵

#切换至redis目录
ca /usr/local/redis-6.0.10

#自行启动时如果没用修改后台运行的那个参数daemonize 可以像redis一样启动时指定
./src/redis-sentinel ./redis.conf --daemonize yes

#关闭哨兵服务, 这里是使用redis客户端工具进行关闭 需要指定关闭的端口号,不然默认关闭Redis服务
./src/redis-cli -p 26379 shutdown

2.第二种方式把哨兵服务交给系统服务去管理(原理和之前Redis一样)

#1.在Systemd服务单元文件中设置ExecStart

cat <<EOF | sudo tee /etc/systemd/system/redis-sentinel.service > /dev/null
[Unit]
Description=redis-sentinel
After=network.target

[Service]
ExecStart=/usr/local/redis-6.0.10/src/redis-sentinel /usr/local/redis-6.0.10/sentinel.conf
ExecStop=/usr/local/redis-6.0.10/src/redis-cli -p 26379 shutdown
Restart=always
RestartSec=30

[Install]
WantedBy=multi-user.target
EOF

#2.重新加载Systemd管理的所有服务
sudo systemctl daemon-reload

#3.启用Redis服务
systemctl enable redis-sentinel.service

#4.启动Redis服务
systemctl start redis-sentinel

#5.查看哨兵运行信息
systemctl status redis-sentinel

PS: 执行过程中发现一个小错误, 系统进程启动哨兵后却发现没用启动成功, 下面是哨兵的日志,大概意思是启动完了又被关闭了。

原因是: 我把哨兵的配置文件的daemonize参数设置为了yes, 也就是后台启动,导致了我使用系统服务去启动哨兵会出现上述情况。

解决方案: 把配置文件修改为no,再次尝试系统服务启动哨兵,就解决了问题。

使用客户端工具登录或直接查看哨兵的信息

#切换目录
cd /usr/local/redis-6.0.10

#登录到哨兵 #在执行命令: info Sentinel 查看哨兵信息
./src/redis-cli -p 26379

#或者直接查看信息命令
./src/redis-cli -p 26379 info Sentinel

可以看出哨兵集群的个数为1了.

同理把三台机器的哨兵服务都启动成功就ok了, 以上基本就搭建完了哨兵集群了

PS: 这里再学习的时候遇到一个坑,就是哨兵节点都配置并启动了,但是查询哨兵信息仍然只有一个，排查了很久才解决，后续再分享一下这个坑吧。

下面是完成了哨兵集群搭建的结果

五、验证哨兵的选举机制

5.1 模拟Master节点宕机

1. 使用系统服务关闭 192.168.195.59 机器上的Redis服务

#这样关闭redis服务,即使设置了保活Redis 也不会自动重启服务
systemctl stop redis

2.查看哨兵日志, 开始选举新的节点了

3.查看192.168.195.60机器的redis信息, 发现192.168.195.61机器被选举为新的Master

4.再次把原主节点(192.168.195.59)的Redis启动, 查看哨兵日志。

发现这台机器也重新加入集群了, 但是变成了slave的角色了。(这里重新上线需要在配置文件中加上主节点的密码, 之前搭建主从的时候, 就提前把所有节点都配置上masterauth就好了)

5.2 故障转移成功后通知节点更新配置文件

1.上面模拟了Master宕机情况,查看Redis的配置文件

这台 195.168.195.59 机器原先为主节点, 当重新加入集群时候,配置问价末尾自动追加了主节点的IP信息

另外两台机器的配置文件也都自动更新主节点信息。

2.哨兵的配置文件也做了自动更新

GPT3.5的回答如下:

六、总结

6.1 优点

自动故障转移：

Sentinel 能自动检测主节点和从节点的故障，并自动将从节点升级为新的主节点，从而保证服务的连续性和可用性。

分布式监控：
- Sentinel 可以以分布式方式运行，多个 Sentinel 实例之间会相互通信，共同决定是否需要进行故障转移。这增强了系统的健壮性和故障容忍能力。
服务发现：
- Sentinel 也承担配置提供者的角色，客户端可以查询 Sentinel 获取当前的主节点地址，这使得客户端总是连接到正确的主节点。
可配置性：
- Sentinel 提供了多种配置选项，允许管理员根据具体需求调整故障检测的灵敏度、故障转移的行为等。
通知：
- Sentinel 支持通过各种方式通知管理员，例如发送邮件、执行脚本等，当监测到故障或者其他重要事件时。