哨兵机制：主库挂了，如何不间断服务？

咱们都了解 Redis主从库集群模式。在这个模式下，若是从库发生故障了，客户端能够继续向主库或其余从库发送请求，进行相关的操做，可是若是主库发生故障了，那就直接会影响到从库的同步，由于从库没有相应的主库能够进行数据复制操做了。

并且，若是客户端发送的都是读操做请求，那还能够由从库继续提供服务，这在纯读的业务场景下还能被接受。可是，一旦有写操做请求了，按照主从库模式下的读写分离要求，须要由主库来完成写操做。此时，也没有实例能够来服务客户端的写操做请求了，以下图所示：

不管是写服务中断，仍是从库没法进行数据同步，都是不能接受的。因此，若是主库挂了，咱们就须要运行一个新主库，好比说把一个从库切换为主库，把它当成主库。这就涉及到三个问题：

1. 主库真的挂了吗？

2. 该选择哪一个从库做为主库？

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

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

哨兵机制的基本流程

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

咱们先看监控。监控是指哨兵进程在运行时，周期性地给全部的主从库发送 PING 命令，检测它们是否仍然在线运行。若是从库没有在规定时间内响应哨兵的 PING 命令，哨兵就会把它标记为“下线状态”；一样，若是主库也没有在规定时间内响应哨兵的 PING 命令，哨兵就会断定主库下线，而后开始自动切换主库的流程。

这个流程首先是执行哨兵的第二个任务，选主。主库挂了之后，哨兵就须要从不少个从库里，按照必定的规则选择一个从库实例，把它做为新的主库。这一步完成后，如今的集群里就有了新主库。

而后，哨兵会执行最后一个任务：通知。在执行通知任务时，哨兵会把新主库的链接信息发给其余从库，让它们执行 replicaof 命令，和新主库创建链接，并进行数据复制。同时，哨兵会把新主库的链接信息通知给客户端，让它们把请求操做发到新主库上。

我画了一张图片，展现了这三个任务以及它们各自的目标。

在这三个任务中，通知任务相对来讲比较简单，哨兵只须要把新主库信息发给从库和客户端，让它们和新主库创建链接就行，并不涉及决策的逻辑。可是，在监控和选主这两个任务中，哨兵须要作出两个决策：

• 在监控任务中，哨兵须要判断主库是否处于下线状态；

• 在选主任务中，哨兵也要决定选择哪一个从库实例做为主库。

接下来，咱们就先说说如何判断主库的下线状态。

你首先要知道的是，哨兵对主库的下线判断有“主观下线”和“客观下线”两种。那么，为何会存在两种判断呢？它们的区别和联系是什么呢？

主观下线和客观下线

哨兵进程会使用 PING 命令检测它本身和主、从库的网络链接状况，用来判断实例的状态。若是哨兵发现主库或从库对 PING 命令的响应超时了，那么，哨兵就会先把它标记为“主观下线”。

若是检测的是从库，那么，哨兵简单地把它标记为“主观下线”就好了，由于从库的下线影响通常不太大，集群的对外服务不会间断。

可是，若是检测的是主库，那么，哨兵还不能简单地把它标记为“主观下线”，开启主从切换。由于颇有可能存在这么一个状况：那就是哨兵误判了，其实主库并无故障。但是，一旦启动了主从切换，后续的选主和通知操做都会带来额外的计算和通讯开销。

为了不这些没必要要的开销，咱们要特别注意误判的状况。

首先，咱们要知道啥叫误判。很简单，就是主库实际并无下线，可是哨兵误觉得它下线了。误判通常会发生在集群网络压力较大、网络拥塞，或者是主库自己压力较大的状况下。

一旦哨兵判断主库下线了，就会开始选择新主库，并让从库和新主库进行数据同步，这个过程自己就会有开销，例如，哨兵要花时间选出新主库，从库也须要花时间和新主库同步。而在误判的状况下，主库自己根本就不须要进行切换的，因此这个过程的开销是没有价值的。正由于这样，咱们须要判断是否有误判，以及减小误判。

那怎么减小误判呢？在平常生活中，当咱们要对一些重要的事情作判断的时候，常常会和家人或朋友一块儿商量一下，而后再作决定。

哨兵机制也是相似的，它一般会采用多实例组成的集群模式进行部署，这也被称为哨兵集群。引入多个哨兵实例一块儿来判断，就能够避免单个哨兵由于自身网络情况很差，而误判主库下线的状况。同时，多个哨兵的网络同时不稳定的几率较小，由它们一块儿作决策，误判率也能下降。

如何选定新主库？

通常来讲，我把哨兵选择新主库的过程称为“筛选 + 打分”。简单来讲，咱们在多个从库中，先按照必定的筛选条件，把不符合条件的从库去掉。而后，咱们再按照必定的规则，给剩下的从库逐个打分，将得分最高的从库选为新主库，以下图所示：

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

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

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

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

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

每一个实例都会有一个 ID，这个 ID 就相似于这里的从库的编号。目前，Redis 在选主库时，有一个默认的规定：在优先级和复制进度都相同的状况下，ID 号最小的从库得分最高，会被选为新主库。

总结

哨兵机制，它是实现 Redis 不间断服务的重要保证。具体来讲，主从集群的数据同步，是数据可靠的基础保证；而在主库发生故障时，自动的主从切换是服务不间断的关键支撑。

Redis 的哨兵机制自动完成了如下三大功能，从而实现了主从库的自动切换，能够下降 Redis 集群的运维开销：

• 监控主库运行状态，并判断主库是否客观下线；

• 在主库客观下线后，选取新主库；

• 选出新主库后，通知从库和客户端。