哨兵集群的组成和运行机制
基于 pub/sub 机制的哨兵集群组成
- 哨兵实例之间可以相互发现，要归功于 Redis 提供的 pub/sub 机制，也就是发布 / 订阅机制。
- 哨兵只要和主库建立起了连接，就可以在主库上发布消息了，比如说发布它自己的连接信息（IP 和端口）。同时，它也可以从主库上订阅消息，获得其他哨兵发布的连接信息。当多个哨兵实例都在主库上做了发布和订阅操作后，它们之间就能知道彼此的 IP 地址和端口。
- 为了区分不同应用的消息，Redis 会以频道的形式，对这些消息进行分门别类的管理。所谓的频道，实际上就是消息的类别。当消息类别相同时，它们就属于同一个频道。反之，就属于不同的频道。只有订阅了同一个频道的应用，才能通过发布的消息进行信息交换。
- 在主从集群中，主库上有一个名为“sentinel:hello”的频道，不同哨兵就是通过它来相互发现，实现互相通信的。
哨兵是如何知道从库的 IP 地址和端口的呢？
- 这是由哨兵向主库发送 INFO 命令来完成的
- 哨兵给主库发送 INFO 命令，主库接受到这个命令后，就会把从库列表返回给哨兵
运行机制
- 通过 pub/sub 机制，哨兵之间可以组成集群
- 同时，哨兵又通过 INFO 命令，获得了从库连接信息，也能和从库建立连接，并进行监控了
- 主从库切换后，客户端也需要知道新主库的连接信息，才能向新主库发送请求操作。所以，哨兵还需要完成把新主库的信息告诉客户端这个任务。
基于 pub/sub 机制的客户端事件通知
- 哨兵就是一个运行在特定模式下的 Redis 实例，只不过它并不服务请求操作，只是完成三个任务
- 监控
- 选主
- 通知
- 每个哨兵实例也提供 pub/sub 机制，客户端可以从哨兵订阅消息
- 哨兵提供的消息订阅频道有很多，不同频道包含了主从库切换过程中的不同关键事件
由哪个哨兵执行主从切换？
- 和主库“客观下线”的判断过程类似，也是一个“投票仲裁”的过程
- 一个哨兵获得了仲裁所需的赞成票数后，就可以标记主库为“客观下线”
- 这个所需的赞成票数是通过哨兵配置文件中的 quorum 配置项设定的
接下来，每个哨兵都会向其他哨兵发送命令，表明希望由自己来执行主从切换，并让所有其他哨兵进行投票。这个投票过程称为Leader 选举。因为最终执行主从切换的哨兵称为 Leader，投票过程就是确定 Leader。
如果本轮选举失败，过一段时间（也就是哨兵故障转移超时时间的 2 倍）会重新选举
注意
- 如果哨兵集群只有 2 个实例，此时，一个哨兵要想成为 Leader，必须获得 2 票，而不是 1 票。
- 所以，如果有个哨兵挂掉了，那么，此时的集群是无法进行主从库切换的。
- 因此，通常我们至少会配置 3 个哨兵实例。
- 要保证所有哨兵实例的配置是一致的，尤其是主观下线的判断值 down-after-milliseconds
小结：支持哨兵集群的关键机制
- 基于 pub/sub 机制的哨兵集群组成过程；
- 基于 INFO 命令的从库列表，这可以帮助哨兵和从库建立连接；
- 基于哨兵自身的 pub/sub 功能，这实现了客户端和哨兵之间的事件通知。
调大down-after-milliseconds值，对减少误判是不是有好处？
- 有好处，适当调大down-after-milliseconds值，当哨兵与主库之间网络存在短时波动时，可以降低误判的概率。
- 但是调大down-after-milliseconds值也意味着主从切换的时间会变长，对业务的影响时间越久，我们需要根据实际场景进行权衡，设置合理的阈值。