一旦多个实例组成了哨兵集群，即使有哨兵实例出现故障挂掉了，其他哨兵还能继续协作完成主从库切换的工作，包括判定主库是不是处于下线状态，选择新主库，以及通知从库和客户端。

在配置哨兵信息时，只需要用到下面的配置项，设置主库IP和端口，并没有配置其他哨兵的连接信息。

          哨兵实例之间可以相护发现，要归功于Redis提供的pub/sub机制，也就是发布/订阅机制。

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

Redis会以频道的形式，对消息进行分门别类的管理。类似于消息队列的主题。

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

"__sentinel_:hello"频道：不同哨兵通过它来相护发现实现互相通信。

例子：哨兵将自己的IP(172.16.19.3)和端口（26579）发布到"__sentinel__:hello"频道上，哨兵订阅了该频道。此时哨兵2和3就可以从这个频道直接获取哨兵1的IP地址和端口号。

哨兵2，3可以和哨兵1建立网络连接。类似的，哨兵2和3之间也可以建立网络连接。这样哨兵集群就形成了。它们互相间可以通过网络连接进行通信，对主库有没有下线这事儿进行判断和协商。

      哨兵除了彼此之间建立起连接形成集群外，还需要和从库建立连接。哨兵的监控任务需要对主从库进行心跳判断，选主和通知。

       哨兵向主库发送 INFO命令完成。哨兵2给主库发送INFO命令，主库接受这个命令以后，把从库列表返回给哨兵。哨兵根据从库列表中连接信息，和每个从库建立连接，并在这个连接上持续的对从库进行监控。哨兵1和3可以通过相同方法和从库建立连接。

       通过pub/sub机制，哨兵之前可以组成集群，同时，哨兵又通过INFO命令，获得从库连接信息。也能和从库建立连接，并进行监控。

        哨兵就是一个运行在特定模式下的Redis实例，只不过并不服务请求操作，只是完成监控，选主和通知的任务。因此每个哨兵实例都提供pub/sub机制。客户端可以从哨兵订阅消息。哨兵提供的消息订阅频道很多，不同频道包含了主从库切换过程中的不同关键事件。

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

    确定由哪个哨兵执行主从切换的过程，和主库"客观下线"的判断过程类似，也是一个"投票仲裁"的过程。

   判断客观下线的过程：多数哨兵认定该主库已经"主观下线"。

   任何一个哨兵只要自身判断主库"主观下线"后，都会给其他实例发送is-master-down-by-addr命令。接着，其他实例会根据自己和主库的连接情况做出Y或N的响应，Y相当于赞成票，N相当于反对票。

    一个哨兵获得仲裁所需的赞成票后，就可以标记主库为"客观下线"，这个赞成票数是 quorum 配置项设定。

     这个哨兵就会给其他哨兵发送命令，表明希望自己来执行主从切换，并让所有其他哨兵进行投票，这个投票过程被称为"Leader选举"。因为最终执行主从切换的哨兵成为Leader,投票过程称为确定Leader。

以3个哨兵为例，假设此时的quorum设为2，那么任何一个想成为Leader的哨兵主要拿到2张赞成票就可以了。

          哨兵集群能够进行成功投票很大程度上依赖于选举命令的正常网络传播。如果网络压力较大或者有短时间堵塞，就可能导致没有一个哨兵能够拿到半数以上的赞成票。所以等到网络拥塞好转以后成功概况会增加。如果哨兵集群只有2个实例，此时一个哨兵想要成为Leader,必须获得2票，而不是1票。如果其中1个哨兵挂掉就无法完成主从切换。

        要保证所有哨兵实例的配置是一致的，尤其是主观下线的判断值 down-after-milliseconds。我们曾经就踩过一个“坑”。当时，在我们的项目中，因为这个值在不同的哨兵实例上配置不一致，导致哨兵集群一直没有对有故障的主库形成共识，也就没有及时切换主库，最终的结果就是集群服务不稳定。所以，你一定不要忽略这条看似简单的经验。

    假设有一个Redis集群是"一主四从"，同时配置包含了5个哨兵实例的集群，quorum值为2，那么在运行过程中，如果3个哨兵实例发生故障，此时Redis主从如果有故障，还能正确判断主库"客观下线"嘛？还能进行主从库切换嘛?是不是哨兵实例越多越好？如果调大 down-after-milliseconds 值，能否减少误判？