【Redis7】 Redis7 哨兵（重点：哨兵运行流程和选举原理）

news2024/12/23 9:31:45

【大家好，我是爱干饭的猿，本文重点介绍Redis7 哨兵，重点：哨兵运行流程和选举原理。

后续会继续分享Redis7和其他重要知识点总结，如果喜欢这篇文章，点个赞👍，关注一下吧】

上一篇文章：《【Redis7】Redis7 主从复制（重点：主从复制原理）》

🥞1. 哨兵

1.1 概述

1.2 作用

1.3 Redis Sentinel架构

1.4 操作步骤

1.5 哨兵运行流程和选举原理

1.6 使用建议

🥞1. 哨兵

1.1 概述

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

1.2 作用

主从监控
- 监控主从redis库运行是否正常
消息通知
- 哨兵可以将故障转移的结果发送到客户端
故障转移
- 如果master异常，则会进行主从切换，将其中一个slave作为新master
配置中心
- 客户端通过连接哨兵来获得当前Redis服务的主节点地址

1.3 Redis Sentinel架构

Redis Sentinel架构如下图：

3个哨兵
- 自动监控和维护集群，不存放数据，只是监控
1主2从
- 用于数据读取和存放

1.4 操作步骤

在 /myredis 目录新建或者拷贝 sentinel.conf
先看看redis解压目录下默认的sentinel.conf文件的内容
哨兵sentinel文件参数（先导）
1. bind 服务监听地址，用于客户端连接
2. daemonize 是否以后台daemon方式运行
3. protected-mode 安全保护模式
4. port 端口
5. logfile 日志文件路径
6. pidfile pid日志路径
7. dir 工作目录
8. sentinel monitor <master> <redis-port> <quorum>
  1. 设置要监控的master
  2. quorm 表示最少有几个哨兵认可客观下线，同意故障迁移的法定票数
9. sentinel auth-pass <master-name> <password> 通过密码连接master
哨兵sentinel文件配置
1. sentinel26381.conf
2. sentinel26380.conf
3. sentinel26379.conf
先启动一主二从
1. 按照上章配置的一主二从基础上，需要对主机redis6379.conf进行更改
  1. 6379后续可能会变成从机，需要设置访问新主机的密码，请设置masterauth项访问密码为123456
2. 启动一主二从
  1. ```
  6379.conf
  	redis-server /myredis/redis6379.conf 
  	redis-cli -a 123456
  
  6380.conf
  	redis-server /myredis/redis6380.conf 
  	redis-cli -a 123456 -p 6380
  
  6381.conf
  	redis-server /myredis/redis6381.conf 
      redis-cli -a 123456 -p 6381
```

启动哨兵

redis-sentinel sentinel26379.conf --sentinel
redis-sentinel sentinel26380.conf --sentinel
redis-sentinel sentinel26381.conf --sentinel

关闭6379服务器，模仿master挂了
1. 两台从机的数据不会丢失
2. 会从其他两台从机选出一个新的master
3. 挂掉的master重连回来，直接变成新master的从机

结论：

本文中的 sentinel26379.conf、sentinel26380.conf、sentinel26381.conf会在运行中进行动态更改
在master-slave切换中，会自动多一行slaveof的配置

1.5 哨兵运行流程和选举原理

当一个主从配置中的master失效之后，sentinel可以选举出一个新的master，用于接替原master的工作，主从配置中其他redis服务器自动指向新的master同步数据。一般建议sentinel采用奇数台，防止某一台sentinel无法连接到master导致误切换。

运行流程，故障切换：

SDOWN主观下线
1. SDOWN 是单个sentinel 自己主观上检测到的关于master的状态，从sentinel的角度来看，如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件
2. sentinel配置文件中的down-after-milliseconds 设置了判断主观下线的时间长度
ODOWN客观下线
1. ODOWN需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经宕机
选举出领导者哨兵
1. 当主节点被判断客观下线以后，各个哨兵节点会进行协商，县选举出一个领导者哨兵节点并由该领导者节点进行failover（故障迁移）
2. Raft算法选出领导者节点
由领导者节点开始推动故障切换并选出一个新master
1. 新主登基
  1. 某个slave 备选成为新 master
  2. 选出新master的规则，剩余slave节点健康前提下
    1. redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点(数字越小优先级越高)
    2. 复制偏移位置offset最大的从节点（log中记录最多条数的）
    3. 最小Run ID的从节点，也就是字典顺序，ASCII码
2. 群臣俯首
  1. 一朝天子一朝臣，重新认老大
  2. 执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点
  3. Sentinel leader会对选举出的新master执行slaveof no one操作，将其提升为master节点
  4. Sentinel leader向其它slave发送命令，让剩余的slave成为新的master节点的slave
3. 旧主拜服
  1. 老master回来也得怂
  2. 将之前已下线的老master设置为新选出的新master的从节点，当老master重新上线后，它会成为新master的从节点
  3. Sentinel leader会让原来的master降级为slave并恢复正常工作。
以上的failover都是sentinel自己独立完成，完全无需人工干预