Redis Sentinel基本实现原理

一.出现的背景:
Redis 主从复制模式下一旦主节点由于故障不能提供服务,需要人工将从节点晋升为主节点,同时还要通知应用方更新主节点地址,对于很多应用这种场景的这种故障处理方式是非常浪费人力的。为了提供Redis主从的高可用性,Redis从2.8版本开始提供Redis Sential(哨兵)架构来解决问题。
 
二.架构图:
 
三.Redis Sentinel的高可用方案主要介绍:
由上图可以看到Redis Sentinel是一个分布式架构,包含若干个Sentinel节点和Redis数据节点,每个Sentinel节点会对数据节点和其余Sentinel节点进行监控,当它发现节点不可达时,会对节点做下线标识,如果被标识的是主节点,它还会和其他Sentinel节点进行“协商”,当大多数Sentinel节点都认为主节点不可达时他们会选举出一个Sentinel节点来完成自动故障转移的工作,选举出新的主节点,将老的主节点降级为从节点,同时会将这个变化实时通知给Redis应用方。
 
四.基本实现原理:
1.执行三个定时任务用于获取及同步各端(主节点、从节点、Sentinel节点)信息:
   A.每隔10秒获得主从节点信息;(通过info命令)
   B.每隔2秒同步主节点及当前sentinel节点信息; (通过redis的订阅功能)
   C.每隔1秒各个Sentinel节点实现同其他端之间的心跳检测;(通过ping命令)
 
2.下线有问题的节点:
   主观下线:每个Sentinel节点会每隔1秒对主从节点及其他Sentinel节点发送ping命令做心跳检测,当这些节点超过down-after-milliseconds没有进行有效回复时Sentinel节点会对该节点做失败判定,这个行为即主观下线。(该主观下线的判定是当前一个Sentinel的判定所以也存在误判的可能,比如刚好那时的网络问题)
    客观下线:当Sentinel接待主观下线的是主节点时,该Sentinel会通过sentinel is-master-down-by-addr命令其他Sentinel节点询问对主节点的判断,当超过quorum(判定主节点最终不可达所需的票数)个数时,Sentinel节点会认为该主节点确实有问题,这时Sentinel节点会做出客观下线的决定。
 
3.领导者Sentinel节点选举(Raft算法)用于去做故障转移的leader(即选谁去领导这次故障转移,现实中一般是谁先发现了这个故障谁就成为leader的可能性最大,而且这个选举的过程很快)。
   该选举过程主要包含:
    (1)每个在线的Sentinel节点都有资格成为领导者,当它确认主观下线时会向其他Sentinel节点发送sentinel is-master-down-by-addr命令,要求将自己设置为领导着。
    (2)收到命令的Sentinel节点如果没同意过其他Sentinel节点的sentinel is-master-down-by-addr命令,则将统一改请求,否则拒绝。
    (3)如果该Sentinel节点发现自己的票数已经大于等于max(quorum,num(sentinels)/2+1),那么它将成为领导者。(现实中一旦一个Sentinel节点获得了max(quorum,num(sentinels)/2+1) 的票数,其他Sentinel节点再去确认已经没有意义因为每个Sentinel节点只有一票)
    (4)如果此过程没有选举出领导者,则将进入下一次类似这样的选举。
 
4.故障转移:
   (1).Sentine领导者节点从从节点列表中选出一个节点作为新的主节点,选择过程如下图:
           
   (2).Sentinel领导者节点会对第一步选出来的从节点执行slaveof no one命令让其成为主节点。
   (3).Sentinel领导者节点会向剩余的从节点发送命令,并让他们成为新主节点的从节点。
   (4)Sentinel节点集合将原来的主节点更新为从节点,并保持对其关注,当其回复后命令它去复制新的主节点数据。 

posted on 2019-08-03 15:19  Ryanyanglibin  阅读(...)  评论(...编辑  收藏

导航