NoSQL子Redis哨兵
目录
一，介绍Redis哨兵
1，哨兵概述
二，哨兵的实现原理
1，哨兵的核心功能
2，哨兵的分布式协助机制
3，故障检测与判断机制
4，具体配置
三，配置redis哨兵
1，准备工作
2，环境搭建
3，部署redis主从
4，部署redis哨兵
一，介绍Redis哨兵
在一主多从的 Redis 架构中，从节点可以起到数据冗余备份和读写分离的作用。如果主节点遇到故障导致无法提供服务时，可以采用手动方式将其一个从节点提升为主节点，保证 Redis 主从能够正常工作。主从切换通过手动完成比较耗时、费力，并且影响 Redis 正常服务。为此，Reids 提供了哨兵功能，实现了自动化的系统监控和故障恢复功能。
1，哨兵概述
哨兵(Sentinel)，主要负责监控主从节点运行是否正常，以及当主节点出现故障时自动将一个从节点转换为新的主节点。哨兵是一个独立的进程，哨兵最基础架构由两部分组成，包括哨兵节点和数据节点。其中，哨兵节点是特殊的 Redis 节点，并不存储数据，出于高可用方面考虑，哨兵架构中通常都是多个哨兵节点共同提供服务。数据节点用于存储 Redis 数据。包括主节点和从节点。
二，哨兵的实现原理
Redis Sentinel（哨兵）是 Redis 的高可用性解决方案，用于监控、自动故障转移和配置管理。其核心原理涉及分布式协作、故障检测、选举机制和客户端通知等多个方面。
1，哨兵的核心功能
- 监控：哨兵持续检查主节点和从节点的状态（如是否在线、响应延迟），通过定期发送
PING命令并分析响应结果判断节点健康状况。
- 自动故障转移：当主节点不可用时，哨兵自动将一个从节点升级为新主节点，并重新配置其他从节点指向新主节点。
- 配置管理：哨兵作为客户端的服务发现中心，客户端通过连接哨兵获取当前主节点地址，当主节点发生变更时，哨兵会通知所有注册的客户端更新连接信息。
- 通知：哨兵在节点状态变化（如主节点下线、故障转移完成）时发送事件通知，支持自定义脚本触发告警。
2，哨兵的分布式协助机制
哨兵通常以集群模式部署（推荐至少 3 个节点）
- 节点发现与连接建立
- 启动时发现
每个哨兵通过配置文件指定初始监控的主节点地址（如redis-sentinel.conf中的sentinel monitor mymaster 127.0.0.1 6379 2）。
- 运行时发现
哨兵之间通过发布 / 订阅机制（__sentinel__:hello频道）交换信息，自动发现其他哨兵节点和从节点。
- 连接拓扑
每个哨兵与监控的主从节点建立 TCP 连接（用于发送命令和接收状态）。哨兵之间也建立 TCP 连接（用于消息交换和协作决策）。
3，故障检测与判断机制
哨兵会向主从节点发送信息与同样监控主从节点的哨兵分享自己的信息。当其他哨兵节点收到信息后,会判断发送信息的哨兵是不是新发现的哨兵，如果是则将其加入已发现的哨兵列表中并创建到该节点的连接,这样就实现了自动发现从节点和其他哨兵节点。
之后哨兵要做的就是监控主从节点是否停止服务，通过发送ping命令来实现的。
ping 命令是每隔1秒发送一次，如果被 ping 的节点超时一定的时间没有回复，哨兵就会认为其主观下线，是哨兵节点“主观地”判断下线。
如果该节点是主节点，则哨兵会进一步判断是否需要对其进行故障恢复，具体过程如下:该哨兵节点会询问其他哨兵节点来了解它们是否也认为该主节点已经主观下线，如果达到指定数量，则哨兵会认为其客观下线，此时各哨兵节点会进行协商，选举出一个领导者哨兵节点，并由该领导者哨兵节点对其进行故障转移操作。
领导者哨兵节点执行故障恢复可以保证同一时间内只有一个哨兵节点在执行故障恢复，避免多个节点同时操作。选举领导者哨兵的过程适用了 Raft 算法，具体的过程如下:
- 发现主节点客观下线的哨兵节点(简称为A)向每个哨兵节点发送命令要求对方选自己成为领导者哨兵。
- 如果目标哨兵节点没有选过其他哨兵，则会同意将A设置为领导者哨兵。
- 如果A发现有超过一半并且超过 quorum 参数值的哨兵节点同意选自己成为领导者哨兵，那么A将成为领导者哨兵。
- 当有多个哨兵同时参选时，有可能会出现没有任何节点当选的可能。如果出现此种情况，那么会等待一个随机时间重新开始下一轮参选，直到选出领导者哨兵为止。
选出领导者哨兵后，领导者哨兵会对主节点进行故障转移恢复。恢复过程可以分为以下3个步骤:
- 在所有从节点中挑选一个节点作为新的主节点。挑选的基准是，首先过滤掉不健康的从节点;然后选择优先级最高的从节点:如果优先级无法区分，则选择赋值偏移量最大的从节点，如果仍无法区分，则选择 runid 最小的从节点。
- 更新主从状态。通过 slaveof no one 命令，让选出来的从节点成为主节点,通过 slaveof 命令让其他节点成为其从节点。
- 将已经停止服务的旧的主节点更新为新的主节点的从节点，当此节点恢复后，能够自动以从节点的身份继续服务。
注意：客观下线是主节点才有的概念，如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。
4，具体配置
哨兵节点的配置文件中需要添加如下配置：
sentinel monitor master-anme ip port quorum
其中，sentinel monitor 是配置哨兵的命令，接着是主节点的名称、IP 地址和端口号，最后的 quorum 用来表示执行故障恢复操作之前至少需要几个哨兵节点同意。一个哨兵节点可以同时监控多个Reids 主从系统，多个哨兵节点也可以同时监控同一个 Redis 主从系统。
配置修改好之后，就可以启动哨兵节点了。当哨兵节点启动时，会与要监控的主数据库(master)建立连接，连接建立之后，哨兵会定时地执行以下3个任务:
- (1)每 10 秒哨兵会向主节点和从节点发送 info 命令。
- (2)每2秒哨兵会向主节点和从节点发送自己的信息。
- (3)每1秒哨兵会向主节点、从节点和其他哨兵发送 ping 命令。
这3个定时任务贯穿哨兵进程的整个生命周期，非常重要。
当哨兵节点启动后，会向主节点发送info 命令，通过解析返回的结果可以获得从节点的列表，然后与每个从节点建立连接。之后，哨兵会每隔 10 秒定时向所有已知主从节点发送 info 命令来获取西悉尼更新并进行相应的操作。
三，配置redis哨兵
1，准备工作
| 192.168.10.101 | 主节点(master) |
| 192.168.10.102 | 从节点(slave1) |
| 192.168.10.103 | 从节点(slave2) |
| 192.168.10.104 | 哨兵节点(sentine104) |
| 192.168.10.105 | 哨兵节点(sentine105) |
| 192.168.10.106 | 哨兵节点(sentine106) |
2，环境搭建
systemctl stop firewalld ##临时关闭防火墙
setenforce 0dnf -y install gcc make ##安装必备软件,6台都要安装##修改主机名
hostnamectl set-hostname sentine104
hostnamectl set-hostname sentine105
hostnamectl set-hostname sentine106hostnamectl set-hostname master
hostnamectl set-hostname slave1
hostnamectl set-hostname slave23，部署redis主从
##三台操作一样
[root@master ~]# ls
anaconda-ks.cfg redis-6.2.4.tar.gz
[root@master ~]# tar zxvf redis-6.2.4[root@master ~]# ls
anaconda-ks.cfg redis-6.2.4 redis-6.2.4.tar.gz
[root@master ~]# cd redis-6.2.4
[root@master redis-6.2.4]# make && make PREFIX=/usr/local/redis install
[root@master redis-6.2.4]# ln -s /usr/local/redis/bin/* /usr/local/bin[root@master redis-6.2.4]# mkdir /etc/redis
[root@master redis-6.2.4]# cp redis.conf /etc/redis/6379.conf 编写redis服务启动脚本
[root@master redis-6.2.4]# vim /lib/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
修改配置文件
##三台都要操作
[root@master redis-6.2.4]# vim /etc/redis/6379.conf
bind 127.0.0.1 192.168.10.101 ##默认75行进行修该，添加各自的ip地址
daemonize yes ##257行进行修改，no改为yes，启动守护进程
logfile "/var/log/redis_6379.log" ##203行添加日志文件systemctl daemon-reload
systemctl start redis
测试
redis-cli
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.10.102,port=6379,state=online,offset=221325,lag=1
slave1:ip=192.168.10.103,port=6379,state=online,offset=221465,lag=1
4，部署redis哨兵
三台redis哨兵配置一样
[root@localhost ~]# tar zxvf redis-6.2.4.tar.gz
[root@localhost ~]# mv redis-6.2.4 /usr/src/redis[root@localhost ~]# cd /usr/src/redis/
[root@localhost redis]# make && make install[root@localhost redis]# mkdir /etc/redis ##创建用于存放redis配置文件的目录[root@localhost ~]# cd /usr/src/redis/[root@localhost redis]# cp redis.conf /etc/redis/6379.conf 修改配置文件
##三台操作一样
[root@localhost redis]# vim /etc/redis/6379.conf
bind 0.0.0.0
sentinel monitor master 192.168.10.101 6379 2
daemonize yes ##257行修改sentinel monitor ##哨兵命令
master ##住节点名字
192.168.10.101 6379 2 ##主节点 IP 和端口，最后的2表示，当主节点出现
故障，至少需要两个哨兵节点同意，才能判定主节点故障编程服务脚本
[root@localhost /]# cat /lib/systemd/system/redis.service
[Unit]
Description=redis
After=network.target[Service]
Type=forking
ExecStart=/usr/local/bin/redis-sentinel /etc/redis/6379.conf[Install]
WantedBy=multi-user.target[root@localhost /]# systemctl daemon-reload
[root@localhost /]# systemctl start redis测试
[root@localhost /]# redis-cli ##查看哨兵状态信息
127.0.0.1:6379> 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=master,status=ok,address=192.168.10.101:6379,slaves=2,sentinels=3##在101master主节点把redis关闭掉
[root@master ~]# systemctl stop redis##回到哨兵节点再次查看，发现主节点变成了103
[root@localhost /]# redis-cli
127.0.0.1:6379> 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=master,status=ok,address=192.168.10.103:6379,slaves=2,sentinels=3