Redis：哨兵机制

【关于作者】

关于作者，目前在蚂蚁金服搬砖任职，在支付宝营销投放领域工作了多年，目前在专注于内存数据库相关的应用学习，如果你有任何技术交流或大厂内推及面试咨询，都可以从我的个人博客（https://0522-isniceday.top/）联系我

1.哨兵机制

主库挂了，涉及到三个问题：

（1）主库真的挂了吗

（2）该选择哪个从库作为主库

（3）怎么把主库的相关信息同步给从库和客户端呢？

因此就有了哨兵机制，哨兵机制是解决主从切换的关键，其有效的解决了主从复制模式下故障转移的上述问题

概念：哨兵其实就是运行再特殊模式下的redis进程，其主要负责的三个任务就是上述的三个问题：

• 监控
• 选择主库
• 通知

2.哨兵机制的流程

• 监控：哨兵再运行时，周期性的给所有主从库发送PING命令，如果从库没有在规定时间内响应PING命令，则将其标记为“下线状态”，主库若没有响应，则同样判定下线状态，并开始选主流程

• 选择主库：按照一定规则选择一个从库实例作为主库

• 通知：将新主库的信息同步给从库，让他们执行replicaof命令，执行与新主库的数据同步，同时把新主库的连接信息通知给客户端，让其把请求操作发送到新主库

  

其中：

• 在监控任务中，哨兵需要判断主库是否处于下线状态；
• 在选主任务中，哨兵也要决定选择哪个从库实例作为主库

2.1.监控–主观下线和客观下线

主观下线：常规时间内主从没有响应PING命令，则哨兵会将其标记为“主观下线”

客观下线：但是哨兵可能会由于网络，或主库负载较大出现误判的情形，因此这里可以引入多个哨兵组成集群（哨兵集群），同时进行判断并少数服从多数，如果有2n+1个哨兵认为主节点下线（个数可配置），则标记为“客观下线”，否则则为上线

具体实现：

任何哨兵认为主节点主观下线了，就会发送is-master-down-by-addr命令。接着其他哨兵收到命令后检查与主库的连接状况，根据状况返回Y或N，当赞成票数目大于所配置的quorum配置，则标记主库为客观下线。此时这个哨兵就可以进入leader选举流程了

2.2.如何选主

流程：筛选+打分，就是将不符合要求的从库筛选掉，按照一定的规则打分选主

（1）筛选：

• 检查从库的在线状态

• 网络连接情况，记录从库和主库的断连次数，比较设置的阈值，超过阈值则判断为网络连接不稳定过滤

  具体判断：配置项down-after-milliseconds（最大超时时间） * 10（次数） ，如果网络断连次数超过十次则代表网络连接不稳定

（2）打分

三个规则，从上到下规则进行选主，只有当某轮选不出才会进入下一轮

• 第一轮：从库优先级

  通过slave-priority配置项，给不同的从库配置优先级。（内存大的实例可以设置高优先级）

• 第二轮：从库复制进度

  和旧主库同步程度最接近的从库得分高，根据从库的slave_repl_offset与master_repl_offset进行比较，最接近的得分高

• 第三轮：从库ID号

  ID号最小的从库得分最高，会被选为新主库

2.3.一些问题：

1.哨兵在操作主从切换的过程中，客户端能否正常地进行请求操作？

读请求可以，写请求会失败，失败持续的时间 = 哨兵切换主从的时间 + 客户端感知到新主库，此时可以通过消息队列的方式防止数据丢失

down-after-milliseconds参数：响应超时时间配置

2.客户端如何感知主从切换？

（1）哨兵通知

哨兵将主库的地址写入自己实例的pubsub（switch-master）实例中，客户端会订阅这个pubsub，主从切换后哨兵会将主节点的信息放入pubsub

（2）客户端主动获取

但是如果哨兵通知客户端失败了该怎么办？客户端访问从库是可通过sentinel get-master-addr-by-name拿到地址，这样不管怎么样都能拿到最新的地址。

一般Redis的SDK都提供了通过哨兵拿到实例地址，再访问实例的方式

3.哨兵集群如果挂了个节点怎么办?

哨兵集群类似zk，多数可用即可

4.由哪个哨兵执行选主（主从切换）

通过选举选出“哨兵领导者”

3.哨兵集群

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

哨兵集群的配置信息中只配置了主库的IP和端口：sentinel monitor <master-name> <ip> <redis-port> <quorum>

• 获取哨兵地址

  就是基于pub/sub的订阅通知机制，只有订阅了同一个频道的应用，才能通过发布的消息进行信息交换。

  主从集群上，有一个名为__sentinel__:hello的频道，通过该频道，哨兵能够知道其他哨兵的地址，因此就能够互相之前通过建立连接进行通信。如下图：

  

• 获得从库地址

  哨兵通过向主库发送INFO命令，主库将发送从库的信息（slave列表）给哨兵，因此哨兵就能够建立与从库的连接并监控

  

• 客户端的主从切换推送

  哨兵也是一个redis服务，因此其也提供订阅/通知机制，客户端可以从哨兵订阅频道并获得不同的消息，例如订阅+switch-master来获得主从切换的通知，从消息中拿到新的主节点的信息并建立连接。

  几个关键事件如下：

  

3.2.哨兵Leader选举

选举时机：哨兵将主节点标记为”客观下线“后，将发起自己的选票选举为主从切换的哨兵节点

投票过程中，成为leader需要两个条件

（1）拿到半数的赞同票

（2）拿到的票数需要大于哨兵配置的quorum值（如果没有拿到半数票，但是拿到了超过quorum值的选票的话，还是无法成为leader节点）

选举流程如下：

其中当节点回复过Y之后，其它的选票会回复N，并且投过票后无法发起选票，节点进入判定“客观下线”的流程并得到Y就会发起选票流程。

当网络压力较大或有短时堵塞的时候，可能会产生没有节点得到半数的选票的场景，这个时候会等待哨兵故障转移超时时间的两倍的时间，再次发起选举。（哨兵的正常选举依赖网络指令的正常传播）

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

哨兵集群采用的类似于Raft的共识算法（指的是集群中多个节点如何就一个问题达成共识）进行Leader选举

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