Redis主从架构中,当slave节点意外宕机后,可以通过全量同步或者增量同步来进行数据的恢复和同步。(这里不了解这个的朋友可以去看看我主页关于Redis主从数据同步原理的详解:传送门!快点我!)
但是大家有没有想过,如果Redis主从集群中,master宕机了呢!那应该怎么办呢?是不是就没人给它数据同步,导致整个业务挂掉了呢?因此我们本文介绍了Redis对于master节点宕机的解决方法:哨兵机制。
哨兵(Sentinel)的结构如图:
![](https://i-blog.csdnimg.cn/blog_migrate/2524ee820cf4c87c81897b21552b5a0d.png)
首先我们先要知道哨兵有啥作用,哨兵的作用如下:
监控:Sentinel 会不断检查您的master和slave是否按预期工作
自动故障恢复:如果master故障,Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主
通知:Sentinel充当Redis客户端的服务发现来源,当集群发生故障转移时,会将最新信息推送给Redis的客户端
哨兵监控Redis主从集群原理
从上图我们可以看到,我们搭建了几个Sentinel(哨兵)集群来监控我们的Redis主从集群的健康状态,那么它们是如何监控的呢?
在详细介绍原理之前,我们需要了解两个概念:①主观下线 ②客观下线 :
•主观下线:如果某sentinel节点发现某实例未在规定时间响应,则认为该实例主观下线。
•客观下线:若超过指定数量(quorum)的sentinel都认为该实例主观下线,则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。
Sentinel基于心跳机制监测服务状态,每隔1秒向集群的每个实例发送ping命令。(这里很像Eureka)。每个Sentinel向集群中的节点发送Ping,如果在规定的时间内,节点没有返回Pong的命令给Sentinel,则该Sentinel会判定该节点为“主观下线”。当判定该节点主观下线的Sentinel数量超过我们设置的“quorum”值时,则该节点“客观下线”。
Redis主从集群故障恢复原理
上面我们说了哨兵机制监控主从集群是否健康的原理。回到我们文章一开始说的一个需要解决的问题:“如果Redis主从集群中,master宕机了应该怎么办”?这里就涉及到Redis主从集群的master节点故障时,其恢复原理了:
一旦发现master故障,sentinel需要在salve中选择一个作为新的master,选择依据是这样的:
首先会判断slave节点与master节点断开时间长短,如果超过指定值(可以在配置文件中配置),则会排除该slave节点。
然后判断slave节点的slave-priority值,越小优先级越高,如果是0则永不参与选举。
如果slave-prority一样,则判断slave节点的offset值,越大说明数据越新,优先级越高。
最后是判断slave节点的运行id大小,越小优先级越高。
那么,当旧master节点故障后,Sentinel从slave节点从选出新master节点后,二者是如何进行切换的呢?
流程如下:
sentinel给选拔出的的slave节点发送slaveof no one命令,让该节点成为新的master节点。
sentinel给所有其它slave发送slave of (新master节点的IP地址 端口号) 命令,让这些slave成为新master的从节点,开始从新的master上同步数据。
最后,sentinel将故障节点标记为slave,当改故障节点(旧master节点)恢复后会自动成为新的master的slave节点。
如下图:
![](https://i-blog.csdnimg.cn/blog_migrate/a2c263149fbf034be04a971fa98da732.png)
总结
①Sentinel的三个作用是什么?
监控
故障转移
通知
②Sentinel如何判断一个redis实例是否健康?
每隔1秒发送一次ping命令,如果超过一定时间没有返回Pong则认为是主观下线
如果超过指定数量的sentinel都认为该节点主观下线,则让该节点下线(客观下线)
③故障转移步骤有哪些?
首先选定一个slave作为新的master,执行slaveof no one
然后让所有节点都执行slaveof 新master
修改故障节点配置,添加slaveof 新master