Redis的哨兵集群是怎么通信的

在我们对Redis的sycn与psync的区别中说了读写分离，但是故障切换的问题还没有说到，这次我们就说一个Redis的高可用的方案

Redis的哨兵

什么是哨兵：在我们刚写项目的时候，可能看开发文档上面写着请编写的变量能从字面意思就理解了。我们从哨兵的字面意思看，什么是哨兵呢？M78星云怎么没有人放哨呢，又被贝利亚给杀进来了，
哨兵就是入侵前的预警，但是Redis中的哨兵就不是预警了而是可以打赢贝利亚的奥特曼。如：主从master挂了，可以把slave提升为master角色，继续对外提供业务，来实现高可用，

简单的哨兵流程图：

在上图中：上图我们部署的哨兵模式是经典的三台哨兵模式，而为什么说三台是经典的哨兵模式呢？不搭建俩台哨兵集群呢？

说到这个问题：我们先了解下哨兵的自动切换机制

主观宕机与客观宕机（不懂的意思在下文解释了）

在Redis的哨兵中有sdown和odown俩种失败状态，sdown是主观宕机，就一个哨兵如果自己觉得一个master宕机了，那么就是主观宕机,odown是客观宕机，如果quorum数量的哨兵都觉得一个master宕机了，那么就是客观宕机。
sdown达成的条件很简单，如果一个哨兵ping一个master，超过了is-master-down-after-milliseconds指定的毫秒数之后，就主观认为master宕机。sdown到odown转换的条件很简单，如果一个哨兵在指定时间内，收到了quorum指定数量的其他哨兵也认为那个master是sdown了，那么就认为是odown了，客观认为master宕机。

哨兵集群的自动发现机制

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

slave配置的自动纠正

哨兵会负责自动纠正slave的一些配置，比如slave如果要成为潜在的master候选人，哨兵会确保slave在复制现有master的数据; 如果slave连接到了一个错误的master上，比如故障转移之后，那么哨兵会确保它们连接到正确的master上。

quorum和majority

每次一个哨兵要做主备切换，首先需要quorum数量的哨兵认为odown，然后选举出一个哨兵来做切换，这个哨兵还得得到majority哨兵的授权，才能正式执行切换。如果quorum < majority，比如5个哨兵，majority就是3，quorum设置为2，那么就3个哨兵授权就可以执行切换。但是如果quorum >= majority，那么必须quorum数量的哨兵都授权，比如5个哨兵，quorum是5，那么必须5个哨兵都同意授权，才能执行切换。

**

看到上面的引出的我们应该对上面的问题有了回答吧？

为什么不搭建俩台哨兵的集群呢？

如最少 quorum =1，majority要比quorum大 所以他得是 2 而执行故障切换的时候需要经过majority同意就是这个范围的哨兵投票同意，所以就得全部的哨兵同意才能执行故障转移，所以可用性就不高，三台挂了一台哨兵还是可以执行故障转移，可用性就高点，这里我为什么引出了这个问题呢？面试的时候你不会知道面试官的套路，所以多了解也无妨。

在上面中我还说了哨兵集群的自动发现机制这个机制是一个阿里的面试题：

你能说说Redis的哨兵是怎么通信的吗？

通过Redis的订阅发布来实现集群间的通信

扩展内容：

心跳检测
怎么知道master还存活呢？我们的哨兵会发送一个info指令获取到master的信息跟master之间保持心跳检测

在故障发生时，需要立即启动故障恢复机制，那么如何保证及时性呢？
每个哨兵节点每隔1秒向master、slave、其他哨兵节点发送ping命令，如果对方能在指定时间内响应，说明节点健康存活。如果未在规定时间内（可配置）响应，那么该哨兵节点认为此节点主观下线。

选举哨兵领导者
确认master节点真正故障后，就需要进入到故障恢复阶段。如何进行故障恢复，也需要经历一系列流程。
首先需要选举出一个哨兵领导者，由这个专门的哨兵领导者来进行故障恢复操作，不用多个哨兵都参与故障恢复。选举哨兵领导者的过程，需要多个哨兵节点共同协商来选出。
这个选举协商的过程，在分布式领域中叫做达成共识，协商的算法叫做共识算法。
共识算法主要为了解决在分布式场景下，多个节点如何针对某一个场景达成一致的结果。
共识算法包括很多种，例如Paxos、Raft、Gossip算法等，(可以说下Raft算法，其他俩个复杂)。
哨兵选举领导者的过程类似于Raft算法，它的算法足够简单易理解。
简单来讲流程如下：

• 每个哨兵都设置一个随机超时时间，超时后向其他哨兵发送申请成为领导者的请求
• 其他哨兵只能对收到的第一个请求进行回复确认
• 首先达到多数确认选票的哨兵节点，成为领导者
• 如果在确认回复后，所有哨兵都无法达到多数选票的结果，那么进行重新选举，直到选出领导者为止

选择出哨兵领导者后，之后的故障恢复操作都由这个哨兵领导者进行操作。
选择新的master
哨兵领导者针对发生故障的master节点，需要在它的slave节点中，选择一个节点来代替其工作。
这个选择新master过程也是有优先级的，在多个slave的场景下，优先级按照：slave-priority配置 > 数据完整性 > runid较小者进行选择。
也就是说优先选择slave-priority最小值的slave节点，如果所有slave此配置相同，那么选择数据最完整的slave节点，如果数据也一样，最后选择runid较小的slave节点。
提升新的master
经过优先级选择，选出了备选的master节点后，下一步就是要进行真正的主从切换了。
哨兵领导者给备选的master节点发送slaveof no one命令，让该节点成为master。
之后，哨兵领导者会给故障节点的所有slave发送slaveof $newmaster命令，让这些slave成为新master的从节点，开始从新的master上同步数据。
最后哨兵领导者把故障节点降级为slave，并写入到自己的配置文件中，待这个故障节点恢复后，则自动成为新master节点的slave。
至此，整个故障切换完成。
客户端感知新master
最后，客户端如何拿到最新的master地址呢？
哨兵在故障切换完成之后，会向自身节点的指定pubsub中写入一条信息，客户端可以订阅这个pubsub来感知master的变化通知。我们的客户端也可以通过在哨兵节点主动查询当前最新的master，来拿到最新的master地址。
另外，哨兵还提供了“钩子”机制，我们也可以在哨兵配置文件中配置一些脚本逻辑，在故障切换完成时，触发“钩子”逻辑，通知客户端发生了切换，让客户端重新在哨兵上获取最新的master地址。