08 | 哨兵集群：哨兵挂了，主从库还能切换吗？

老师请教下： 1、图示哨兵选举过程中，选举的结果取决于S2的投票，如果S2也投给自己，并且每轮投票都是只投给自己，岂不是无法选出“Leader”，是不是这个过程从了死循环呢？ 2、投票投给谁，依据是什么？

Redis 1主4从，5个哨兵，哨兵配置quorum为2，如果3个哨兵故障，当主库宕机时，哨兵能否判断主库“客观下线”？能否自动切换？ 经过实际测试，我的结论如下： 1、哨兵集群可以判定主库“主观下线”。由于quorum=2，所以当一个哨兵判断主库“主观下线”后，询问另外一个哨兵后也会得到同样的结果，2个哨兵都判定“主观下线”，达到了quorum的值，因此，哨兵集群可以判定主库为“客观下线”。 2、但哨兵不能完成主从切换。哨兵标记主库“客观下线后”，在选举“哨兵领导者”时，一个哨兵必须拿到超过多数的选票(5/2+1=3票)。但目前只有2个哨兵活着，无论怎么投票，一个哨兵最多只能拿到2票，永远无法达到多数选票的结果。 但是投票选举过程的细节并不是大家认为的：每个哨兵各自1票，这个情况是不一定的。下面具体说一下： 场景a：哨兵A先判定主库“主观下线”，然后马上询问哨兵B（注意，此时哨兵B只是被动接受询问，并没有去询问哨兵A，也就是它还没有进入判定“客观下线”的流程），哨兵B回复主库已“主观下线”，达到quorum=2后哨兵A此时可以判定主库“客观下线”。此时，哨兵A马上可以向其他哨兵发起成为“哨兵领导者”的投票，哨兵B收到投票请求后，由于自己还没有询问哨兵A进入判定“客观下线”的流程，所以哨兵B是可以给哨兵A投票确认的，这样哨兵A就已经拿到2票了。等稍后哨兵B也判定“主观下线”后想成为领导者时，因为它已经给别人投过票了，所以这一轮自己就不能再成为领导者了。 场景b：哨兵A和哨兵B同时判定主库“主观下线”，然后同时询问对方后都得到可以“客观下线”的结论，此时它们各自给自己投上1票后，然后向其他哨兵发起投票请求，但是因为各自都给自己投过票了，因此各自都拒绝了对方的投票请求，这样2个哨兵各自持有1票。 场景a是1个哨兵拿到2票，场景b是2个哨兵各自有1票，这2种情况都不满足大多数选票(3票)的结果，因此无法完成主从切换。 经过测试发现，场景b发生的概率非常小，只有2个哨兵同时进入判定“主观下线”的流程时才可以发生。我测试几次后发现，都是复现的场景a。 哨兵实例是不是越多越好？ 并不是，我们也看到了，哨兵在判定“主观下线”和选举“哨兵领导者”时，都需要和其他节点进行通信，交换信息，哨兵实例越多，通信的次数也就越多，而且部署多个哨兵时，会分布在不同机器上，节点越多带来的机器故障风险也会越大，这些问题都会影响到哨兵的通信和选举，出问题时也就意味着选举时间会变长，切换主从的时间变久。 调大down-after-milliseconds值，对减少误判是不是有好处？ 是有好处的，适当调大down-after-milliseconds值，当哨兵与主库之间网络存在短时波动时，可以降低误判的概率。但是调大down-after-milliseconds值也意味着主从切换的时间会变长，对业务的影响时间越久，我们需要根据实际场景进行权衡，设置合理的阈值。

这篇文章太好了，直接解决了一个困惑我很久的问题，我一直把判断下线和选主主当成了同一件事，把quorum当成是判断下线和选举leader的阀值，原来判断下线还选主是两个分开的事情

哨兵判断下线分为可能下线和确定下线两种状态。 在课后的例子中，5个哨兵正常2个，异常3个，qurum为2（判断确定下线的哨兵数目） 根据主从选举要求必须半数以上的节点同意，即要求数量大于N/2+1。此例中是5/2+1＝3，而只有2个哨兵活着因此不可能完成主从切换。 而确定下线的数目为2，2个哨兵可以完成确定下线的判断。

整个哨兵集群都挂了，还会主从切换吗

一，作者讲了什么？ 哨兵集群的工作机制 二，作者是怎么把这事给讲明白的？ 1，哨兵之间互通机制：基于pub/sub机制，在主库中有一个"__sentinel__:hello"的频道，哨兵之间互相发现通信 2，哨兵与主从库互通机制：哨兵向主库发送INFO指令，可以获取所有从库的信息，实现对主库，从库的监控 3，哨兵判定主库异常机制：哨兵集群中任意一个实例都可以发起主库异常“投票仲裁”流程 三，为了讲明白，作者都讲了哪些要点？有哪些亮点？ 1，亮点1：哨兵之间的互动是通过发布订阅机制完成的，利用自身的特性来实现。这让我联想到kafka对于日息位置偏移量的管理 2，要点1：哨兵之间通信不是哨兵之间之间联系，而是通过订阅主库的同一频道来获取彼此的信息 3，要点2：哨兵是通过INFO指令，从主库获取从库信息，并与每个从库建立连接，监控所有主从库状态 4，要点3：哨兵是一个特殊的redis实例，所以客户端可以订阅哨兵的指定频道获得redis主从库的信息 5，要点4：哨兵集群执行主从切换机制：谁发现，谁就发起投票流程，谁获得多数票，谁就是哨兵Leader，由Leader负责主从库切换 6，要点5：哨兵集群Leader选举成功与否，依赖于网络通信状况，网络拥塞会导致选举失败，重新进行新一轮选举 四，对于作者所讲，我有哪些发散性思考？ 五，在未来的哪些场景里，我可以使用它？ 六，留言区的收获：（感谢 @ 小喵喵 的提问） 1，哨兵投票机制： a：哨兵实例只有在自己判定主库下线时，才会给自己投票，而其他的哨兵实例会把票投给第一个来要票的请求，其后的都拒绝 b：如果出现多个哨兵同时发现主库下线并给自己投票，导致投票选举失败，就会触发新一轮投票，直至成功 2，哨兵Leader切换主从库的机制：（感谢 @Kaito ，@Darren 大神的解答） 哨兵成为Leader的必要条件：a：获得半数以上的票数，b：得到的票数要达到配置的quorum阀值 主从切换只能由Leader执行，而成为Leader有两个必要的条件，所以当哨兵集群中实例异常过多时，会导致主从库无法切换

1、可以正确的判断主库“客观下线”，以为其中一个哨兵已经获得了“客观下线”所需要的投票数； 2、不能进行自动的主从切换，因为在主从切换的时候，必须选择出一个主哨兵，但是选择主哨兵有2个条件： 2.1 拿到半数以上的赞成票； 2.2 拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。 此时可以满足投票数，但是拿不到半数以上的投票，因此无法选出主哨兵，所以无法进行主从切换。 3、哨兵的实例不是越多越好，因为哨兵的选举使用的是Raft协议，这个协议是Paxos协议的变种，这种协议在选主时，需要所有的节点参与投票，所以节点越多，选举耗时可能就会更久，所以根据对服务SLA的要求，评估一个节点可能出现问题的概率，选择合适的哨兵数量。 4、down-after-milliseconds不是越大越好的，虽然可以减少误判的概率，但是问题真正发生时，服务的不可用状态也会更久，所以down-after-milliseconds要根据真实的业务场景，进行取舍。

选举leader的过程和分布式Raft协议很像。之前写过一篇介绍Raft机制的文章，可以看看：《用动图讲解分布式Raft》https://mp.weixin.qq.com/s/US12ux7osqH_L0CtQyw-9A

在哨兵节点选取Leader 节点的时候，某个节点已经投出了 Y 票，但是该轮没有选举出来Leader, 这时候这个节点怎么知道已经到了下一轮需要继续投票了呢？ 也可以这样问：一个节点在一轮只能投出一个票，但是这个节点怎么知道一轮什么时候，什么时候结束的呢？

老师你好。看到“同时，哨兵又通过 INFO 命令，获得了从库连接信息，也能和从库建立连接，并进行监控了”这句话。我翻了一下代码sentinel.c/sentinelSendPeriodicCommands。发现sentinelSendPeriodicCommands里有一行代码： redisAsyncCommand(ri->cc, sentinelInfoReplyCallback, NULL, "INFO"); 的确哨兵也是会往从库发送INFO命令的，而从库的INFO返回值中，我发现包含以下的内容： run_id:d7e50cc730c3851fcb9d8b4b6af425f59e5207a6 slave_repl_offset:140354728 slave_priority:100 07节里说的三轮打分，是不是根据从库INFO监控信息来进行打分的？也就是说，第一轮根据slave_priority，第二轮根据slave_repl_offset，第三轮根据run_id。感觉和前面内容串起来了。 不对的地方，麻烦老师纠错下。