你真的了解Redis的哨兵机制吗？

前言

之前介绍了Redis通过主从集群模式来保持数据一致性。当从库故障时，客户端依然能正常读写操作。但是当主库故障时，因为我们设置的是只往主库写数据，此时如果有大量写操作的请求，Redis就无法接收到新数据了。

当这种情况发生时，我们就需要一种机制来解决这个问题，那就是需要一个新的主库了。今天就来说说redis的哨兵机制。

初识redis哨兵机制

在redis主从集群中，主从库的切换就是通过哨兵机制来控制的。说到底，哨兵机制就是Redis的一个关键进程。它时刻在关注着集群的状态，哨兵的工作可以归纳为：

• 监控集群
• 选出主库
• 通知集群

监控集群

这个工作，就是哨兵定期联络整个集群实例（发ping命令），当从库没有在规定时间内响应的话，哨兵就会认为该从库处于“下线状态”，此时影响不大。

但当主库没响应时，主库会被认为处于下线状态，此时会影响写的操作，因此会开始切换主库的动作。

选出主库

当主库被标记为下线状态时，“选主”就是关键步骤了。哨兵就会按照设定好的规则，从所有的从库中选出最适合的一个作为主库，这样一来集群又有主库了，写操作才不会受到影响。

推选主库的方法，可以理解为设定了多个推选规则，分多轮筛选主库，根据不同的权重和步骤，最终确认替换主库的从库实例。

通知集群

这个步骤，哨兵会将推选出的新主库信息发给其他从库实例，这样从库就会更新主库信息，从而与新主库进行数据同步工作。而且哨兵也会将新主库的信息传递给客户端，这样客户端就会将写请求发到新主库中去。

用图来总结一下哨兵的工作就是：

深入哨兵机制

哨兵如何判定主从库的下线

监控工作中，哨兵会将断连的实例标记相应状态。具体来说，如果从库响应超时，哨兵直接将它标记成“主观下线”。但如果是主库的话，标记工作就得谨慎起来了，因为一旦标记"主观下线"，选主就得开始了。

业界常规的做法是建立哨兵集群，当判定主库下线的哨兵数量 大于 判定主库未下线的的哨兵数量，此时才会真正认为主库挂了，从而将主库标记为“客观下线”，然后就开始选主的工作了。

哨兵如何选主

选主的过程可总结为“筛选——>多轮打分”。

筛选过程

此过程会检查各个从库实例的网络状况，而且要看之前的网络状态是否稳定（看断连次数是否超过设定的阀值），如果总是断连，只是当前稳定，也不能通过我们的筛选。

打分过程

打分主要分3轮执行：

1. 第一轮：按照优先级知道从库得分。这个我们可在配置文件中slave-priority参数设定。
2. 第二轮：和下线的主库按照同步程度打分。也就是说从库和旧的主库同步延迟越小，得分就越高。同步程度我们可比较旧主库的master_repl_offset值和从库的slave_repl_offset值之间的差异得出。
3. 第三轮：从库编号ID小的从库得分高。如果前两轮出现了得分一致的多个从库，此时直接就选出ID最小的那个从库。

经过筛选和打分过程，新的主库就推选出来了。接下来就好办了，哨兵就新主库的信息通知下去了。

小结

这篇文章主要介绍了redis哨兵机制是如何运作的。从哨兵机制的运作原理，我们可学到redis设计者的智慧，那就是要面对不同的状况，通过相应的机制去应对之。