16.Sentinel

Sentinel是Redis的高可用性解决方案:由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器,以及这些主服务器下的所有从服务器,并在被监视的主服务器进入下线状态时,自动将下线组服务器属下的某个从服务器升级为新的主服务器,然后由新的主服务器代替已下线的主服务器继续处理命令请求。

启动并初始化Sentinel

启动一个Sentinel可以使用命令:
redis-sentinel /path/to/your/sentinel.conf
redis-server /path/to/your/sentinel.conf —sentinel
这两个命令效果完全相同。
当一个Sentinel启动时,它需要执行以下步骤:
1.初始化服务器
2.将普通redis服务器使用的代码替换成Sentinel专用代码。
3.初始化Sentinel状态。
4.根据给定的配置条件,初始化Sentinel监视服务器列表。
5.创建连向主服务器的网络连接。

初始化服务器

Sentinel本质上只是一个运行在特殊模式的Redis服务器,所以启动Sentinel的第一步,就是初始化一个普通的Redis服务器。
这里写图片描述
启动Sentinel的第二个步骤是将一部分普通Redis服务器使用的代码替换成Sentinel专用代码。
Sentinel服务器不使用数据库,所以Sentinel要使用sentinel.c/sentinelcmds作为服务器命令表。PING、SENTINEL、INFO、SUBSCRIBE、UNSUBSCRIBE、PSUBSCRIBE和PUNSUBSCRIBE这7个命令就是客户端可以对Sentinel执行的全部命令了。

初始化Sentinel状态

应用了Sentinel的专用代码之后,接下来,服务器会初始化一个sentinel.c/sentinelState结构(sentinel状态),这个结构保存了服务器中所有和sentinel功能有关的状态:
这里写图片描述

初始化Sentinel状态的masters属性

Sentinel状态中的masters字典记录了所有被Sentinel监视的主服务器的相关信息,其中:
字典的键是被监视主服务器的名字
字典的值则是被监视主服务器对于的sentinel.c/sentinelRedisInstance结构(实例结构)。
每一个实例结构代表一个被Sentinel监视的Redis服务器实例,这个实例可以是主服务器、从服务器、或者另外一个Sentinel。
实例结构为主服务器时的部分属性:
这里写图片描述
这里写图片描述
sentinelRedisInstance.addr属性是一个指向sentinel.c/sentinelAddr结构的指针,这个结构保存着实例等IP地址和端口号:
typedef struct sentinelAddr{
char *ip;
int port;
}sentinelAddr;
对Sentinel状态对初始化将引发对masters字典的初始化,而masters字典的初始化是根据被载入的Sentinel配置文件来进行的。

创建连向主服务器的网络连接

初始化Sentinel的最后一步是创建向被监视主服务器的网络连接,Sentinel将成为主服务器的客户端,它可以向主服务器发送命令,并从命令回复中获取相关的信息。
对于每个被Sentinel监视的主服务器来说,Sentinel会创建两个连向主服务器的异步网络连接:
1.命令连接:这个连接专门用于向主服务器发送命令,接收命令回复。
2.订阅连接:专门用于订阅主服务器的_sentinel_:hello频道
为什么是两个连接?
1.在目前的Redis发布与订阅功能中,被发送的信息都不会保存在Redis服务器里面,如果在信息发送时,想要接收信息的客户端不在线或者断线,那么这个客户端就会丢失这条信息。专门用一个订阅连接来接收该频道的信息为了不丢失_sentinel_:hello频道的任何信息。
2.除了订阅频道外,sentinel还必须向主服务器发送命令,以此来与主服务器进行通信
因为Sentinel需要与多个实例创建多个网络连接,所以Sentinel使用的是异步连接。

获取主服务器信息

Sentinel默认每10s一次的频率,通过命令连接向被监视的主服务器发送INFO命令,并通过分析INFO命令的回复来获取主服务器的当前信息。
通过分析主服务器返回的INFO命令回复,Sentinel可以获得以下两方面的信息:
1.关于主服务器本身的信息,包括run_id域记录的服务器运行ID,以及role域记录的服务器角色
2.关于主服务器属下所有从服务器的信息,每个从服务器都由一个“slave”字符串开头的行记录,每行的ip=域记录了从服务器的IP地址,port = 域则记录了从服务器的端口号。
根据run_id域和role域记录的信息,Sentinel将对主服务器的实例结构进行更新。主服务器返回的从服务器的信息,会被用于更新主服务器实例结构的slaves字典,这个字典记录了主服务器属下从服务器的名单。
Sentinel在分析INFO命令中包含的从服务器信息时,会检查从服务器对应的实例结构是否已经存在于slaves字典:
如果从服务器对应的实例结构已经存在,那么Sentinel对从服务器的实例结构进行更新。
如果从服务器对应的实力机构不存在,那么说明这个从服务器是新发现的从服务器,Sentinel会在slaves字典中为这个从服务器新创建一个实例结构。
如果从服务器对应的实例结构不存在,那么说明这个从服务器是新发现的从服务器,Sentinel会在slaves字典中为这个从服务器新创建一个实例结构。

获取从服务器信息

当Sentinel发现主服务器有新的从服务器出现时,Sentinel除了会为这个新的从服务器创建相应的实例结构之外,Sentinel还会创建连接到服务器的命令连接和订阅连接。

向主服务器和从服务器发送信息

在默认情况下,Sentinel会以每两秒一次的频率,通过命令连接箱所有被监视的主服务器和从服务器发送一下格式的命令:
PUBLISH __sentinel__:hello “< s_ip>,< s_port>,< s_epoch>,< m_name>, < m_ip>, < m_port>, < m_epoch>”
其中以s_开头的参数记录是Sentinel本身的信息:
s_ip:Sentinel的IP地址
s_port:Sentinel的端口号
s_runid:Sentinel的运行id
s_epoch:Sentinel当前的配置纪元
而m_开头的参数记录则是主服务器的信息,如果Sentinel正在监视的是主服务器,那么这显示记录的就是主服务器的信息;如果Sentinel正在监视 的是从服务器,那么这些参数记录的就是从服务器正在复制主服务器的信息。
m_name:主服务器的名字
m_ip:主服务器的IP地址
m_port:主服务器的端口号
m_epoch:主服务器当前的配置纪元

接收来自主服务器和从服务器的频道信息

当Sentinel与一个主服务器或者从服务器建立起订阅连接之后,sentinel就会通过订阅连接,向服务器发送以下命令:
SUBSCRIBE _ sentinel_ :hello
也就是说对于每个与Sentinel连接的服务器,Sentinel即通过命令连接向服务器的_ _sentinel__:hello频道发送信息,又通过订阅连接从服务器的_ _sentinel__:hello频道接受信息。
当一个Sentinel从_ _sentinel__:hello频道收到一条信息 时,Sentinel会对这条信息进行分析,提取出信息中的Sentinel IP地址,Sentinel端口号,Sentinel运行ID等八个参数,并进行以下检查:
如果接受到的信息中记录的Sentinel运行ID和接受信息的sentinel的运行ID相同,那么说明这条信息是sentinel自己发送的,不做处理。
如果信息中揭露的sentinel运行ID和接受信息的sentinel运行ID不同,那么接受信息的sentinel会根据信息中的各个参数,对相应主服务器的实例结构进行更新。

更新sentinels字典

当一个Sentinel接收到其他Sentinel发来的信息时,目标Sentinel会从信息中分析并提取出以下两方面参数:
与Sentinel有关的参数:源Sentinel的IP地址、端口号、运行ID和配置纪元。
与主服务器有关的参数:源Sentinel正在监视的主服务器的名字、IP地址、端口号和配置纪元。

扫描二维码关注公众号,回复: 2738642 查看本文章

创建连向其他Sentinel的命令连接

当Sentinel通过频道信息发现一个新的Sentinel时,它不仅会为新Sentinel在Sentinels字典中创建想要的实例结构,还会创建一个连向新Sentinel的命令连接,而新Sentinel也同样会创建连向这个Sentinel的命令连接,最终监视同一主服务器的多个Sentinel将形成相互连接的网络。
Sentinel之间不会创建订阅连接,是因为Sentinel需要通过接收主服务器或者从服务器发来的频道信息来发现未知的新Sentinel,而相互已知的Sentinel只要使用命令连接来进行通信就足够了。

检测主管下线状态

在默认情况下,Sentinel会以每秒一次的频率向所有与它创建了命令连接的实例发送PING命令,并通过实例返回的PING命令回复来判断实例是否在线。
实例对PING命令的回复可以分为以下两种情况:
1.有效回复:实例返回+PONG、-LOADING、-MASTERDOWN三种回复的其中一种。
2.无效回复:实例返回除了有效返回的那三种回复之外的其他回复。

检测客观下线状态

当Sentinel将一个主服务器判断为主观下线之后,为了确认这个主服务器是否真的下线了,它会向同样监视这一主服务器的其他Sentinel进行询问,看它们是否也认为主服务器已经进入了下线状态。当Sentinel从其他Sentinel哪里接受到足够数量的已下线判断之后,Sentinel就会将从服务器判定为客观下线,并对主服务器执行故障转移操作。

发送SENTINEL is-master-down-by-addr命令

SENTINEL is-master-down-by-addr < ip>< port> < current_epoch> < runid>
命令询问其他Sentinel是否同意主服务器已下线。

接收SENTINEL is-master-down-by-addr命令

当一个Sentinel(目标Sentinel)接收到另一个Sentinel(源Sentinel)发来的SENTINEL is-master-down-by命令时,目标Sentinel会分析并去除命令请求中包含的各个参数,并根据其中的主服务器IP和端口号,检查主服务器是否已下线,然后向源Sentinel返回一条包含三个参数的Multi Bulk回复作为SENTINEL is-master-down-by命令的回复:
(1)< down_state>
(2)< leader_runid>
(3)< leader_epoch>

接收SENTINEL is-master-down-by-addr命令的回复

当这一数量达到配置指定的判断客观下线所需的数量时,Sentinel会将主服务器实例结构flags熟悉的SRI_O_DOWN标识打开,标示主服务器已经进入客观下线状态。
客观下线状态的判断条件
当任务主服务器已经进入下线状态的Sentinel的数量,超过Sentinel配置中设置的quorum参数的值,那么该Sentinel就会任务主服务器已经进入客观下线状态。

选举领头Sentinel

当一个主服务器被判断为客观下线时,监视这个下线主服务器的各个Sentinel会进行协商,选举出一个领头Sentinel,并由领头Sentinel对下线主服务器进行故障转移操作。
选举领头Sentinel的规则和方法:
1.所有在线的Sentinel都有被选为领头Sentinel的资格。
2.每次进行领头Sentinel选举之后,不论选举是否成功,所有Sentinel的配置纪元的值都会自增一次。
3.在一个配置纪元里面,所有Sentinel都有一次将某个Sentinel设置为局部领头Sentinel的机会,并且局部领头一旦设置,在这个配置纪元里就不能再更改。
4.每个发现主服务器进入客观下线的Sentinel都会要求其他Sentinel将自己设置为局部领头Sentinel。
5.当一个Sentinel(源Sentinel)向另一个Sentinel(目标Sentinel)发送SENTINEL is-master-down-by-addr命令,并且命令中的runid参数不是*符号而是源Sentinel将被成为目标Sentinel的局部领头Sentinel,而之后接收到的所有设置要求都会被目标Sentinel拒绝。
6.Sentinel设置局部领头Sentinel的规则是先到先得:最先向目标Sentinel发送设置要求的源Sentinel将成为目标Sentinel的局部领头Sentinel的运行ID和配置纪元。
7.源Sentinel在接收到目标Sentinel返回的命令回复之后,会检查回复中leader_epoch参数的值和自己的配置纪元是否相同,如果相同的话,那么源Sentinel继续取出回复中的leader_runid参数,如果leader_runid参数的值和源Sentinel的运行ID一致,那么表示目标Sentinel将源Sentinel设置成了局部领头Sentinel。
8.如果有某个Sentinel被半数以上的Sentinel设置成了局部领头Sentinel,那么这个Sentinel称谓领头Sentinel。
9.因为领头Sentinel的产生需要半数以上的Sentinel的支持,并且每个Sentinel在每个配置纪元里面只能设置一次局部领头Sentinel,所以在一个配置纪元里面,只会出现一个领头Sentinel。
10.如果在给定时限内,没有一个Sentinel被选举为领头Sentinel,那么各个Sentinel将在一段时间只会再次进行选举,直到选出领头Sentinel为止。

故障转移

在选举产生出领头Sentinel之后,领头Sentinel将对已下线的主服务器执行故障转移操作,该操作包含以下三个步骤:
1)在已下线主服务器属下的所有从服务器里面,挑选出一个从服务器,并将其转换为主服务器。
2)让已下线主服务器属下的所有从服务器改为复制新的主服务器。
3)将以下线主服务器设置为新的主服务器的从服务器,当这个旧的主服务器重新上线时,它将会成为新的主服务器的从服务器。

选出新的主服务器

新的主服务器是怎样挑选出来的
领头Sentinel会将已下线主服务器的所有从服务器保存到一个列表里,然后按照以下规则,一项一项地对列表进行过滤:
1)删除列表中所有处于下线或者断线状态的从服务器,这可以保证列表中剩余的从服务器都是正常在线的。
2)删除列表中所有最近5s内没有回复过领头Sentinel的INFO命令的从服务器,这可以保证列表中剩余的从服务器都是最近成功进行过通信的。
3)删除所有与已下线主服务器连接断开超过down-after-milliseconds*10毫秒的从服务器。
之后,领头Sentinel将根据从服务器的优先级,对列表中剩余的从服务器进行排序,并选出其中优先级最高的从服务器。

修改从服务器的复制目标

当新的主服务器出现之后,领头Sentinel下一步要做的就是,让已下线主服务器属下的所有从服务器去复制新的主服务器,这一动作可以通过向从服务器发送SLAVEOF命令来时限。

将旧的主服务器变为从服务器

故障转移操作最后要做的是,将已下线的主服务器设置为新的主服务器的从服务器。

猜你喜欢

转载自blog.csdn.net/xiaomimi1993/article/details/81353233