尚硅谷redis7 63-69 redis哨兵监控之理论简介

63 redis哨兵监控之理论简介

什么是哨兵

master挂了如何办?从机原地待命。此时数据只能读取不能更新。因此需要：

吹哨人巡查监控后台master主机是否故障,如果故障了根据投票数自动将某一个从库转换为新主库,

哨兵的作用

1、监控redis运行状态,包括master和slave

2、当master down机,能自动将slave切换成新master

如何使用哨兵

主从监控监控主从redis库运行是否正常

Sentinel 实时监控 Redis 的主从节点运行状态，检测节点是否宕机或失联。

消息通知哨兵可以将故障转移的结果发送给客户端

当发生主从切换后，Sentinel 会将新的主节点信息通知给客户端或相关服务，确保其连接到正确的主节点。

故障转移如果Master异常,则会进行主从切换,将其中一个Slave作为新Master

Sentinel 发现主节点（Master）宕机，并经多个 Sentinel 实例协商确认后，会自动将其中一个从节点（Slave）提升为新的主节点，并将其他从节点重新配置为复制新的主节点。

配置中心客户端通过连接哨兵来获得当前Redis服务的主节点地址

客户端可以通过连接 Sentinel 获取当前可用的主节点地址，而不需要手动修改配置，从而实现动态主节点发现。

64 redis哨兵监控之案例实操1

3个哨兵自动监控和维护集群,不存放数据,只是吹哨人

1主2从用于数据读取和存放

为什么要有 3 个 Sentinel 哨兵？

1.防止一个哨兵挂了，无法实现监控

2.基数好投票

Redis Sentinel 使用一种简单的共识机制来避免误判【有时候主机并不是真死了，可能是网络不好】。哨兵集群通过"投票"来决定主节点是否真的故障。这个过程称为：

故障主观判断（sdown） → 故障客观判断（odown）

每个 Sentinel 实例独立判断主节点是否故障（sdown）

当大多数 Sentinel 都认为主节点不可用时，才会触发故障转移（odown）

Redis 集群中通常部署 3 个 Sentinel（哨兵），是为了实现高可用的主从切换机制。哨兵之间通过投票机制达成共识，判断主节点是否真的故障，并协调自动故障转移。3 个是最小可容忍 1 个故障的投票集，是安全性与资源使用的最佳平衡。

由于硬件问题，无法用6台机子去模拟过程，因此6379：master,6390、6381：slave。同时三个哨兵和6379共用一个主机。

先看看/opt目录下默认的sentinel.conf文件【哨兵配置文件】的内容

将此sentinel.conf文件拷贝到myredis文件夹下

重点参数项说明

bind：服务监听地址,用于客户端连接,默认本机地址

daemonize：是否以后台daemon方式运行

protected-mode：安全保护模式

port：端口

logfile：日志文件路径

pidfile：pid文件路径用于指定 进程 ID 文件（PID 文件） 的保存路径。

dir：工作目录

设置要监控的Master服务器

sentinel monitor <master-name> <ip> <redis-port> <quorum>

参数	说明
`<master-name>`	主节点的名称（逻辑标识，可自定义）
`<ip>`	要监控的主节点的 IP 地址
`<redis-port>`	主节点的端口
`<quorum>`	最少有多少个 Sentinel 认为主节点挂了，才会进行故障转移（投票数量）

sentinel auth-pass <master-name> <password> 配置主节点认证密码的重要命令，用于确保 Sentinel 在连接主节点时通过密码验证。

参数	说明
`<`master-name`>`	与 `sentinel monitor` 中配置的主节点名称保持一致
`<password>`	主节点 Redis 的访问密码（即 `requirepass` 设置的密码）

sentinel monitor mymaster 127.0.0.1 6379 2

sentinel auth-pass mymaster myRedisPassword

这个配置告诉 Sentinel：

"连接并监控名为 mymaster 的主节点时，需要使用密码 myRedisPassword。"

61 redis哨兵监控之案例实操2

我们知道,网络是不可靠的,有时候一个sentinel会因为网络堵塞而误以为一个master redis已经死掉了,在sentinel集群环境下需要多个sentinel互相沟通来确认某个master是否真的死了,quorum这个参数是进行客观下线的一个依据,意思是至少有quorum个sentinel认为这个master有故障,才会对这个master进行下线以及故障转移。因为有的时候,某个sentinel节点可能因为自身网络原因,导致无法连接master,而此时master并没有出现故障,所以,这就需要多个sentinel都一致认为该master有问题,才可以进行下一步操作,这就保证了公平性和高可用。

其他参数配置

sentinel down-after-milliseconds <master-name> <milliseconds>:
- 指定多少毫秒之后，主节点没有应答哨兵,此时哨兵主观上认为主节点下线
sentinel parallel-syncs <master-name> <nums>:
- 表示允许并行同步的slave个数,当Master挂了后,哨兵会选出新的Master,此时,剩余的slave会向新的master发起同步数据
sentinel failover-timeout <master-name> <milliseconds>:
- 故障转移的超时时间,进行故障转移时,如果超过设置的毫秒,表示故障转移失败
sentinel notification-script <master-name> <script-path> :
- 配置当某一事件发生时所需要执行的脚本
sentinel client-reconfig-script <master-name> <script-path>:
- 客户端重新配置主节点参数脚本

66 redis哨兵监控之案例实操3

如果你使用的是 redis-sentinel 可执行文件（或者你有一个指向 redis-server 的符号链接，名为 redis-sentinel），你可以通过以下命令来以 Sentinel 模式运行：

redis-sentinel /path/to/sentinel.conf

否则，你也可以直接使用 redis-server 可执行文件，并通过 Sentinel 模式启动，如下所示：

redis-server /path/to/sentinel.conf -- sentinel

哨兵默认监听 TCP 端口 26379，因此要让哨兵正常工作，你的服务器必须开放 26379 端口，以接收来自其他哨兵实例 IP 地址的连接。否则，哨兵之间将无法通信，也无法就该执行什么操作达成一致，故障转移也将无法进行。

本案例sentinel文件通用配置

由于机器硬件关系,我们的3个哨兵都同时配置进一台虚拟机中【例如：192.168.111.169】

sentinel26379.conf

bind 0.0.0.0

daemonize yes

protected-mode no

port 26379

logfile "/myredis/sentinel26379.log"

pidfile /var/run/redis-sentinel26379.pid

dir /myredis

sentinel monitor mymaster 192. 168. 111. 169 6379 2

sentinel auth-pass mymaster 111111

配置项	含义
`bind 0.0.0.0`	监听所有网卡（对外可访问）
`daemonize yes`	以守护进程方式运行（后台运行）
`protected-mode no`	关闭保护模式（确保你已配置防火墙，否则不安全）
`port 26379`	Sentinel 的监听端口，默认就是这个
`logfile`	日志文件路径（建议确保 `/myredis` 目录存在）
`pidfile`	PID 文件路径（注意你原来写的是 `redis-sentine126379. pid`，有空格和拼写错）
`dir`	Sentinel 持久化信息的工作目录
`sentinel monitor`	配置要监控的主节点（名称、IP、端口、投票数）
`sentinel auth-pass`	Sentinel 连接主节点使用的认证密码