Redis哨兵机制简介

127 阅读5分钟

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

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

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

Sentinel 故障处理

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

down-after-milliseconds

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

17044733-c36323b64d2682ef.webp

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

SENTINEL is-master-down-by-addr <ip> <port> <current_epoch> <run_id>

命令来询问另外两个 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 客观下线\color{red}{客观下线}了。

LeaderSentinel选举\color{green}{Leader Sentinel 选举}

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

SENTINEL is-master-down-by-addr <ip> <port> <current_epoch> <run_id>

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

17044733-d8b88593905c5695.webp

如下图所示,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 实例同意。如果在一段时内没有选举成功,则会过一段时间后进行重新选举。

故障转移\color{green}{故障转移}

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

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

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

SLAVEOF no one

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

SLAVEOF <ip> <port>

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

总结

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