Redis哨兵机制详解

Redis主从架构中，当slave节点意外宕机后，可以通过全量同步或者增量同步来进行数据的恢复和同步。（这里不了解这个的朋友可以去看看我主页关于Redis主从数据同步原理的详解：传送门！快点我！）

但是大家有没有想过，如果Redis主从集群中，master宕机了呢！那应该怎么办呢？是不是就没人给它数据同步，导致整个业务挂掉了呢？因此我们本文介绍了Redis对于master节点宕机的解决方法：哨兵机制。

哨兵（Sentinel）的结构如图：

首先我们先要知道哨兵有啥作用，哨兵的作用如下：

• 监控：Sentinel 会不断检查您的master和slave是否按预期工作

• 自动故障恢复：如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主

• 通知：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端

1. 哨兵监控Redis主从集群原理

从上图我们可以看到，我们搭建了几个Sentinel（哨兵）集群来监控我们的Redis主从集群的健康状态，那么它们是如何监控的呢？

在详细介绍原理之前，我们需要了解两个概念：①主观下线 ②客观下线 ：

•主观下线：如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。

•客观下线：若超过指定数量（quorum）的sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。

Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送ping命令。（这里很像Eureka）。每个Sentinel向集群中的节点发送Ping，如果在规定的时间内，节点没有返回Pong的命令给Sentinel，则该Sentinel会判定该节点为“主观下线”。当判定该节点主观下线的Sentinel数量超过我们设置的“quorum”值时，则该节点“客观下线”。

2. 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节点。

如下图：

3. 总结

①Sentinel的三个作用是什么？

• 监控

• 故障转移

• 通知

②Sentinel如何判断一个redis实例是否健康？

• 每隔1秒发送一次ping命令，如果超过一定时间没有返回Pong则认为是主观下线

• 如果超过指定数量的sentinel都认为该节点主观下线，则让该节点下线（客观下线）

③故障转移步骤有哪些？

• 首先选定一个slave作为新的master，执行slaveof no one

• 然后让所有节点都执行slaveof 新master

• 修改故障节点配置，添加slaveof 新master