[Redis]哨兵机制

在之前的文章中介绍了 [Redis]主从复制机制，主从复制机制可以允许我们拓展节点来进行数据拷贝，可以根据业务场景进行读写分离、数据备份等功能，但是主节点Master出现异常时并不能实现自动地主从复制节点切换、故障处理转移等操作，本篇要介绍的 哨兵机制正是基于Redis的主从复制机制进行的节点监听管理机制，可以在出现上述问题时进行节点切换和故障转移，是一种Redis 高可用方案的实现机制。

架构拓扑

• Master（主节点） Redis的主服务数据库，负责接收业务数据的写入，一般为一个（这里不扩展分布式架构下sharding后的水平扩展下多Master，仅简单讨论Redis Sentinel一般架构拓扑）
• Slave（从节点） Redis的从服务数据库，复制Master节点数据，一般为多个
• Sentinel Node Sentinel哨兵节点，负责监听Master、Slave等业务数据节点情况，一般为多个形成哨兵集群节点，这也是哨兵机制自身高可用的一种体现

组成	角色定位	作用	数量
Master	业务数据主节点	接收客户端请求，可读可写	1
Slave	业务数据从节点	复制Master数据，灾备，可写（读写分离）	>=1
Sentinel Node	哨兵节点	监听Master、Slave业务数据节点，在故障发生时进行故障转移处理	>=1

运行机制

Redis Sentinel主要工作任务就是时刻监听所有Redis节点的状态，一旦发生异常根据预设值机制进行故障处理使Redis可以达到高可用。核心实现机制是，通过三个定时监控任务完成对各个节点发现和监控。

定时任务	触发间隔	功能
定时info	10s	Sentinel节点获取最新Redis节点信息和拓扑关系
定时publish/subscribe	2s	Sentinel节点通过订阅master频道进行彼此信息通互
定时ping	1s	Sentinel节点检查与所有Redis节点、其他Sentinel节点网络

• [Worker-1] 每隔10秒，每个Sentinel节点会向master和slave发送info命令获取 最新的拓扑结构。
  该定时任务的作用是： 当故障发生或有新节点加入时，可以定时获取和更新当前Redis节点的拓扑关系

在master节点执行info replication可查看主从复制信息如下：
Replication role:master connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=4917,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=4917,lag=1`

• [Worker-2] 每隔2秒，每个Sentinel节点会向Redis数据节点的_sentinel_：hello频道上发布（publish）该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息，同时每个Sentinel节点也会订阅（subcribe）该频道，来了解其他Sentinel节点以及它们对master的判断
  该定时任务的作用是： 所有的sentinel节点通过发布/订阅主节点的_sentinel_：hello进行节点间信息通互，为后面客观下线以及领导者选举提供依据

• [Worker-3] 每隔1秒，每个Sentinel节点会向master、slave、其他sentinel节点发送一条ping命令做一次心跳检测来确认这些节点当前是否可达

故障转移

• [step-1] 当sentinel node节点监听到master节点出现故障，slave从节点无法对master进行数据复制
  
• [step-2] sentinel node发现master节点异常，会在sentinel集群节点中内部进行投票选举出leader来进行master、slave业务数据节点故障进行转移处理，并通知client客户端

超时故障判断：
通过down-after-milliseconds参数进行配置，当超过该时间无响应则判断为节点故障

集群投票机制：
由于sentinel node是以集群形式存在的，当sentinel node监听到master节点异常时，会询问其他sentinel node进行所有节点集群投票确认决定下一步是否进行，这样能很好的减少单节点对故障的误判

• [step-3] 当新的master产生后，slave节点会复制新的master，但是还会继续监听旧的master节点
  
• [step-4] 当旧的master节点故障恢复后，由于sentinel集群一直监听，会重新将其纳入集群管理中，将其变为新的master节点的从节点，此时恢复后的故障节点变为slave，开始复制新的master节点，实现节点故障后的重复利用

以上为Redis Sentinel架构下故障转移流程，总结以上流程的时序图交互如下：

集群选举

Sentinel节点选举

由于sentinel是以集群形式存在来保证高可用，因此在故障处理时，需要先选举一个sentinel节点作为Leader进行操作，每一个sentinel节点都可以成为Leader。

选举过程：

• 当一个sentinel节点确认redis集群的主节点下线后
• 请求其他sentinel节点要求将自己选举为Leader。被请求的sentinel节点如果没有同意过其他sentinel节点的选举请求，则同意该请求，即选举票数+1，否则不同意。
• 当一个sentinel节点获得的选举票数达到Leader最低票数(sentinel节点数/2+1的最大值)，则该sentinel节点选举为Leader；否则重新进行选举。

Sentinel集群采用的是Raft算法进行选举，感兴趣可以继续探究该算法内部实现机制。

主观下线&客观下线：

• 主观下线
  Sentinel集群的每一个Sentinel节点会定时对redis集群的所有节点发心跳包检测节点是否正常。如果一个节点在down-after-milliseconds时间内没有回复Sentinel节点的心跳包，则该redis节点被该sentinel节点主观下线，所谓主观下线是单独一个节点判断，有可能此时该节点与master通信异常，而非master与全部节点交互异常，因此需要多个sentinel节点共同确认。
  
• 客观下线
  当节点被一个sentinel节点记为主观下线时，并不意味着该节点肯定故障了，还需要sentinel集群的其他sentinel节点共同判断为主观下线才行。

Redis节点选举

当sentinel集群选举出sentinel leader后，由sentinel leader从slave中选择一个作为master。

选举过程：

• 过滤故障的节点
• 选择优先级slave-priority最大的slave作为master，如不存在则继续
• 选择复制偏移量(offset)（数据写入量的字节，记录写了多少数据。主服务器会把偏移量同步给从服务器，当主从的偏移量一致，则数据是完全同步）最大的slave作为master，如不存在则继续
• 选择runid（redis每次启动的时候生成随机的runid作为redis的标识）最小的slave作为master，这里是一个随机方案也是最终兜底方案

参考

《Redis设计与实现》
《Redis开发与运维》
https://www.cnblogs.com/albert32/p/13393382.html Sentinel节点选举