深入搞懂Redis中的哨兵

日期：2023-04-26 00:00 / 作者：青灯夜游

redis哨兵详解，哨兵搭建流程，哨兵的运行流程和选举原理(主观下线，客观下线，如何选举出哨兵leader)。

Redis哨兵（sentinel）

哨兵是什么？

吹哨人巡查监控后台master主机是否故障，如果故障了根据投票数自动将某一个从库转换为新主库，继续对外服务。【相关推荐：Redis视频教程】

俗称，无人值守运维。

干什么？

主从监控：监控主从redis库运行是否正常
消息通知：哨兵可以将故障转移的结果发送给客户端
故障转移：将其中一个Slave作为新的Master
配置中心：客户端通过连接哨兵来获得当前Redis服务的主节点地址

案例

架构

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

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

步骤

将redis安装路径下的 sentinel.conf 拷贝到 myredis目录下
```
cp sentinel.conf /myredis/sentinel26379.conf
```
修改配置文件
```
vim sentinel26379.conf
    
bind 0.0.0.0
    
# protected-mode yes 修改为 protected-mode no
protected-mode no

# daemonize no 修改为 daemonize yes
daemonize yes

# port 
port 26379

# pid文件名字，pidfile
pidfile /var/run/redis_26379.pid
    
# log文件名字，logfile（修改 logfile "" 为 logfile "/myredis/26379.log"）
logfile "/myredis/26379.log"

# 指定当前的工作目录（修改 dir /temp 为 dir /myredis）
dir /myredis
```
设置要监控的master服务器

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

安装三台linux

ip和port分别为

# sentinel00
192.168.157.112    26379
# sentinel01
192.168.157.113    26380
# sentinel02
192.168.157.118    26381

配置三台哨兵

sentinelxxxx.conf 文件

sentinel00

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.157.115 6379 2
sentinel auth-pass mymaster 1234

sentinel01

sentinel26380.conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 26380
logfile "/myredis/sentinel26380.log"
pidfile /var/run/redis-sentinel26380.pid
dir /myredis
sentinel monitor mymaster 192.168.157.115 6379 2
sentinel auth-pass mymaster 1234

sentinel02

sentinel26381.conf

bind 0.0.0.0
daemonize yes
protected-mode no
port 26381
logfile "/myredis/sentinel26381.log"
pidfile /var/run/redis-sentinel26381.pid
dir /myredis
sentinel monitor mymaster 192.168.157.115 6379 2
sentinel auth-pass mymaster 1234

测试

基于之前的 redis复制，启动1主2从测试是否主从复制是否正常，输入 info replication 查看是否正常

启动三台哨兵，完成监控

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

测试主从复制，一切良好
查看日志

查看配置文件 sentinel.conf

> 后面为自动新增内容

模拟master宕机

master主机
```
# 模拟宕机
shudown
```
问题
1. 两台从机数据是否正常？（yes）
2. 会不会从剩下的两台机器中选出新的master?（yes）
3. 之前的master重启之后会不会重新上位，重新成为master？（no）
salve获取数据

查看新的master

重写启动原master

master不会重新上位。

对比配置文件

文件的内容，在运行期间会被sentinel动态修改。master—slave主从关系切换后，配置文件内容会自动发生改变。

sentinel6379.conf 文件

旧 master

新master

哨兵运行流程和选举原理

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

SDown主观下线(Subjectively Down)

SDOWN（主观不可用）是单个哨兵自己主观检测到的关于master的状态，从sentinel的角度来看，如果发送了PING心跳后，在一定时间内没有收到合法的回复，就到达了SDOQN的条件。

sentinel配置文件中的 down-after-milliseconds 设置了主观下线的时间长度（默认30秒）。

# sentinel down-after-milliseconds  
sentinel down-after-milliseconds mymaster 30000

ODown客观下线(Objectively Down)

ODOWN需要一定数量的sentinel，多个哨兵达成一致意见才能确认一个master客观上已经宕机了。

# sentinel monitor    
sentinel monitor mymaster 127.0.0.1 6379 2

选举出领导者哨兵

当主节点被判断客观下线后，各个哨兵节点会进行协商，先选举出一个领导者哨兵节点，并由该领导者哨兵节点进行failover（故障迁移）

领导者哨兵如何选出来的？

Raft算法

监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得，即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者。

选新的master（im）

整个过程由sentinel自己独立完成，无需人工干涉。

新主登基

某一个slave被选中成为master

选出新的master的规则，剩余slave节点健康的前提下

redis.conf文件中，优先级slave-priority或者replica-priority最高节点（数字越小优先级越高）
复制偏移量offset最大的从节点。
最小Run ID的从节点。

群臣俯首

执行 slaveof no one 命令让选出来的从节点成为新的主节点，并通过 slaveof 命令让其他节点成为其从节点。
sentinel leader 会对选举出来的新 master 执行 slaveof no one，将其提升为master节点
sentinel leader 向其他slave发送命令，让剩余的slave成为新的master节点的slave。

旧主拜服

将之前的已经下线的旧master设置为新选出的新master的从节点，当旧master重新上线后，它会成为新master的从节点
sentinel leader 会让原来的master降级为slave并恢复正常工作。

哨兵使用建议

哨兵节点数量应该为多个，哨兵本身应该为集群，保证高可用
哨兵节点数量应该是奇数
各个哨兵节点的配置应该一致
如果哨兵节点部署在docker等容器里面，尤其要注意端口的正确映射
哨兵集群 + 主从复制，并不能保证数据零丢失

更多编程相关知识，请访问：编程视频！！