（八）哨兵机制的集群模式

本文主要知识点：

基于 pub/sub 机制的哨兵集群组成过程；
基于 INFO 命令的从库列表，这可以帮助哨兵和从库建立连接；
基于哨兵自身的 pub/sub 功能，这实现了客户端和哨兵之间的事件通知。

哨兵集群

在哨兵模式下建立多个哨兵，一般建立三个或三个以上构成哨兵集群
设置哨兵服务的主库：
sentinel monitor <master-name> <ip> <redis-port> <quorum>

在这里哨兵只需要指定它所服务的主库ip和端口就可以了。并没有指定哨兵集群中其他哨兵，那哨兵之间怎么进行数据传输和相互工作的呢？这里就需要从哨兵集群的组成和运行机制进行学习了。

基于 pub/sub 机制的哨兵集群模式

发布订阅模式：就像csdn中一样，用户可以订阅博主的相关专栏，当博主在指定专栏中发布相关的内容时，用户就可以收到该文章的通知信息。

Redis 就提供了 发布/订阅 模式。在哨兵集群的发布订阅中，哨兵相当于用户，主库相当于博主。哨兵只要和主库建立起了连接，就可以在主库上发布消息了，比如说发布它自己的连接信息（IP 和端口）。同时，它也可以从主库上订阅消息，获得其他哨兵发布的连接信息。当多个哨兵实例都在主库上做了发布和订阅操作后，它们之间就能知道彼此的 IP 地址和端口。

频道

除了哨兵实例，我们自己编写的应用程序也可以通过 Redis 进行消息的发布和订阅。所以，为了区分不同应用的消息，Redis 会以频道的形式，对这些消息进行分门别类的管理。所谓的频道，实际上就是消息的类别。当消息类别相同时，它们就属于同一个频道。反之，就属于不同的频道。只有订阅了同一个频道的应用，才能通过发布的消息进行信息交换。

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

当 哨兵1 与主库建立连接后，主库的 “sentinel:hello” 频道中会存放 哨兵1 的相关信息。同时，主库会将其他哨兵的信息发布给 哨兵1 ，这样 哨兵1 就可以通过 “sentinel:hello” 知道其他哨兵的相关信息了。

上面讲解的是哨兵之间通过 Redis 的发布订阅模式 建立起之间的联系。

那么哨兵在主库客观下线后成功选取了新主库后，如何通过其他从库信息了，我们可没有在哨兵中配置过从库相关的ip和端口。

哨兵通过INFO命令获取从库信息

哨兵2 与主库建立连接后，并不知道其他从库的存在，此时需要向主库发送一条INFO 命令，主库会返回该哨兵slave列表，该列表中记录了与主库相连的从库的相关信息。 哨兵1 接收到这个slave列表后，就会根据其中的ip和端口与对应的从库建立连接。这样哨兵就可以对与主库连接的从库进行监控了。

这样一来，通过上面的两种方式，哨兵就可以在只配置主库的情况下成功监控主库和所有的从库了。

但是哨兵不能只与主库、从库建立连接。因为当进行了主从库切换后，相应的主客户端、从客户端也需要做出相应的改变，客户端也需要知道新主库的连接信息，才能向新主库发送请求操作。所以，哨兵还需要完成把新主库的信息告诉客户端这个任务。

如何在客户端通过监控了解哨兵进行主从切换的过程呢？比如说，主从切换进行到哪一步了？这其实就是要求，客户端能够获取到哨兵集群在监控、选主、切换这个过程中发生的各种事件。此时，我们仍然可以依赖 pub/sub 机制，来帮助我们完成哨兵和客户端间的信息同步。

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

从本质上说，哨兵就是一个运行在特定模式下的 Redis 实例，只不过它并不服务请求操作，只是完成监控、选主和通知的任务。所以，每个哨兵实例也提供 pub/sub 机制，客户端可以从哨兵订阅消息。哨兵提供的消息订阅频道有很多，不同频道包含了主从库切换过程中的不同关键事件。
这里可以看出 哨兵既可以看成订阅者，也可以看成发布者。

客户端需要在哨兵上订阅相关的频道，从而获取指定的信息，下面是一些主要的频道及其事件：

客户端如何订阅哨兵？

客户端读取哨兵的配置文件，可以获取哨兵的端口和ip，从而与哨兵建立连接。之后客户端执行相关命令来订阅指定的频道。
SUBSCRIBE +odown :订阅主库下线事件
PSUBSCRIBE * :订阅所有事件

如果订阅了所有事件，客户端不仅可以在主从切换后得到新主库的连接信息，还可以监控到主从库切换过程中发生的各个重要事件。这样，客户端就可以知道主从切换进行到哪一步了，有助于了解切换进度。

通过上述讲解可知：通过发布订阅模式，哨兵与哨兵之间，哨兵与从库之间、哨兵与客户端之间成功建立的连接。保证了 哨兵 三大任务的正常执行。

还有一个问题：现在有多个哨兵了，那么由哪一个哨兵来执行主从切换呢？

Leader选取

判定过程和“客观下线”判定过程类似，都是由多个哨兵进行综合评价的。
任何一个哨兵实例只要自身判定主库“主观下线”后，就会给其他实例发送 is-master-down-by-addr 命令。接着，其他实例会根据自己和主库的连接情况，做出 Y 或 N 的响应，Y 相当于赞成票，N 相当于反对票。（一个哨兵实例只有一张赞成票）

一个哨兵获得了仲裁所需的赞成票数后，就可以标记主库为“客观下线”。这个所需的赞成票数是通过哨兵配置文件中的 quorum 配置项设定的。例如，现在有 5 个哨兵，quorum 配置的是 3，那么，一个哨兵需要 3 张赞成票，就可以标记主库为“客观下线”了。这 3 张赞成票包括哨兵自己的一张赞成票和另外两个哨兵的赞成票。此时，这个哨兵就可以再给其他哨兵发送命令，表明希望由自己来执行主从切换，并让所
有其他哨兵进行投票。这个投票过程称为“Leader 选举”。因为最终执行主从切换的哨兵称为 Leader，投票过程就是确定 Leader。在投票过程中，任何一个想成为 Leader 的哨兵，要满足两个条件：第一，拿到半数以上的赞成票；第二，拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。以 3 个哨兵为例，假设此时的 quorum 设置为 2，那么，任何一个想成为 Leader 的哨兵只要拿到2 张赞成票，就可以了。

Leader选取注意

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