[Redis]哨兵机制

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

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

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

• [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节点
作为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节点
  共同判断为主观下线才行。

当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节点选举