哨兵的主要作用
为实现主从切换，主要功能为监控、选主、通知
监控
哨兵发送ping命令检查主从库的网络连接状态，若ping响应超时，则标记为“主观下线”，如果存在半数以上的哨兵判断主库为“主观下线”，则标识主库为“客观下线”。
选主
主库“客观下线”之后，会重新选主。选主流程如下：
过滤掉 已经下线后的从库 和 总是和主库断连的从库（超过断连次数的阈值）
在剩下的从库中按照一定的规则对从库进行打分，得分高者升级为主库
- 优先级高的从库得分高，可通过slave-priority设置从库的优先级
- 同步进度最快的从库，得分高，比较从库的slave-repli-offset
- 从库ID号小的得分高
通知
通知从库重新同步新主库的数据。哨兵会把新主库的地址写入自己实例的pubsub(switch-master)中，客户端订阅pubsub 就能感知到主库
哨兵集群
特点: 哨兵集群存在故障节点时，只要集群中大部分节点正常，集群依旧能对外提供服务。 “拜占庭问题”。
问题： 主库下线后由谁来执行新主库的切换？
答： 从哨兵中选举出一个哨兵领导者。 每个哨兵设置一个随机超时时间，超时后向其他哨兵请求投票，其他哨兵会给第一个向自己发送投票请求的哨兵进行投票，可能经过多次投票后（若在一个回合中没有投出来，哨兵集群会等待一段时间（也就是哨兵故障转移超时时间的 2 倍），再重新进行投票），投票数超过半数且投票数大于等于哨兵配置文件中的 quorum 值的为哨兵领导者。
需要注意的是，如果哨兵集群只有 2 个实例，此时，一个哨兵要想成为 Leader，必须获得 2 票，而不是 1 票。所以，如果有个哨兵挂掉了，那么，此时的集群是无法进行主从库切换的。因此，通常我们至少会配置 3 个哨兵实例。这一点很重要，你在实际应用时可不能忽略了
