Redis 的主库挂了，如何不间断服务？( 二 ) _Redis

一旦哨兵判断主库下线了，就会开始选择新主库，并让从库和新主库进行数据同步，这个过程本身就会有开销，例如，哨兵要花时间选出新主库，从库也需要花时间和新主库同步。而在误判的情况下，主库本身根本就不需要进行切换的，所以这个过程的开销是没有价值的。正因为这样，我们需要判断是否有误判，以及减少误判。
那怎么减少误判呢？在日常生活中，当我们要对一些重要的事情做判断的时候，经常会和家人或朋友一起商量一下，然后再做决定。
哨兵机制也是类似的，它通常会采用多实例组成的集群模式进行部署，这也被称为哨兵集群。引入多个哨兵实例一起来判断，就可以避免单个哨兵因为自身网络状况不好，而误判主库下线的情况。同时，多个哨兵的网络同时不稳定的概率较?。?伤?且黄鹱鼍霾?nbsp;，误判率也能降低。
这节课，你只需要先理解哨兵集群在减少误判方面的作用，就行了。至于具体的运行机制，下节课我们再重点学习。
在判断主库是否下线时，不能由一个哨兵说了算，只有大多数的哨兵实例，都判断主库已经“主观下线”了，主库才会被标记为“客观下线”，这个叫法也是表明主库下线成为一个客观事实了。这个判断原则就是：少数服从多数。同时，这会进一步触发哨兵开始主从切换流程。
为了方便你理解，我再画一张图展示一下这里的逻辑。
如下图所示，Redis 主从集群有一个主库、三个从库，还有三个哨兵实例。在图片的左边，哨兵 2 判断主库为“主观下线”，但哨兵 1 和 3 却判定主库是上线状态，此时，主库仍然被判断为处于上线状态。在图片的右边，哨兵 1 和 2 都判断主库为“主观下线”，此时，即使哨兵 3 仍然判断主库为上线状态，主库也被标记为“客观下线”了。

文章插图
客观下线的判断
简单来说， “客观下线”的标准就是，当有 N 个哨兵实例时，最好要有 N/2 + 1 个实例判断主库为“主观下线”，才能最终判定主库为“客观下线” 。这样一来，就可以减少误判的概率，也能避免误判带来的无谓的主从库切换。（当然，有多少个实例做出“主观下线”的判断才可以，可以由 Redis 管理员自行设定）。
好了，到这里，你可以看到，借助于多个哨兵实例的共同判断机制，我们就可以更准确地判断出主库是否处于下线状态。如果主库的确下线了，哨兵就要开始下一个决策过程了，即从许多从库中，选出一个从库来做新主库。
如何选定新主库？一般来说，我把哨兵选择新主库的过程称为“筛选 + 打分” 。简单来说，我们在多个从库中，先按照一定的筛选条件，把不符合条件的从库去掉。然后，我们再按照一定的规则，给剩下的从库逐个打分，将得分最高的从库选为新主库，如下图所示：

文章插图
新主库的选择过程
在上述段落中，我们需要明晰两个关键的“一定” 。现在，让我们详细讨论这里的“一定”究竟指的是什么。
首先，让我们来探讨所选从库的筛选条件。
通常情况下，我们必须确保所选的从库仍然处于在线运行状态。然而，在选择新主库时，仅仅考虑从库的当前在线状态是不够的，因为正常在线并不代表它就是最佳的主库选择。
设想一下，如果在选主时，我们选中一个正常在线的从库并开始使用它。不过，不久后，它的网络连接发生故障，这将迫使我们重新选择主库。这显然不符合我们的期望。
因此，在进行主库选择时，除了检查从库的当前在线状态，还需要考虑它以前的网络连接状态。如果一个从库经常与主库断开连接，并且断开连接的次数超出了特定的阈值，那么我们就有理由相信，这个从库的网络状况并不太可靠，因此可以将其排除在主库的选择之外。
具体怎么判断呢？你使用配置项 down-after-milliseconds * 10 。其中，down-after-milliseconds 是我们认定主从库断连的最大连接超时时间。如果在 down-after-milliseconds 毫秒内，主从节点都没有通过网络联系上，我们就可以认为主从节点断连了。如果发生断连的次数超过了 10 次，就说明这个从库的网络状况不好，不适合作为新主库。