一、哨兵机制解决的问题

为保证Redis服务不间断，提供了主从库集群，多实例对外提供服务。但是，如果主库挂了，怎么不间断服务呢？无论是写服务中断，还是从库无法进行数据同步，都是不能接受的。

如果主库挂了，我们就需要运行一个新主库，比如说把一个从库切换为主库，把它当成主库。这就涉及到三个问题：

主库真的挂了吗？
该选择哪个从库作为主库？
怎么把新主库的相关信息通知给从库和客户端呢？

在 Redis 主从集群中，哨兵机制是实现主从库自动切换的关键机制，它有效地解决了主从复制模式下故障转移的这三个问题。

哨兵机制：一个运行在特殊模式下的 Redis 进程，主从库实例运行的同时，它也在运行。哨兵主要负责的就是三个任务：监控、选主（选择主库）和通知。

二、哨兵机制的基本流程

1、监控

哨兵进程在运行时，周期性地给所有的主从库发送 PING 命令，检测它们是否仍然在线运行。

如果从库没有在规定时间内响应哨兵的 PING 命令，哨兵就会把它标记为“下线状态”；
如果主库也没有在规定时间内响应哨兵的 PING 命令，哨兵就会判定主库下线，然后开始自动切换主库的流程，进入【选主】流程

判断主库是否处于下线状态：

主观下线：

哨兵发现主库或从库对 PING 命令的响应超时了，那么，哨兵就会先把它标记为“主观下线”。

主观下线有时会存在误判：误判一般会发生在集群网络压力较大、网络拥塞，或者是主库本身压力较大的情况下。误判会带来选主，通知，重新主从同步等开销。所以需要进行再次判断。

客观下线：

哨兵机制也类似redis集群，它通常会采用多实例组成的集群模式进行部署，这也被称为【哨兵集群】。引入多个哨兵实例一起来判断，就可以避免单个哨兵因为自身网络状况不好，而误判主库下线的情况。同时，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。只有大多数的哨兵实例，都判断主库已经“主观下线”了，主库才会被标记为“客观下线”。【有多少个实例做出“主观下线”的判断才可以，可以由 Redis 管理员自行设定】

2、选主

主库挂了以后，哨兵就需要从很多个从库里，按照一定的规则选择一个从库实例，把它作为新的主库。

如何选定新主库：

哨兵选择新主库的过程称为“筛选 + 打分”。

首先在多个从库中按照一定的筛选条件，把不符合条件的从库去掉。

然后，我们再按照一定的规则，给剩下的从库逐个打分，将得分最高的从库选为新主库。

筛选条件：

除了要检查从库的当前在线状态，还要判断它之前的网络连接状态。

如果从库总是和主库断连，而且断连次数超出了一定的阈值，我们就有理由相信，这个从库的网络状况并不是太好，就可以把这个从库筛掉了。

打分规则：

分别按照三个规则依次进行三轮打分，这三个规则分别是从库优先级、从库复制进度以及从库 ID 号。只要在某一轮中，有从库得分最高，那么它就是主库了，选主过程到此结束。如果没有出现得分最高的从库，那么就继续进行下一轮。

从库优先级：用户可以通过 slave-priority 配置项，给不同的从库设置不同优先级。比如一个从库的内存大，就可以给他设置高优先级。

从库复制进度：选择和旧主库同步最接近的那个从库作为主库，进度接近的判断标准：【主从复制】中，支持增量复制机制中的repl_backlog_buffer 环形缓冲区的相对位置差。

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

3、通知

选主完成后，哨兵会把新主库的连接信息发给其他从库，让它们执行 replicaof 命令，和新主库建立连接，并进行数据复制。同时，哨兵会把新主库的连接信息通知给客户端，让它们把请求操作发到新主库上。

Redis_哨兵机制