Redis(六)：哨兵机制

上次说到主从库集群模式。在这个模式下，如果从库发生了故障，客户端可以继续向主库或者其他从库发送请求，进行相关的操作，但是如果主库发生了故障，那就没有直接会影响到从库的同步，因为从库没有相应的主库可以进行数据复制操作了。
而且，如果客户端发送发的都是读操作请求，那还可以由从库继续提供服务，在这纯读的业务场景下还能被接受。但是，一旦有些操作请求了，按照主从库模式下的读写分离要求，需要由主库来完成写操作。此时，也没用实例可以来服务客户端的写操作请求了，如图
无论是写服务中断，还是从库无法进行数据同步，都是不能接受的。所以，如果主库挂了，我们就需要运行一个新的主库，比如说把这个从库切换成主库。如果真让他成为主库，就需要确认以下三个问题：

1. 主库真的挂了吗？
2. 该怎么选择从库？
3. 怎么把新主库的相关信息通知给从库和客户端？
   这是涉及到哨兵机制了。在Redis主从集群中，哨兵机制是实现主从库切换的关键机制，它有效的解决了主从模式下的故障转移问题。

哨兵机制基本流程

哨兵其实就是一个运行在特殊模式下的Redis进程，主从库实例运行的同时，他也在运行。哨兵主要负载的就是三个任务：监控，选主和通知。
监控是指哨兵进程在运行时，周期性地给所有的主从库发送ping命令，如果从库没有在规定时间内相应哨兵的ping命令，哨兵就会判断主库下线，然后自动切换主库的流程
这个流程首先就是执行哨兵的第二个任务，选主。主库挂了以后，哨兵就需要从很多个从库里，按照一定的规则选择一个从库实例，把它作为新的主库。这一步完成后，现在的集群里就有了新主库。
然后哨兵就会执行最后一个任务：通知。在执行通知任务时，哨兵会把新主库的链接信息发给其他从库，让他们执行replicaof命令，和新主库建立链接，并进行数据复制。同时哨兵会把新主库的链接信息通知给库护短，让他们把请求操作发到新主库上。
我们画了一张图片，展示了着三个任务以及他们各自的目标。

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

• 在监控任务中，哨兵需要判断主库是否处于下线窗台；
• 在选主任务中，哨兵也要决定选择哪个从库作为主库。
  接下来，我们就先说说如何判断主库的下线状态。
  首先要知道的是，哨兵对主库的下线判断有“主观下线”和“客观下线”两种。那么，为什么会存在两种判断呢？他们的区别和联系是什么？

主观下线和客观下线

主观下线：哨兵进程会用PING命令检测他自己和主从库的网络情况，用来判断实例的状态。如果哨兵发现主库或从库对PING命令的响应超时了，那么，哨兵就会先把它标记为主观下线。
如果检测的事从库，那么哨兵简单地将其标记为“主观下线就行了”，因为从库的影响一般不会太大，集群的对外服务不会间断。
但是如果检测的是主库，那么，哨兵还不能简单地标记为“主观下线”，开启主从切换。因为和可能有这么一个情况：那就是哨兵误判，主库并未故障。可是，一旦启动了主从切换，后续的选主和通知操作都会带来额外的计算机和通行的开销。
为了避免这些不必要的开销，我们需要特别注意误判的情况。首先，我们要知道啥叫误判。很简单，就是主库实际并未下线，但是哨兵误以为它下线了。误判一般会发生在集群网络压力大、网络通塞、或者是主库本身压力比较大的情况下。
一旦哨兵判断主库下线了，就会开始选择新的主库，并让从库和新主库进行数据同步，这个过程本身就会有开销，例如，哨兵要花时间选出新主库，从库也需要花时间和新主库同步。而在误判的情况下，主库本身就不需要进行切换的，所有这个过程的开销是没有价值的