Redis哨兵机制简介

Redis提供两种高可用解决方案，哨兵和集群，本文主要介绍哨兵系统的架构、高可用原理和故障处理过程。

Redis哨兵架构
Sentinel 是 Redis 的高可用解决方案，由一个或者多个 Sentinel 实例组成的 Sentinel 系统可以监控任意多个主服务器，以及这些主服务器下属的所有从服务器，并在被监控的主服务器下线之后，自动将其某个从服务器升级为主服务器，然后由新的主服务器代替已下线的主服务器继续处理请求。

Sentinel系统

如下图所示，这个 Sentinel 系统是由三个 Sentinel 实例监控一个主服务器，主服务器有三个从服务器，主服务器负责处理客户端发过来的请求，从服务器主要是从主服务器进行复制，当 Sentinel 系统检测到主服务器下线后，会从三台从服务器中选出一个来替代主服务器对外提供服务，以此来实现高可用。

Sentinel 故障处理

首先来了解一下如何定义服务下线，在默认情况下，Sentinel 会以每秒一次的频率向系统中的所有与它创建连接的实例，包括主服务器、从服务器和其他 Sentinel 实例，发送 ping 命令，并通过 ping 命令的回复来判断实例是否下线。配置文件通过配置

down-after-milliseconds

该参数表示，一个实例在 down-after-milliseconds 毫秒内，连续向 Sentinel 返回无效回复，那么该 Sentinel 主观认为这个实例下线了，这就是的监测，如下图所示

下线监测

sentinel B 监测到 server A 已下线，此时 sentinel B 主观认为 server A 下线，但是 Sentinel 系统中存在多个 Sentinel 实例，那么此时还不能判定该实例已经下线，sentinel B 会向 sentinel A 和 sentinel C 发送

SENTINEL is-master-down-by-addr    

命令来询问另外两个 Sentinel 是否认为 server A 已下线，命令中个参数含义如下，

• ip，server A 的 ip 地址；
• port，server A Redis 服务的端口号；
• current_epoch，Sentinel 当前的配置纪元；
• run_id，该值可以为“*”或者当前 sentinel 的 run_id，用于 sentinel leader 的选举。

另外两个接收到这个命令会进行回复，回复中包含如下三个方面的内容，

• down_state，对主服务器的监测结果，1代表主服务器已下线，0表示主服务器未下线；
• leader_runid，该值可以为“*”或者该 sentinel 所选举的 leader sentinel 的 run_id；
• leader_epoch，该 sentinel 所选举的 leader sentinel 的配置纪元。

sentinel B会根据 sentinel A 和 sentinel C 的回复判定 server A 是否下线，判定依据是半数以上的 sentinel 实例认为 server A 已下线，那么就认为 server A 了。

当 Sentinel 监测到有主服务器下线后，会从所有在线的 Sentinel 实例中选举出来一个领头羊，即 Leader Sentinel 来进行后续的故障转移操作，选举过程也是通过

SENTINEL is-master-down-by-addr    

命令来完成，当 current_epoch 为0，run_id 为*表示询问主节点的下线状态，若 current_epoch 为 sentinel B 的当前纪元，run_id 为 sentinel B 的 run_id，那么表示 sentinel B 希望命令接收者选举 sentinel B 为 Leader Sentinel。这个纪元用于选举，在一个纪元里，所有sentinel都有可能被选举成为领头羊，并且在这个纪元最多只能有一个领头羊，因为存在选举不成功的情况，一旦选举成功，在这个纪元里领头羊不能发生变更，并且每进行一次选举，配置纪元的值就会增加1。

Leader Sentinel 选举

如下图所示，Sentinel A 和 Sentinel B 都监测到了主服务器下线并经过其他服务器确认主服务器客观下线，那么两个 Sentinel 都会要求其他 Sentinel 设置自己为leader，Sentinel A 会分别向 Sentinel B 和 Sentinel C 发送选举命令，Sentinel B 也会向 Sentinel A 和 Sentinel C 发送选举命令，选举算法采用的Raft一致性算法，简单来说就是先来先得，即如果 Sentinel C 先收到 Sentinel A 的命令，Sentinel C 就会选举 Sentinel A 为本纪元的 leader，回复 Sentinel A 的消息为

1 //down_state，对主服务器的监测结果，1代表主服务器已下线，0表示主服务器未下线；
Sentinel_A_runid //leader_runid，表示选举的leader的runid
leader_epoch_leader_epoch //表示选举的leader指定的纪元

当 Sentinel C 收到 Sentinel B 的选举命令时，会拒绝将 Sentinel B 设置为领头羊。
Sentinel A 和 Sentinel B 收到回复之后，会根据回复来判定自己是否被成功选举为 leader，判定依据是半数以上的 Sentinel 实例同意。如果在一段时内没有选举成功，则会过一段时间后进行重新选举。

选举出来的 Leader Sentinel 首先会从所有从服务器中选择一个从服务器作为主服务器，选择过程主要包括，

• 删除从服务器中处于下线状态的；
• 删除从服务器中5秒内没有回复 Leader Sentinel INFO 命令的从服务器；
• 删除所有从服务器与已下线主服务器断开连接超过 down-after-milliseconds * 10 毫秒的从服务器；
• 按照剩余从服务器的优先级，即实例权重来进行选择，选择权重最大的实例；
• 如果权重相等，则按照复制偏移量对从服务器进行排序，复制偏移量表示从服务器与已下线主服务器的数据同步情况，复制偏移量越大表示同步的数据越多，选取复制偏移量大的从服务器；
• 如果上述步骤依然不能选取出从服务器，那么根据从服务器的run_id进行排序，选取 run_id 最小的实例。

选出新的主服务器之后，Sentinel通过命令

SLAVEOF no one

设置选取出来从服务器作为新的主服务器，然后通过向其他从服务器发送命令

SLAVEOF  

ip 和 port 为新主服务器的 ip 地址和端口号，等下线的旧主服务器重新连接之后，Sentinel会通过上述命令将其设置为新的主服务器的从服务器，至此整个故障转移过程完成。

总结

本文主要介绍了 Redis Sentinel 是如何做到高可用的。