redis哨兵

前言

上一篇文章梳理了redis的主从复制，今天来继续梳理redis的另一个功能哨兵，如果说redis的主从复制是基于高并发的设计理念，那么sentinel（哨兵）则是基于高可用的，我们知道redis主从架构模式是为了实现读写分离，从而能够支持更高的并发，那么哨兵则为了保证redis的可用性的一个监控服务器，哨兵不支持redis服务器的类似数据库的功能，而是充当主从服务器的护卫的角色，在发现主从服务器不可用时及时进行故障转移，以此实现redis的高可用。

redis哨兵简介

redis哨兵本质上也是一个redis服务器，只是一种特殊的模式运行，这种模式不提供数据库功能，只是监控redis主从服务器，并在主服务器下线时进行故障转移。

当一个哨兵初始化完成后，就会与被他监视的服务器创建两个连接，一个是命令连接，一个是订阅连接，这两个连接都是为了实现sentinel与被监视的主从服务器的通信，通过命令连接，sentinel可以像被监视的主从服务器发送消息，并接收消息，比如一个哨兵像主服务器发送INFO命令，得到如下回复：

Server
...
run_id:7611c59dc3a29aa6fa0609f841bb6a1019008a9c
...
# Replication
role:master
...
slave0:ip=127.0.0.1,port=11111,state=online,offset=43,lag=0
slave1:ip=127.0.0.1,port=22222,state=online,offset=43,lag=0
slave2:ip=127.0.0.1,port=33333,state=online,offset=43,lag=0
...
# Other sections

通过分析回复信息可以知道，当前服务器是主服务器，他有三个从服务器，ip和端口信息以及状态和复制偏移量都可以得到，哨兵会将这些数据保存在自己的服务器上。

主观下线

当一个哨兵与主从服务器建立连接时，就会以每秒一次的的频率向他监视的所有服务器发送ping命令，如果在主观下线时长内，哨兵都没有得到有效的ping回复，sentinel就会将该服务器标记为主观下线。

## 主管下线时长配置
sentinel down-after-milliseconds master 50000

如上配置说明当前主服务器以及他的所有从服务器的主观下线时间是50000毫秒，需要说明的是监视同一个服务器的sentinel可以配置不同的主观下线时间，所以他们对被监视的服务器的主观下线意见可能并不统一。

客观下线

当一个sentinel认为一个服务器主观下线时会向监视这个服务器的其他sentinel发信息确认该服务器的状态，如果有半数以上的sentinel都认为该服务器主观下线，那么当前服务器就会被认定为客观下线。

选举领头sentinel

当确认一个主服务器为客观下线时，就需要进行故障转移，那么有谁来进行故障转移呢？这时就需要从所有sentinel中选举出一个领头sentinel来进行故障转移，领头sentinel的选举有点类似先到先得的机制，假设有三个sentinel同时监视一个主服务器，他们同时确认了主服务器客观下线，这时他们就会再向其他的sentinel发送一条消息，接收到消息的sentinel会把第一次发来消息的源sentinel设置为局部领头sentinel，得到局部领头sentinel票数高的sentinel就会被任命为领头sentinel，故障转移的工作也有该领头sentinel来完成。

故障转移

故障转移要做三件事：

1. 从下线的主服务器里挑选出状态最优的从服务器提拔为主服务器
2. 修改剩余从服务器的复制目标服务器为新的主服务器
3. 将下线的主服务器修改为新主服务器的从服务器

如何挑选出最优从服务器：

• 排除所有处于下线或者断线的从服务器
• 排除所有最近五秒内没有回复领头sentinel信息的从服务器
• 排除所有与一下线主服务器超时连接的从服务器
• 按照从服务器的优先级选出优先级最高的从服务器
• 存在优先级最高相同的从服务，按复制偏移量挑选出最大的

将下线主服务器设置为新主服务器的从服务器的目的是，一旦下线主服务器重新上线后，可以重新担任从服务器的角色。

总结

本文主要梳理了哨兵的相关概念以及哨兵所要做的相关工作，本文关键字如下：

• sentinel
• 主观下线
• 客观下线
• 领头sentinel
• 故障转移

扫码关注个人公众号 精彩不错过