【大家好，我是爱干饭的猿，本文重点介绍Redis7 哨兵，重点：哨兵运行流程和选举原理。
后续会继续分享Redis7和其他重要知识点总结，如果喜欢这篇文章，点个赞👍，关注一下吧】
上一篇文章：《【Redis7】Redis7 主从复制（重点：主从复制原理）》
目录
🥞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文件参数（先导）
- bind 服务监听地址，用于客户端连接
- daemonize 是否以后台daemon方式运行
- protected-mode 安全保护模式
- port 端口
- logfile 日志文件路径
- pidfile pid日志路径
- dir 工作目录
- sentinel monitor <master> <redis-port> <quorum>
- 设置要监控的master
- quorm 表示最少有几个哨兵认可客观下线，同意故障迁移的法定票数
编辑
- sentinel auth-pass <master-name> <password> 通过密码连接master
- 哨兵sentinel文件配置
- sentinel26381.conf
- sentinel26380.conf
- sentinel26379.conf
编辑
- 先启动一主二从
编辑
- 按照上章配置的一主二从基础上，需要对主机redis6379.conf进行更改
- 6379后续可能会变成从机，需要设置访问新主机的密码， 请设置masterauth项访问密码为123456
- 启动一主二从
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挂了
- 两台从机的数据不会丢失
- 会从其他两台从机选出一个新的master
- 挂掉的master重连回来，直接变成新master的从机
结论：
- 本文中的 sentinel26379.conf、sentinel26380.conf、sentinel26381.conf会在运行中进行动态更改
- 在master-slave切换中，会自动多一行slaveof的配置
1.5 哨兵运行流程和选举原理
当一个主从配置中的master失效之后，sentinel可以选举出一个新的master，用于接替原master的工作，主从配置中其他redis服务器自动指向新的master同步数据。一般建议sentinel采用奇数台，防止某一台sentinel无法连接到master导致误切换。
运行流程，故障切换：
- SDOWN主观下线
- SDOWN 是单个sentinel 自己主观上检测到的关于master的状态，从sentinel的角度来看，如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件
- sentinel配置文件中的down-after-milliseconds 设置了判断主观下线的时间长度
编辑
- ODOWN客观下线
- ODOWN需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经宕机
编辑
- 选举出领导者哨兵
- 当主节点被判断客观下线以后，各个哨兵节点会进行协商，县选举出一个领导者哨兵节点并由该领导者节点进行failover（故障迁移）
- Raft算法 选出领导者节点
编辑
- 由领导者节点开始推动故障切换并选出一个新master
- 新主登基
- 某个slave 备选成为新 master
- 选出新master的规则，剩余slave节点健康前提下
- redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点(数字越小优先级越高)
- 复制偏移位置offset最大的从节点（log中记录最多条数的）
- 最小Run ID的从节点，也就是字典顺序，ASCII码
- 群臣俯首
- 一朝天子一朝臣，重新认老大
- 执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点
- Sentinel leader会对选举出的新master执行slaveof no one操作，将其提升为master节点
- Sentinel leader向其它slave发送命令，让剩余的slave成为新的master节点的slave
- 旧主拜服
- 老master回来也得怂
- 将之前已下线的老master设置为新选出的新master的从节点，当老master重新上线后，它会成为新master的从节点
- Sentinel leader会让原来的master降级为slave并恢复正常工作。
- 以上的failover都是sentinel自己独立完成，完全无需人工干预
1.6 使用建议
- 哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用
- 哨兵节点的数量应该是奇数个
- 各个哨兵节点的配置应该一致
- 如果哨兵节点部署在Docker等容器里，要注意端口的正确映射
- 哨兵集群+主从复制，并不能保证数据零丢失
分享到此，感谢大家观看！！！
如果你喜欢这篇文章，请点赞加关注吧，或者如果你对文章有什么困惑，可以私信我。
🏓🏓🏓
