第八章 哨兵集群：哨兵挂了，主从库还能切换吗

第八章 哨兵集群：哨兵挂了，主从库还能切换吗 ?基于 pub/sub 机制的哨兵集群组成

哨兵之间怎么知道彼此的地址和端口呢 ?

依赖于redis的发布/订阅机制，每个哨兵都把自己的信息发送给主库，然后从主库订阅其他哨兵的消息，这样就可以互相知道其他哨兵的地址了在主从集群中，主库上有一个名为 “sentinel:hello” 的频道，不同哨兵就是通过它来相互发现，实现互相通信的。

基于 INFO 命令的从库列表，这可以帮助哨兵和从库建立连接

哨兵如何知道从库的 IP 地址和端口的呢 ?

哨兵向主库发送 INFO 命令，主库将从库列表返回给哨兵。哨兵就可以根据从库列表中的连接信息，和每个从库建立连接，并在这个连接上持续地对从库进行监控。

基于 pub/sub 机制的客户端事件通知每个哨兵实例也提供 pub/sub 机制，客户端可以从哨兵订阅消息。哨兵提供的消息订阅频道有很多，不同频道包含了主从库切换过程中的不同关键事件。

由哪个哨兵执行主从切换 ?

主库客观下线 仲裁过程：

任何一个实例只要自身判断主库主观下线后，就会给其他实例发送 is-master-down-by-addr命令。其他实例会根据自己和主库的连接情况，做出Y或N的响应。该哨兵实例获得了仲裁所需的赞成票数后【哨兵配置文件中的quorum配置项】，就可以标记主库为客观下线。

哨兵 Leader选举过程（最终执行主从切换的哨兵称为 Leader，投票过程就是确定 Leader。）：

该哨兵实例可以再给其他哨兵发送命令，表明希望由自己来执行主从切换，并让其他哨兵进行投票（Leader选举）。在投票过程中，任何一个想成为Leader的哨兵，要满足两个条件：拿到半数以上的赞成票。拿到的票数同时还需要大于等于哨兵配置文件中的quorum值。如果这轮没有产生Leader，哨兵集群会等待一段时间（哨兵故障转移超时时间的2倍），再重新选举。

总结下哨兵集群执行主从切换的具体过程：

一个哨兵发现主库主观下线，那他就会发送命令给其他哨兵，然后其他哨兵根据自己和主库的连接情况，通知给发送命令的那个哨兵，该哨兵根据赞成的票数来决定是否将该主库标记为客观下线如果主库标记为客观下线了，该哨兵就会再给其他哨兵发送命令，表明希望由自己来执行主从切换，也就是让其他哨兵进行投票选举leader如果该哨兵被选举为leader了，它就要根据一定的规则选出新主库然后执行主从切换问题

5 个哨兵实例的集群，quorum 值设为 2。在运行过程中，如果有 3 个哨兵实例都发生故障了，此时，Redis 主库如果有故障，还能正确地判断主库“客观下线”吗 ? 如果可以的话，还能进行主从库自动切换吗 ?

因为判定主库“客观下线”的依据是，认为主库“主观下线”的哨兵个数要大于等于 quorum 值，现在还剩 2 个哨兵实例，个数正好等于 quorum 值，所以还能正常判断主库是否处于“客观下线”状态。如果一个哨兵想要执行主从切换，就要获到半数以上的哨兵投票赞成，也就是至少需要 3 个哨兵投票赞成。但是，现在只有 2 个哨兵了，所以就无法进行主从切换了。