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

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

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

哨兵之间的相互发现

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

• 哨兵将本身的链接信息 (ip, port) 发布到主库上, 其它哨兵订阅

• 本身编写的应用程序也能够经过 Redis 进行消息的发布和订阅

• Redis 会以频道的形式，对这些消息进行分门别类的管理

所谓的频道，实际上就是消息的类别。当消息类别相同时，它们就属于同一个频道。反之，就属于不一样的频道。只有订阅了同一个频道的应用，才能经过发布的消息进行信息交换。

在主从集群中，主库上有一个名为“__sentinel__:hello”的频道，不一样哨兵就是经过它来相互发现，实现互相通讯的。

哨兵除了彼此之间创建起链接造成集群外，还须要和从库创建链接。这是由于，在哨兵的监控任务中，它须要对主从库都进行心跳判断，并且在主从库切换完成后，它还须要通知从库，让它们和新主库进行同步。

哨兵如何发现从库 ip, port

这是由哨兵向主库发送 INFO 命令来完成的。

哨兵也和客户端链接:

• 主从库切换后，客户端也须要知道新主库的链接信息，才能向新主库发送请求操做。因此，哨兵还须要完成把新主库的信息告诉客户端这个任务。

• 实际使用哨兵时要求，客户端可以获取到哨兵集群在监控、选主、切换这个过程当中发生的各类事件。

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

从本质上说，哨兵就是一个运行在特定模式下的 Redis 实例，只不过它并不服务请求操做，只是完成监控、选主和通知的任务。因此，每一个哨兵实例也提供 pub/sub 机制，客户端能够从哨兵订阅消息。哨兵提供的消息订阅频道有不少，不一样频道包含了主从库切换过程当中的不一样关键事件。

让客户端从哨兵这里订阅消息:

• 客户端读取哨兵的配置文件后，能够得到哨兵的地址和端口，和哨兵创建网络连

• 在客户端执行订阅命令，来获取不一样的事件消息

// 订阅“全部实例进入客观下线状态的事件”：
SUBSCRIBE +odown

// 订阅全部的事件
PSUBSCRIBE  *

当哨兵把新主库选择出来后，客户端就会看到下面的 switch-master 事件。这个事件表示主库已经切换了，新主库的 IP 地址和端口信息已经有了。这个时候，客户端就能够用这里面的新主库地址和端口进行通讯了。

switch-master <master name><oldip><oldport><newip><newport>

3由哪一个哨兵执行主从切换？

判断主库下线的过程:

1. 任何一个实例只要自身判断主库“主观下线”后，就会给其余实例发送 is-master-down-by-addr 命令。接着，其余实例会根据本身和主库的链接状况，作出 Y 或 N 的响应，Y 至关于同意票，N 至关于反对票。

   一个哨兵得到了仲裁所需的同意票数后，就能够标记主库为“客观下线”。这个所需的同意票数是经过哨兵配置文件中的 quorum 配置项设定的。例如，如今有 5 个哨兵，quorum 配置的是 3，那么，一个哨兵须要 3 张同意票，就能够标记主库为“客观下线”了。这 3 张同意票包括哨兵本身的一张同意票和另外两个哨兵的同意票。

2. 此时，这个哨兵就能够再给其余哨兵发送命令，代表但愿由本身来执行主从切换，并让全部其余哨兵进行投票。这个投票过程称为“Leader 选举”。由于最终执行主从切换的哨兵称为 Leader，投票过程就是肯定 Leader。

任何一个想成为 Leader 的哨兵，要知足两个条件:

• 拿到半数以上的同意票

• 拿到的票数同时还须要大于等于哨兵配置文件中的 quorum 值

以 3 个哨兵为例，假设此时的 quorum 设置为 2，那么，任何一个想成为 Leader 的哨兵只要拿到 2 张同意票，就能够了。

若是 S3 没有拿到 2 票 Y，那么这轮投票就不会产生 Leader。哨兵集群会等待一段时间（也就是哨兵故障转移超时时间的 2 倍），再从新选举。这是由于，哨兵集群可以进行成功投票，很大程度上依赖于选举命令的正常网络传播。若是网络压力较大或有短时堵塞，就可能致使没有一个哨兵能拿到半数以上的同意票。因此，等到网络拥塞好转以后，再进行投票选举，成功的几率就会增长。

须要注意的是，若是哨兵集群只有 2 个实例，此时，一个哨兵要想成为 Leader，必须得到 2 票，而不是 1 票。因此，若是有个哨兵挂掉了，那么，此时的集群是没法进行主从库切换的。所以，一般咱们至少会配置 3 个哨兵实例。这一点很重要，你在实际应用时可不能忽略了。

4总结支持哨兵集群的这些关键机制:

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

• 基于 INFO 命令的从库列表，这能够帮助哨兵和从库创建链接；

• 基于哨兵自身的 pub/sub 功能，这实现了客户端和哨兵之间的事件通知。

最后，我想再给你分享一个经验：要保证全部哨兵实例的配置是一致的，尤为是主观下线的判断值 down-after-milliseconds。咱们曾经就踩过一个“坑”。当时，在咱们的项目中，由于这个值在不一样的哨兵实例上配置不一致，致使哨兵集群一直没有对有故障的主库造成共识，也就没有及时切换主库，最终的结果就是集群服务不稳定。因此，你必定不要忽略这条看似简单的经验。