Redis哨兵模式原理剖析，监控、选主

为什么需要客观下线机制？

因为当前哨兵节点探测对方没有得到响应，很有可能这两个机器之间的网络发生了故障，而 Master 节点本身没有任何问题，此时就认为 Master 故障是不正确的。

为了解决上述问题，客观下线应运而生，Sentinel一般会集群部署，引入多个哨兵实例一起来判断，就可以避免单个哨兵因为自身网络状况不好，而误判主库下线的情况。

假设我们有N个哨兵实例，如果有N/2+1个实例判断主库“主观下线”，此时把节点标记为“客观下线”，此时就可以做主从切换了。

4.选举哨兵领导者？

==========

假设Sentinel 判断主库“主观下线”后，就会给其他 Sentinel 实例发送 is-master-down-by-addr 命令，接着，其他 Sentinel 实例会根据自己和主库的连接情况，做出赞成和反对决定。

假设我们有N个哨兵实例，如果有#{quorum}个实例赞成，此时这个 Sentinel 就会给其他 Sentinel 发送主从切换请求，其他 Sentinel 会进行投票，如果投票通过，这个 Sentinel 就可以进行主从切换了， 这个投票过程被称为Leader 选举 。其实整体思想和Zookeeper一样的。

在投票过程中，任何一个想成为 Leader 的哨兵，要满足两个条件：第一，拿到半数以上的赞成票；第二，拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。

quorum一般我们都会配置成 实例数量/2+1

此时会有小伙伴问ÿ