是什么
Docs
吹哨人巡查监控后台master主机是否故障，如果故障了根据投票数自动将某一个从库转换为新主库，继续对外服务
作用:无人值守运维
能干嘛
1.主从监控
监控主从redis的库是否运行正常
2.消息通知
哨兵可以将故障转移的结果发送给客户端
3.故障转移
如果Master异常，则会进行主从切换将其中一个Slave作为新Master
4.配置中心
客户端通过连接哨兵来获得当前Redis服务的主节点地址
案例演示(实战步骤)
1.Redis sentinel架构,前提说明
2.案例步骤
1./myredis目录下新建或者拷贝sentinel.conf文件，名字绝不能错
把/opt/redis-版本号下的最原始的sentinel.conf文件拷贝进/myredis下
2.conf配置文件的重点参数说明
1.bind
服务监听地址，用于客户端连接，默认本机地址
2.daemonize
是否以后台daemon方式运行
3.protected-mode
安全保护模式
4.port
端口
5.logfile
日志文件路径
6.pidfile
pid文件路径
7.dir
工作目录
8.sentinel monitor <master-name> <ip> <redis-port> <quorum>
设置要监控的master服务器
quorum:表示最少有几个哨兵认可客观下线，同意故障迁移的法定票数。
为什么用quorum:
我们知道，网络是不可靠的，有时候一个sentinel会因为网络堵塞而误以为一个master redis已经死掉了，在sentinel集群环境下需要多个sentinel互相沟通来确认某个master是否真的死了，quorum这个参数是进行客观下线的一个依据，意思是至少有quorum个sentinel认为这个master有故障，才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因，导致无法连接master，而此时master并没有出现故障，所以，这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。
9.sentiel auth-pass <master-name> <password>
master设置了密码，连接master服务的密码
10.其他
3.本次案例哨兵sentinel.conf的通用配置
由于机器硬件关系，我们的3个哨兵都同时配置进192.168.111.169同一台机器
在/myredis下配置:
sentinel26379:
4.先启动一主二从3个redis实例,测试正常的主从复制
1.架构说明
2.配置redis一主二从的conf文件
6379:(也要配置6379的masterauth,因为当6379从主机下位后成为从机,要连接新主机)
3.3台不同的虚拟机实例，启动三部真实机器实例并连接
5.启动三个哨兵,完成监控
6.启动三个哨兵后再测试一次主从复制
7.原有的master挂了
1.我们自己手动关闭6379服务器,模拟master挂了
2.问题思考
两台从机上的数据是否ok-->ok的,但是因为要内部选举,所以会error一段时间
是否会从剩下的两台从机上选出新的master-->会
之前down的主机重新启动回来,谁将是新老大,会不会双master冲突-->不会,通过日志,我们发现6379会彻底变成slave
查看sentinel26379.log文件
3.答案揭晓
数据是ok的,但是两个小问题,一种是连接断开,一种是broken pipe
8.对比配置文件
6379的配置文件;
结论:
sentinel会修改redis数据库的conf文件
3.其他备注
哨兵只是监控,没有业务压力
生产都是不同机房不同服务器，很少出现3个哨兵全挂掉的情况
哨兵可以同时监控多个master,一行一个
哨兵运行流程和选举原理
当一个主从配置中的master失效之后，sentinel可以选举出一个新的master用于自动接替原master的工作，主从配置中的其他redis服务器自动指向新的master同步数据。一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换
运行流程,故障切换
三个哨兵监控一主二从,正常运行中
主观下线SDown
SDOWN(主观不可用)是单个sentinel自己主观止检测到的关于master的状态，从sentinel的角度来看如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件。
sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度
ODown客观下线
ODOWN需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经宕掉
quorum
选举出领导者哨兵(哨兵中选出兵王)leader
投票完以后,三个哨兵选出一个leader.由leader来执行接下来的更换master等操作
当主节点被判断客观下线以后，各个哨兵节点会进行协商先选举出一个领导者哨兵节点(兵王)并由该领导者节点也即被选举出的兵王进行failover(故障迁移)
看日志可以看到选取leader的过程
兵王如何选举出来的?Raft算法
判断主观下线的哨兵节点向其他哨兵节点发送master宕机，如果超过半数的哨兵节点判断master节点进入客观下线的状态，那么率先判断进入主观下线的哨兵将成为领头sentinel
由兵王开始推动故障切换流程并选举出一个新的master(新master选举的算法)
三步骤
新王登基
某个slave被选中成为新master
选出新master的规则(在slave节点健康的前提下):
群臣俯首
首先被选为新master的执行slaveof no one命令让自己从原来的从节点变为主节点,然后再通过slaveof 命令让其他节点成为从节点
旧主拜服
总结
上述的failover操作均由sentinel自己独自完成，完全无需人工干预
哨兵使用建议
并不能保证数据零丢失,引出集群
