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

Redis有多个哨兵形成集群，如果一个哨兵实例故障了，那么其他哨兵还能继续协作完成主从库切换到工作。

1.哨兵集群间是如何通信的呢

Redis的哨兵实例相互之间的通信是基于pub/sub机制，也就是发布/订阅机制。

哨兵只要和主库建立起连接，就可以在主库上发布消息了，比如它发布自己的连接信息（IP和端口）。同时，他也可以从主库上订阅消息，获得其他哨兵发布的连接信息。
当多个哨兵实例都在主库上做了发布和订阅操作后，它们之间就能知道彼此的IP地址和端口。

除了哨兵实例，我们自己编写的应用程序也可以通过Redis进行消息的发布和订阅。

所以为了区分不同应用的消息，Redis会以频道的形式，对这些消息进行分门别类的管理。所谓频道，实际上就是消息的类别，当消息的类别相同时，他们就属于同一个频道。反之，就属于不同的频道。

只有订阅了同一个频道的应用，才能通过发布的信息进行信息交换。

在主从集群中，主库上有一个名为“sentinel：hello”的频道，不同哨兵就是通过它来相互发现，实现相互通信的。

然后，哨兵2.3可以和哨兵1建立网络连接。通过这个方式，哨兵2和3也可以建立网络连接，这样，哨兵集群就形成了。他们相互间可以通过网络连接进行通信，比如锁对主库有没有下线这件事情进行判断和协商。

哨兵除了彼此之间建立起连接形成集群外，还需要和从库建立连接。这是因为，在哨兵的监控任务中，它需要对主从库都进行心跳判断，而且在主从库切换完成后，它还需要通知从库，让他们和新主库进行同步。

2.哨兵是如何和从库进行通信的呢

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

3.哨兵怎么和客户端通信呢

基于pub/sub机制的客户端事件通知

从本质上来说，哨兵也是个运行在特定模式下的Redis实例，只不过它并不服务请求操作。只是完成监控、选主和通知的任务。

所以每个哨兵实例也提供pub/sub机制，客户端可以从哨兵订阅消息。

客户端读取了哨兵的配置文件后，可以获得哨兵的地址和端口，和哨兵建立网络连接。然后我们可以在客户端订阅命令，来获取不同的事件消息。

4.由哪个哨兵来执行主从切换呢

客观下线的过程：
任何一个实例只要判断主库主观下线后，就会给其他实例发送is-master-down-by-addr命令。其他实例会根据自己和主库的连接情况，做成Y或N的响应。

一旦哨兵获得仲裁所需的票数后，就可以标记主库为客观下线。

此时，这个哨兵就可以再给其他哨兵发送命令，表面希望由自己来执行主从切换，并让其他所有哨兵进行投票，这个投票选举过程称为“Leader选举”。因为最终执行主从切换的哨兵称为Leader，投票过程就是确定Leader。

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