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

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

sentinel monitor <master-name> <ip> <redis-port> <quorum> 

二、基于 pub/sub 机制的哨兵集群组成（哨兵间通信）

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

A、哨兵只要和主库建立起了连接，就可以在主库上发布消息了，比如说发布它自己的连接信息（IP 和端口）。

B、同时，它也可以从主库上订阅消息，获得其他哨兵发布的连接信息。当

C、多个哨兵实例都在主库上做了发布和订阅操作后，它们之间就能知道彼此的 IP 地址和端口。

2、为了区分不同应用的消息，Redis 会以频道的形式，对这些消息进行分门别类的管理。

A、所谓的频道，实际上就是消息的类别。

B、当消息类别相同时，它们就属于同一个频道。反之，就属于不同的频道。

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

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

a、哨兵 1 把自己的 IP（172.16.19.3）和端口（26579）发布到“__sentinel__:hello”频道上，哨兵 2 和 3 订阅了该频道。

b、那么此时，哨兵 2 和 3 就可以从这个频道直接获取哨兵 1 的 IP 地址和端口号。

c、然后，哨兵 2、3 可以和哨兵 1 建立网络连接。

d、通过这个方式，哨兵 2 和 3 也可以建立网络连接

e 、这样一来，哨兵集群就形成了。

f、它们相互间可以通过网络连接进行通信，比如说对主库有没有下线这件事儿进行判断和协商。

三、哨兵是如何知道从库的 IP 地址和端口的呢？（哨兵与从库）

1、哨兵除了彼此之间建立起连接形成集群外，还需要和从库建立连接。

A、这是因为，在哨兵的监控任务中，它需要对主从库都进行心跳判断，

B、而且在主从库切换完成后，它还需要通知从库，让它们和新主库进行同步。

2、哨兵获得从库的 IP 地址和端口，是由哨兵向主库发送 INFO命令来完成的

A、哨兵 2 给主库发送 INFO 命令，主库接受到这个命令后，就会把从库列表返回给哨兵。

B、接着，哨兵就可以根据从库列表中的连接信息，和每个从库建立连接，并在这个连接上持续地对从库进行监控。

四、基于 pub/sub 机制的客户端事件通知（哨兵和客户端间的信息同步）

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

A、哨兵提供的消息订阅频道有很多，不同频道包含了主从库切换过程中的不同关键事件。（包括主库下线判断、新主库选定、从库重新配置。）

a、客户端读取哨兵的配置文件后，可以获得哨兵的地址和端口，和哨兵建立网络连接。

b、然后，我们可以在客户端执行订阅命令，来获取不同的事件消息。 

c、举个例子，你可以执行如下命令，来订阅“所有实例进入客观下线状态的事件”：

SUBSCRIBE +odown

当然，你也可以执行如下命令，订阅所有的事件：

PSUBSCRIBE  *

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

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

五、由哪个哨兵执行主从切换（类似”仲裁投票“）

哨兵集群要判定主库“客观下线”，需要有一定数量的实例都认为该主库已经“主观下线”了。

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

一个哨兵获得了仲裁所需的赞成票数后，就可以标记主库为“客观下线”。

这个所需的赞成票数是通过哨兵配置文件中的 quorum 配置项设定的。

例如，现在有 5 个哨兵，quorum 配置的是 3，那么，一个哨兵需要 3 张赞成票，就可以标记主库为“客观下线”了。这 3 张赞成票包括哨兵自己的一张赞成票和另外两个哨兵的赞成票。 

在投票过程中，任何一个想成为 Leader 的哨兵，要满足两个条件：第一，拿到半数以上的赞成票；第二，拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。以 3 个哨兵为例，假设此时的 quorum 设置为 2，那么，任何一个想成为 Leader 的哨兵只要拿到 2 张赞成票，就可以了。

如果这轮投票不会产生 Leader，哨兵集群会等待一段时间（也就是哨兵故障转移超时时间的 2 倍），再重新选举。这是因为，哨兵集群能够进行成功投票，很大程度上依赖于选举命令的正常网络传播。

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

六、小结

​​​​​​​为了实现主从切换，我们引入了哨兵；为了避免单个哨兵故障后无法进行主从切换，以及为了减少误判率，又引入了哨兵集群；哨兵集群又需要有一些机制来支撑它的正常运行。

支持哨兵集群的这些关键机制，包括：

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

基于 INFO 命令的从库列表，这可以帮助哨兵和从库建立连接；

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

 对于主从切换，当然不是哪个哨兵想执行就可以执行的，否则就乱套了。所以，这就需要哨兵集群在判断了主库“客观下线”后，经过投票仲裁，选举一个 Leader 出来，由它负责实际的主从切换，即由它来完成新主库的选择以及通知从库与客户端。

要保证所有哨兵实例的配置是一致的，尤其是主观下线的判断值 down-after-milliseconds。