redis高可用之哨兵模式

一、什么是哨兵模式？

在redis主从模式下，如果主节点出现故障，需要从从节点中选举一个新的主节点，将其余从节点的主节点改变成新的主节点，同时要通知redis客户端主节点已经更换，等到原主节点恢复，还要将原主节点变成新主节点的从节点，这一系列操作，需要一个自动化的过程，哨兵模式就是自动完成这一系列操作，保证redis的高可用。具体点就是可以配置启动一系列哨兵节点，由它们来监控数据节点的状态，发生故障是做故障转移。

二、哨兵模式是如何实现的？

节点发现-> 心跳检测->主观下线->客观下线->哨兵领导选举->故障转移

三个定时任务：

节点发现：每个哨兵节点会开启一个定时任务，每隔10s向主节点和从节点发送info命令，获取数据节点的拓扑结构

节点间交换信息（发现新的哨兵节点、同步对主节点状态的判断）：每个哨兵节点会开启一个定时任务，每隔2s向数据节点的_sentinel_:hello频道上发送当前哨兵节点的信息以及对主节点的判断

心跳检测：每个哨兵节点会开始一个定时任务，每隔1s向主节点、从节点、其它哨兵节点发生ping命令，如果目标节点超过down-after-milliseconds未回复，则任务目标节点下线（主观下线）

客观下线：当一个哨兵主观下线的是主节点时，该哨兵会向其它哨兵发生命令 is-master-down-by-addr，询问其它哨兵观察到的master的状态，如果有超过<quorum>个哨兵都主观下线了主节点，那么可以认为主节点确实有问题，可以客观下线。（对于从节点和其它哨兵节点主观下线后，没有后面的客观下线判断和故障转移操作）

哨兵领导选举：确认主节点客观下线后，需要做故障转移，做故障转移之需要一个哨兵节点来指挥，所以需要选举一个哨兵领导，大致策略：当一个哨兵发现主节点主观下线后，会问其它哨兵节点对主节点状态的，并且要求将自己设为哨兵领导，其它哨兵收到请求后，如果没有同意过其它哨兵节点，就会同意，否则就会拒绝，如果发起请求的哨兵发现有超过max（quorum，nums(sentinels) /2 +1）个哨兵同意直接当领导，则升级为领导。

故障转移：哨兵领导遍历从节点，过滤掉不健康的从节点，再按优先级选、如果没有优先级，再选复制偏移量最大的（数据最全），如果一样，选runid最小的从节点，哨兵领导对选出来的从节点执行slaveof no one，让它成为主节点，并向其它从节点发送命令，让它们把主节点改成新的主节点，最后将原来的主节点更新为从节点，等其恢复后，让它去复制新的主节点。

 

以上结构保证了主节点的高可用，这种场景下，从节点只是作为主节点的一个热备，并不参与客户端操作。有些浪费，现在很多读写分离的场景，要把从节点也利用起来，所以从节点也应该保障高可用。

四、从节点如何保障高可用？

哨兵在对各个节点的监控中，如果有时间发生，会发出相应的事件通知，所以能够获取到从节点的状态，所以可以把从节点看着一个资源池，通过监控各节点的状态，模拟主节点的故障转移机制，实现从节点高可用。具体实现方式待研究