【redis基础】哨兵
hi,这里是redis系列文章，本篇是【redis基础】哨兵，上一篇链接：【redis】redis主从复制_努力努力再努力mlx的博客-CSDN博客
目录
概念
作用
如何使用哨兵（案例演示+实战步骤）
redis sentinel架构提前说明
重点参数配置
本次案例通用文件配置
关于sentinel文件中的其他配置
启动一主二从的redis实例，配置哨兵，并以此演示正常的主从复制情况
主机挂了，查看日志
手动关闭redis服务器，模拟主机挂掉
我们查看主机挂掉之后从机的变化
对比配置文件
哨兵的运行流程和推举原理
主观下线与客观下线
SDOWN主观下线
ODOWN客观下线
选举领导者哨兵（哨兵中选取兵王）
由兵王开启故障切换并选举出一个新的master
新主登基
群臣俯首，一朝天子一朝臣，重新认老大
旧主拜服，老master回来也得怂
哨兵的使用建议
概念
简单来说，哨兵就是吹哨人巡查监控后台master主机是否故障，如果故障了根据投票数自动将某一个从库转换为新主库，继续对外服务。
作用
哨兵主要有以下四个作用：
- 主从监控
- 监控主从redis库运行是否正常
- 消息通知
- 哨兵可以将故障转移的结果发送到客户端
- 故障转移
- 如果master异常，则会进行主从切换，将其中一个slave作为新master
- 配置中心
- 客户端通过连接哨兵来获得当前Redis服务的主节点地址
使用一句话来总结，哨兵的主要作用有以下两点:
1、监控redis运行状态，包括master和slave
2、当master down机，能自动将slave切换成新master
如何使用哨兵（案例演示+实战步骤）
redis sentinel架构提前说明
我们本次验证redis哨兵作用的配置如下：
- 3个哨兵
- 自动监控和维护集群，不存放数据，只是监控
- 1主2从
- 用于数据读取和存放
- 在 /myredis 目录新建或者拷贝 sentinel.conf
- 先看看redis解压目录下默认的sentinel.conf文件的内容
重点参数配置
哨兵sentinel文件参数（先导）
bind 服务监听地址，用于客户端连接（默认为本机地址）
daemonize 是否以后台daemon方式运行
protected-mode 安全保护模式
port 端口
logfile 日志文件路径
pidfile pid日志路径
dir 工作目录
sentinel monitor
设置要监控的masterquorm 表示最少有几个哨兵认可客观下线，同意故障迁移的法定票数
我们知道，网络是不可靠的，有时候一个sentinel会因为网络堵塞而误以为一个master redis已经死掉了，在sentinel集群环境下需要多个sentinel互相沟通来确认某个master是否真的死了，quorum这个参数是进行客观下线的一个依据，意思是至少有quorum个sentinel认为这个master有故障，才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因，导致无法连接master，而此时master并没有出现故障，所以，这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。
sentinel auth-pass
通过密码连接master //
//通过密码连接到主机，在这里需要注意的是，即使是主机中的配置文件，我们仍然需要对此进行配置，因为我们主机挂掉之后重新启动其不再默认是主机，认识作为从机，此时他也需要连接新的主机
本次案例通用文件配置
我们对以下的哨兵的配置文件进行配置
sentinel26381.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
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.111.169 6379 2
sentinel auth-pass mymaster 111111sentinel26379.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.111.169 6379 2
sentinel auth-pass mymaster 111111关于sentinel文件中的其他配置
sentinel down-after-milliseconds ：
指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线
sentinel parallel-syncs ：
表示允许并行同步的slave个数，当Master挂了后，哨兵会选出新的Master，此时，剩余的slave会向新的master发起同步数据
sentinel failover-timeout ：
故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败
sentinel notification-script ：
配置当某一事件发生时所需要执行的脚本
sentinel client-reconfig-script ：
客户端重新配置主节点参数脚本 启动一主二从的redis实例，配置哨兵，并以此演示正常的主从复制情况
|
1
|
169机器上新建redis6379.conf配置文件，由于要配合本次案例，请设置masterauth项访问密码为111111，
不然后续可能报错master_link_status:down
|
|
2
|
172机器上新建redis6380.conf配置文件，设置好replicaof |
|
3
|
173机器上新建redis6381.conf配置文件，设置好replicaof |
按照上章配置的一主二从基础上，需要对主机redis6379.conf进行更改
redis6379.conf
6379后续可能会变成从机，需要设置访问新主机的密码， 请设置masterauth项访问密码为111111
redis 6380.conf
具体IP地址和密码根据你本地真实情况，酌情修改
redis 6381.conf
启动一主二从
6379.conf
redis-server /myredis/redis6379.conf
redis-cli -a 111111 -p6379
6380.conf
redis-server /myredis/redis6380.conf
redis-cli -a 111111 -p 6380
6381.conf
redis-server /myredis/redis6381.conf
redis-cli -a 111111-p 6381
启动哨兵
redis-sentinel sentinel26379.conf --sentinel
redis-sentinel sentinel26380.conf --sentinel
redis-sentinel sentinel26381.conf --sentinel查看哨兵信息
查看主从复制信息，发现一切正常
主机挂了，查看日志
手动关闭redis服务器，模拟主机挂掉
我们查看主机挂掉之后从机的变化
可能出现的问题：
对Broken pipe进行一定的解释：
|
认识broken pipe
|
pipe是管道的意思，管道里面是数据流，通常是从文件或网络套接字读取的数据。
当该管道从另一端突然关闭时，会发生数据突然中断，即是broken，对于socket来说，
可能是网络被拔出或另一端的进程崩溃
|
|
解决问题
|
其实当该异常产生的时候，对于服务端来说，并没有多少影响。因为可能是某个客户端突然中止了进程导致了该错误
|
|
总结 Broken Pipe
|
这个异常是客户端读取超时关闭了连接,这时候服务器端再向客户端
已经断开的连接写数据时就发生了broken pipe异常！
|
总结来说，就是主机挂掉对从机产生了瞬时性的影响，遇到这种问题不要慌张，再次重新输入同样的指令即可。
继续查看复制信息
6380
6381
我们发现6381成为了主机
对比配置文件
老master vim redis6379.conf
redis6379下线
vim redis6380.conf
新master vim redis6381.conf
我们得出结论：
- 本文中的 sentinel26379.log、sentinel26380.log、sentinel26381.log会在运行中进行动态更改
- 在master-slave切换中，redis###.conf文件中的内容会被自动更改
除此之外，哨兵中还能监视多个master，一行一个
哨兵的运行流程和推举原理
当一个主从配置中的master失效之后，sentinel可以选举出一个新的master，用于接替原master的工作，主从配置中其他redis服务器自动指向新的master同步数据。一般建议sentinel采用奇数台，防止某一台sentinel无法连接到master导致误切换。
主观下线与客观下线
SDOWN主观下线
1.SDOWN 是单个sentinel 自己主观上检测到的关于master的状态，从sentinel的角度来看，如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件
2.sentinel配置文件中的down-after-milliseconds 设置了判断主观下线的时间长度
所谓主观下线（Subjectively Down， 简称 SDOWN）指的是单个Sentinel实例对服务器做出的下线判断，即单个sentinel认为某个服务下线（有可能是接收不到订阅，之间的网络不通等等原因）。主观下线就是说如果服务器在[sentinel down-after-milliseconds]给定的毫秒数之内没有回应PING命令或者返回一个错误消息， 那么这个Sentinel会主观的(单方面的)认为这个master不可以用了，o(╥﹏╥)o
sentinel down-after-milliseconds
表示master被当前sentinel实例认定为失效的间隔时间，这个配置其实就是进行主观下线的一个依据
master在多长时间内一直没有给Sentine返回有效信息，则认定该master主观下线。也就是说如果多久没联系上redis-servevr，认为这个redis-server进入到失效（SDOWN）状态。
ODOWN客观下线
ODOWN需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经宕机
四个参数含义：
masterName是对某个master+slave组合的一个区分标识(一套sentinel可以监听多组master+slave这样的组合)
quorum这个参数是进行客观下线的一个依据，法定人数/法定票数
意思是至少有quorum个sentinel认为这个master有故障才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因导致无法连接master，而此时master并没有出现故障，所以这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。
选举领导者哨兵（哨兵中选取兵王）
- 当主节点被判断客观下线以后，各个哨兵节点会进行协商，县选举出一个领导者哨兵节点并由该领导者节点进行failover（故障迁移）
- Raft算法 选出领导者节点
监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得：即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者
日志变化
由兵王开启故障切换并选举出一个新的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并恢复正常工作。
哨兵的使用建议
- 哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用
- 哨兵节点的数量应该是奇数个
- 各个哨兵节点的配置应该一致
- 如果哨兵节点部署在Docker等容器里，要注意端口的正确映射
- 哨兵集群+主从复制，并不能保证数据零丢失