1. 如何选定新主库？

哨兵选择新主库的过程称为“筛选 + 打分”。简单来说，我们在多个从库中，先按照一定的筛选条件，把不符合条件的从库去掉。然后，我们再按照一定的规则，给剩下的从库逐个打分，将得分最高的从库选为新主库。

1.1 筛选

• 一定的筛选条件指的是：一般情况下，我们肯定要先保证所选的从库仍然在线运行。不过，在选主时从库正常在线，这只能表示从库的现状良好，并不代表它就是最适合做主库的。设想一下，如果在选主时，一个从库正常运行，我们把它选为新主库开始使用了。可是，很快它的网络出了故障，此时，我们就得重新选主了。这显然不是我们期望的结果。
• 除了要检查从库当前在线状态，还要判断他之前的网络状态。如果从库总是和主库断连，而且断连次数超出了一定的阈值，我们就有理由相信，这个从库的网络状况并不是太好，就可以把这个从库筛掉了。
• 具体操作：使用配置项 down-after-milliseconds * 10。其中，down-after-milliseconds 是我们认定主从库断连的最大连接超时时间。如果在 down-after-milliseconds 毫秒内，主从节点都没有通过网络联系上，我们就可以认为主从节点断连了。如果发生断连的次数超过了 10 次，就说明这个从库的网络状况不好，不适合作为新主库。

1.2 打分

打分规则：一共三轮，这三轮是有先后顺序的。从库优先级>从库复制进度>从库ID号，每轮打分过后判断此轮过后有没有得分最高的从库，如果有，那么它就是主库了，选主到此结束了。如果没有出现得分最高的从库，那么就继续进行下一轮打分。具体每一轮的打分规则如下：

• 第一轮：优先级最高的从库得分高
  • 用户可以通过slave-priority配置项，给不同的从库设置不同的优先级。比如，你有两个从库，它们的内存大小不一样，你可以手动给内存大的实例设置一个高优先级。在选主时，哨兵会给优先级高的从库打高分，如果有一个从库优先级最高，那么它就是新主库了。如果从库的优先级都一样，那么哨兵开始第二轮打分。
• 第二轮：和旧主库同步程度最接近的从库得分高。
  • 这个规则的依据是，如果选择和旧主库同步最接近的那个从库作为主库，那么，这个新主库上就有最新的数据。如何判断从库和旧主库间的同步进度呢？上节课我向你介绍过，主从库同步时有个命令传播的过程。在这个过程中，主库会用 master_repl_offset 记录当前的最新写操作在 repl_backlog_buffer 中的位置，而从库会用 slave_repl_offset 这个值记录当前的复制进度。此时，我们想要找的从库，它的 slave_repl_offset 需要最接近 master_repl_offset。如果在所有从库中，有从库的 slave_repl_offset 最接近 master_repl_offset，那么它的得分就最高，可以作为新主库。
  • 就像下图所示，旧主库的 master_repl_offset 是 1000，从库 1、2 和 3 的 slave_repl_offset 分别是 950、990 和 900，那么，从库 2 就应该被选为新主库。如下图：

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

2.新问题

我们在实际应用时，哨兵机制通常采用多实例的方式进行部署，多个哨兵实例通过“少数服从多数”的原则，来判断主库是否客观下线。一般来说，我们可以部署三个哨兵，如果有两个哨兵认定主库“主观下线”，就可以开始切换过程。当然，如果你希望进一步提升判断准确率，也可以再适当增加哨兵个数，比如说使用五个哨兵。

• 这样会有新的挑战：两个问题
  • 哨兵集群当中有一个实例挂了，按照原来的n/2+1个哨兵主观下线的规则，现在可以就会变化了，这是否会影响主库状态判断和选主呢？
  • 哨兵集群多数实例达成共识，判断出主库”客观下线“后，由哪个实例来执行主从切换呢？

3.总结：

这节我们学习了哨兵的最重要的任务--选主。依靠的是哨兵机制，它是实现 Redis 不间断服务的重要保证。具体来说，主从集群的数据同步，是数据可靠的基础保证；而在主库发生故障时，自动的主从切换是服务不间断的关键支撑。 Redis 的哨兵机制自动完成了以下三大功能，从而实现了主从库的自动切换，可以降低 Redis 集群的运维开销：

• 监控主库运行状态，并判断主库是否客观下线；
• 在主库客观下线后，选取新主库；
• 选出新主库后，通知从库和客户端。 今天的学习先到这，下次我们将学习如何解决新的挑战。
• 《Redis核心技术与实战》学习笔记Day six