实际上，一旦多个实例组成了哨兵集群，即使有哨兵实例出现故障挂掉了，其他哨兵还能继续协作完成主从库切换的工作，包括判定主库是不是处于下线状态，选择新主库，以及通知从库和客户端。
1 基于 pub/sub 机制的哨兵集群组成
哨兵之间的相互发现
哨兵实例之间可以相互发现，要归功于 Redis 提供的 pub/sub 机制，也就是发布 订阅机制。
哨兵将自己的连接信息 (ip, port) 发布到主库上, 其它哨兵订阅
自己编写的应用程序也可以通过 Redis 进行消息的发布和订阅
Redis 会以频道的形式，对这些消息进行分门别类的管理
所谓的频道，实际上就是消息的类别。当消息类别相同时，它们就属于同一个频道。反之，就属于不同的频道。只有订阅了同一个频道的应用，才能通过发布的消息进行信息交换。
在主从集群中，主库上有一个名为“__sentinel__:hello”的频道，不同哨兵就是通过它来相互发现，实现互相通信的。
哨兵除了彼此之间建立起连接形成集群外，还需要和从库建立连接。这是因为，在哨兵的监控任务中，它需要对主从库都进行心跳判断，而且在主从库切换完成后，它还需要通知从库，让它们和新主库进行同步。
哨兵如何发现从库 ip, port
这是由哨兵向主库发送 INFO 命令来完成的。
哨兵也和客户端连接:
主从库切换后，客户端也需要知道新主库的连接信息，才能向新主库发送请求操作。所以，哨兵还需要完成把新主库的信息告诉客户端这个任务。
实际使用哨兵时要求，客户端能够获取到哨兵集群在监控、选主、切换这个过程中发生的各种事件。
2 基于pub/sub机制的客户端事件通知
从本质上说，哨兵就是一个运行在特定模式下的 Redis 实例，只不过它并不服务请求操作，只是完成监控、选主和通知的任务。所以，每个哨兵实例也提供 pub/sub 机制，客户端可以从哨兵订阅消息。哨兵提供的消息订阅频道有很多，不同频道包含了主从库切换过程中的不同关键事件。
让客户端从哨兵这里订阅消息:
客户端读取哨兵的配置文件后，可以获得哨兵的地址和端口，和哨兵建立网络连
在客户端执行订阅命令，来获取不同的事件消息
// 订阅“所有实例进入客观下线状态的事件”：
SUBSCRIBE +odown
// 订阅所有的事件
PSUBSCRIBE *
