redis哨兵机制

哨兵机制

如果主库挂了，那我们就需要一个新的主库，比如把一个从库变成新的主库，这涉及到三个问题

1.主库真的挂了吗

2.谁来当新主库

3.怎么把新主库的相关信息通知给从库和客户端

定义：

哨兵就是运行在redis上的一个进程，它有三个任务，监控，选主，通知

监控：

哨兵在运行时会周期性的给所有的主从库发送ping命令，检测它是否是在线状态，如果从库没有响应，哨兵就会判定他是下线状态，主库如果不响应，就会判断主库下线，开始自动转换主库的流程

选主：

主库挂了以后，哨兵就需要从很多个从库里，按照一定的规则选择一个从库实例，把它作为新的主库。这一步完成后，现在的集群里就有了新主库。

通知：

哨兵会把新主库的信息发送给其他从库，让它们和新主库建立连接，进行数据复制，同时通知客户端，以后的请求发给新主库

主观下线和客观下线

哨兵在监控主库是否下线的时候可能受制于自己的网络问题等原因发生误判，也就是主库其实没有下线，但哨兵认为它下线开始了主从切换，主从切换过程资源消耗较大。

因此为了避免出现误判，引入了多实例组成的集群模式进行部署哨兵，多个哨兵一起判断这个主库是否下线了，避免单个哨兵网络不好的情况

主观下线就是某个哨兵认为主库下线了，客观下线是一定量的哨兵都认为主库下线了，主库才会被标记为客观下线

最好要有 N/2 + 1 个实例判断主库为“主观下线”，才能最终判定主库为“客观下线”。（多少实例，管理员可以调）

如何选择新主库

选主库的过程主要是两个“筛选+打分”。

筛选：筛选的条件主要是从库要在线，但是在选举时候从库在线不够有说服力，可能它过一会就下线了，所以除了检查从库的当前状态， 还要检查从库之前的网络状态，如果它经常和之前的主库断联说明它的网络状态不太好，不适合做新主库。这里有一个阈值判断，断连次数超出了一定的阈值，我们就有理由相信，这个从库的网络状况并不是太好，就可以把这个从库筛掉了。

打分：

第一轮：优先级最高的从库得分最高

用户可以通过 slave-priority 配置项，给不同的从库设置不同优先级。比如，你有两个从库，它们的内存大小不一样，你可以手动给内存大的实例设置一个高优先级。在选主时，哨兵会给优先级高的从库打高分，如果有一个从库优先级最高，那么它就是新主库了。如果从库的优先级都一样，那么哨兵开始第二轮打分。

第二轮：和旧主库同步程度最接近的从库得分高。

这个规则的依据是，如果选择和旧主库同步最接近的那个从库作为主库，那么，这个新主库上就有最新的数据。

我们想要找的从库，它的 slave_repl_offset 需要最接近 master_repl_offset。如果在所有从库中，有从库的 slave_repl_offset 最接近 master_repl_offset，那么它的得分就最高，可以作为新主库。

第三轮：ID号小的从库得分高

在优先级和复制进度都相同的情况下，ID 号最小的从库得分最高，会被选为新主库。

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

pub/sub机制就是发布订阅机制

部署哨兵集群的时候，配置哨兵时只设置了主库的信息，并没有给其他哨兵的连接信息，那么哨兵之间是如何连接上的呢？

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

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

哨兵除了彼此要形成集群外，还需要和从库建立连接，方便监控

这是由哨兵向主库发送 INFO 命令来完成的。主库会把从库列表给哨兵

但是，哨兵不能只和主、从库连接。因为，主从库切换后，客户端也需要知道新主库的连接信息，才能向新主库发送请求操作。所以，哨兵还需要完成把新主库的信息告诉客户端这个任务。

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

有哪个哨兵进行主从切换

确定由哪个哨兵执行主从切换的过程，和主库“客观下线”的判断过程类似，也是一个“投票仲裁”的过程。

客观下线的流程：

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

此时，这个哨兵就开始再给其他哨兵发送命令，希望自己来执行主从切换，并且让其他哨兵投票。这个投票过程称为“Leader 选举”。因为最终执行主从切换的哨兵称为 Leader，投票过程就是确定 Leader。

想成为leader，要满足两个条件：拿到半数以上的赞成票，且票数高于等于配置文件中的quorum值。

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

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