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

哨兵集群组成和运行机制

• 基于 pub/sub 机制的哨兵集群组成

基于 pub/sub 机制的哨兵集群组成

• 哨兵之间可以互相发现，使用了Redis 提供的 pub/sub 机制，也就是发布 / 订阅机制。
• 哨兵只要和主库建立起连接，就可以在主库上发布消息，比如说发布自己的连接信息（IP 和端口）
• 可以从主库上订阅消息，获得其他哨兵发布的连接信息。当多个哨兵实例都在主库上做了发布和订阅操作后，它们之间就能知道彼此的 IP 地址和端口
• 只有订阅了同一个频道的应用，才能通过发布的消息进行信息交换
• 哨兵订阅__sentinel__:hello

哨兵如何获取从库的ip地址

• 哨兵向主库发送INFO类型的链接，然后就可以获得所有从库的信息，然后和从库建立连接

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

• 客户端从哨兵这里订阅消息
• 哨兵把新主库选择出来后，客户端就会看到switch-master 事件，表示主库已经切换了，新主库的 IP 地址和端口信息已经有了。这个时候，客户端就可以用这里面的新主库地址和端口进行通信switch-master <master name> <oldip> <oldport> <newip> <newport>
• 

选定一个哨兵进行主从切换

• 当一个哨兵发现与主库链接断开也就是认为主库主观下线后，就会与其他实例通信，其他实例判断是否连接到主库，对发起主库链接失败的哨兵进行投票，如果投票同意数量大于配置的话，就会认为主库客观下线
• 每个哨兵只能投一票同意一票拒绝，并且先收到的投票请求是同意的，后收到的拒绝的
• 若一轮投票后，没有选出leader，然后哨兵集群会等待一段时间（也就是哨兵故障转移超时时间的 2 倍），再重新选举
  

所有哨兵同时投自己一票

• 发生S1、S2和S3同时同自己投票的情况，这需要这三个哨兵基本同时判定了主库客观下线。但是，不同哨兵的网络连接、系统压力不完全一样，接收到下线协商消息的时间也可能不同，所以，它们同时做出主库客观下线判定的概率较小，一般都有个先后关系。
• 其次，哨兵对主从库进行的在线状态检查等操作，是属于一种时间事件，用一个定时器来完成，一般来说每100ms执行一次。每个哨兵的定时器执行周期都会加上一个随机时间偏移，目的是让每个哨兵执行上述操作的时间能稍微错开些，也是为了避免它们都同时判定主库下线，同时选举Leader