Redis设计与实现（十）—— 哨兵

概述

哨兵的核心功能是主节点的自动故障转移，是配置提供者，不是代理，我们的客户端会去哨兵中去获取主节点的ip和host，然后自己去连接。而不是告诉哨兵后，由哨兵连接
下面提供的功能

• 监控：哨兵会不断地检查主节点和从节点是否运作正常。
• 自动故障转移：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中 一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
• 配置提供者：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。
• 通知：哨兵可以将故障转移的结果发送给客户端。

两种节点

在我们的哨兵架构中，主要会有两种节点组成：哨兵节点和数据节点：
哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的redis节点，不存储数据。
数据节点：主节点和从节点都是数据节点。

哨兵原理

1、定时任务：每个哨兵节点维护了3个定时任务，向主从节点发送info命令获取最新的主从结构，向其他节点发送ping命令判断是否下线，发布订阅功能获取其他哨兵的信息
2、主观下线：在心跳检测的定时任务里，如果其他节点超过一定时间没有回复，哨兵节点就会将其进行主观下线
3、客观下线：哨兵节点在对主节点进行主观下线后，会询问其他哨兵该主节点的状态，如果一定数量哨兵认为下线，则判断为客观下线，客观下线是主节点才有的概念，如果从节点和哨兵节点发生故障，被主观下线后，不会再有后续的客观下线和故障转移操作
4、选举领导者哨兵节点，当主节点被判断客观下线后，哨兵会进行协商，选举出一个领导者哨兵节点，并由该节点对其进行故障转移，使用raft算法，基本思路是先到先得，在一轮选举中，A向B发送成为领导者的申请，如果B没有同意其他哨兵，就会将同意A成为主
5、故障转移：被选举出来的哨兵节点开始进行故障转移操作，注意，故障转移的同时也会进行更新配置文件
5.1）在从节点中选择新的主节点：选择原则是先过滤掉不健康的从结点，然后选择优先级最高的从节点，如果优先级无法区分，选用offset最大的，也就是最新的节点，如果仍然无法区分，选用runid最小的从节点
5.2）更新主从状态：使用slave no one，让从节点变成主节点，然后让其他节点成为从节点
5.3）将已经下线的主节点设置成从节点，等到下次上线，成为从节点

主观和客观下线

主观下线：就一个哨兵如果自己觉得一个master宕机了，那么就是主观宕机。如果一个哨兵ping一个master，超过了is-master-down-after-milliseconds指定的毫秒数之后，就主观认为master宕机
客观下线，如果quorum数量的哨兵都觉得一个master宕机了，那么就是客观宕机，如果一个哨兵在指定时间内，收到了quorum指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown了，客观认为master宕机

哨兵集群的自动发现机制

哨兵互相之间的发现，是通过redis的pub/sub系统实现的。
1）每隔两秒钟，每个哨兵都会往自己监控的某个master+slaves对应的channel里发送一个消息，内容是自己的host、ip和runid还有对这个master的监控配置
2）每个哨兵也会去监听自己监控的每个master+slaves对应的hello channel，然后去感知到同样在监听这个master+slaves的其他哨兵的存在
3）每个哨兵还会跟其他哨兵交换对master的监控配置，互相进行监控配置的同步

选举的最小数量

每次一个哨兵要做主备切换，首先需要quorum数量的哨兵认为客观下线，然后选举出一个哨兵来做切换，这个哨兵还得得到majority一定数量的哨兵的同意，才能正式执行切换。这个参数一般是用来防止脑裂问题，当出现网络分区的时候，假设分成了两块区域，在这个条件下，两边的网络都没断，出现了两台主节点，类似于形成了互不通信的独立的两个集群，导致两边数据不进行同步，数据不一样，选择最小选举数量能有效解决脑裂问题。

如果quorum < majority，比如9个哨兵，多数派就是5，quorum设置为4，那么就5个哨兵授权就可以执行切换
但是如果quorum >= majority，那么必须quorum数量的哨兵都授权，比如9个哨兵，quorum是9，那么必须9个哨兵都同意授权，才能执行切换

影响主节点选举的一些参数

（1）跟master断开连接的时长
  首先，如果一个slave跟master断开连接已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么slave就被认为不适合选举为master

（2）slave优先级
  按照slave优先级进行排序，slave priority越低，优先级就越高

（3）复制offset
  如果slave priority相同，那么看replica offset，哪个slave复制了越多的数据，offset越靠后，复制了更多的数据，数据就更全，相反数据越少

（4）run id
  如果上面两个条件都相同，那么选择一个run id比较小的那个slave，注意runid是随机的

建议

1、哨兵节点的数量应该不止一个，一方面增加哨兵节点的冗余，避免哨兵本身成为高可用的瓶颈，另一方面减少对下线的误判
2、哨兵节点的数量应该是奇数，便于进行决策，例如领导者选举，客观下线的选举，也可以有效避免脑裂问题