Redis高可用之---哨兵集群

1.概述

redis中存在一个高可用结构的重要进程,sentinel哨兵,可以实现监听主从、控制主从,完成主从复制基础之上的故障替换转移,主节点宕机,从节点顶替。

哨兵也是redis-server进程,比较特殊,不处理数据增删查改,只负责监听主从。

2.运行原理

2.1结构

在主从结构之上,需要引入哨兵行程集群（下面的结构为一主二从三哨兵）

哨兵执行逻辑 ：
1.哨兵启动会连接主节点 
2.调用info replication 获取到主从集群的所有节点信息 
3.开启每秒钟的心跳检测(rpc远程通信协议),判断节点是否存活 

• 从节点宕机,哨兵进程只会做记录 down 
• 主节点宕机,哨兵开始发起投票选举,在多个从节点中选择其中一个顶替成为新的主节点,其他从节点哨兵重新挂接到新的主节点 

4.投票需要过半机制. 

• 如果3个哨兵进程,2个以上选择同一个从节点,这个从节点才能顶替原有主节点提供功能 
• 不过半的投票结果是作废的,将会隔一段时间重新投票 

哨兵需要搭建集群（不让让一个哨兵说了算，否则网络波动一个可能判断失误）
哨兵配置不合理，可能出现平衡的选举，就会等待一段时间，重新选举，为了避免这种情况，一般一主二从三哨兵，就不会出现哨兵选举出现平票的情况。

2.2宕机情况

2.2.1从节点宕机

从节点宕机后，哨兵会记录该节点的宕机状态，当该节点重写启动，原来的宕机事件的记录就被去掉

2.2.2 主节点宕机

redis之所以引入哨兵进程就是为了监听主从,实现一个主从结构的故障替换逻辑。
当哨兵发现master主节点宕机，epoch逻辑时终值,主节点宕机,会在时终值上自增1.然后哨兵开始进行投票,投票2个从节点到底选择谁来当新的主节点（哨兵通过调用节点命令slaveof 重新挂接新的主节点），产生了新的主节点后，原来的主节点就不在是主节点，恢复后可以重新挂接到新的主节点

2.3原理

• 在哨兵中需要配置监听管理的主节点 
• 哨兵会连接主节点,从而获取所有集群节点信息,调用主节点的info replication,记录 
• 每隔一段时间(3秒) 向所有节点发送心跳检测(RPC心跳),判断节点是否宕机 

宕机处理 
1.从节点宕机,哨兵只负责记录,从节点恢复之后,记录修改 
2.主节点宕机,哨兵心跳检测发现宕机,询问其他哨兵,确定宕机.开始执行顶替选举 

• 从节点中选择一个顶替的节点作为新的主 
• 将其他存活的从节点重新挂接到新的节点 
• 记录原来主节点宕机,原有主节点恢复,哨兵修改宕机记录,将原有主节点挂接新节点

哨兵中的执行任务--事件,故障转移,替换就是一个时间,都要经过投票逻辑,只有最终某一个结果是过半票数支持,才通过