Redis夯实基础系列-Sentinel深入浅出

最新推荐文章于 2023-10-07 22:47:37 发布

想转码的土木狗

最新推荐文章于 2023-10-07 22:47:37 发布

阅读量118

点赞数

文章标签： redis

本文链接：https://blog.csdn.net/Lms07121/article/details/132562587

版权

Sentinel

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

下图展示了一个Sentinel系统监视服务器的例子，其中：

用双环图案表示的是当前的主服务器serverl。
用单环图案表示的是主服务器的三个从服务器server2、server3以及server4。
server2、server3、server4三个从服务器正在复制主服务器serverl,而Sentinel系统则在监视所有四个服务器。

在这里插入图片描述

假设这时，主服务器serverl进入下线状态，那么从服务器server2、server3、server4对主服务器的复制操作将被中止，并且Sentinel系统会察觉到serverl已下线，如下图所示(下线的服务器用虚线表示)。

在这里插入图片描述

当serverl的下线时长超过用户设定的下线时长上限时，Sentinel系统就会对serverl执行故障转移操作：

首先，Sentinel系统会挑选serverl属下的其中一个从服务器，并将这个被选中的从服务器升级为新的主服务器。
之后，Sentinel系统会向serverl属下的所有从服务器发送新的复制指令，让它们成为新的主服务器的从服务器，当所有从服务器都开始复制新的主服务器时，故障转移操作执行完毕。
另外，Sentinel还会继续监视已下线的serverl,并在它重新上线时，将它设置为新的主服务器的从服务器。

下图展示了Sentinel系统将server2升级为新的主服务器，并让服务器server3和server4成为server2的从服务器的过程。

在这里插入图片描述

之后，如果serverl重新上线的话，它将被Sentinel系统降级为server2的从服务器，如下图所示。

在这里插入图片描述

1.1 启动并初始化Sentinel

启动一个Sentinel可以使用命令：

$ redis-sentinel /path/to/your/sentinel.conf

或者命令：

$ redis-server /path/to/your/sentinel.conf --sentinel

这两个命令的效果完全相同。

当一个Sentinel启动时，它需要执行以下步骤：

初始化服务器。
将普通Redis服务器使用的代码替换成Sentinel专用代码。
初始化Sentinel状态。
根据给定的配置文件，初始化Sentinel的监视主服务器列表。
创建连向主服务器的网络连接。

1.1.1 初始化服务器

首先，因为Sentinel本质上只是一个运行在特殊模式下的Redis服务器，所以启动Sentinel的第一步，就是初始化一个普通的Redis服务器。

不过，因为Sentinel执行的工作和普通Redis服务器执行的工作不同，所以Sentinel的初始化过程和普通Redis服务器的初始化过程并不完全相同。

例如，普通服务器在初始化时会通过载入RDB文件或者AOF文件来还原数据库状态，但是因为Sentinel并不使用数据库，所以初始化Sentinel时就不会载入RDB文件或者AOF文件。

下表展示了Redis服务器在Sentinel模式下运行时，服务器各个主要功能的使用情况。

功能	使用情况
数据库和键值对方面的命令，比如SET、DEL、FLUSHDB	不使用
事务命令，比如MULTI和WATCH	不使用
脚本命令，比如EVAL	不使用
RDB持久化命令，比如SAVE和BGSAVE	不使用
AOF持久化命令，比如BGREWRITEAOF	不使用
复制命令，比如SLAVEOF	Sentinel内部可以使用，但客户端不可以使用
发布与订阅命令，比如PUBLISH和 SUBSCRIBE	SUBSCRIBE、PSUBSCRIBE、UNSUBSCRIBE、PUNSUBSCRIBE四个命令在Sentinel内部和客户端都可以使用，但PUBL/SH命令只能在Sentinel内部使用
文件事件处理器(负责发送命令请求、处理命令回复)	Sentinel内部使用，但关联的文件事件处理器和普通Redis服务器不同
时间事件处理器(负责执行serverCron函数)	Sentinel内部使用，时间事件的处理器仍然是serverCron函数，serverCron函数会调用sentinel.c/sentinelTimer函数，后者包含了Sentinel要执行的所有操作

1.1.2 使用Sentinel专用代码

启动Sentinel的第二个步骤就是将一部分普通Redis服务器使用的代码替换成Sentinel专用代码。比如说，普通Redis服务器使用redis.h/REDIS_SERVERPORT常量的值作为服务器端口：

#define REDIS SERVERPORT 6379

而Sentinel则使用sentinel.c/REDIS_SENTINEL_PORT常量的值作为服务器端口：

#define REDIS_SENTINEL_PORT 26379

除此之外，普通Redis服务器使用redis.c/redisCommandTable作为服务器的命令表：

struct redisCommand redisCommandTable[] = {
    {"get",getCommand,2,"r",0,NULL,1,1,1,0,0},
    {"set",setCommand,-3,"wm",0,noPreloadGetKeys,1,1,1,0,0},
    {"setnx",setnxCommand,3,"wm",0,noPreloadGetKeys,1,1,1,0,0},
    //...
    {"script",scriptCommand,-2,"ras",0,NULL,0,0,0,0,0},
    {"time",timeCommand,1,"rR",0,NULL,0,0,0,0,0),
    {"bitop",bitopCommand,-4,"wm",0,NULL,2,- 1,1,0,0},
    {"bitcount",bitcountCommand,-2,"r",O,NULL,1,1,1,0,0}
}

而Sentinel则使用sentinel.c/sentinelcmds作为服务器的命令表，并且其中的INFO命令会使用Sentinel模式下的专用实现sentinel.c/sentinelInfoCommand函数，而不是普通Redis服务器使用的实现redis.c/infoCommand函数：

struct redisCommand sentinelcmds[] = {
    {"ping",pingCommand,1,"",0,NULL,0,0,0,0,0},
    {"sentinel",sentinelCommand,-2,"",0,NULL,0,0,0,0,0),
	{"subscribe",subscribeCommand,-2,"",0,NULL,0,0,0,0,0),
	{"unsubscribe",unsubscribeCommand,- 1,"",0,NULL,0,0,0,0,0},
	{"psubscribe",psubscribeCommand,-2,"",0,NULL,0,0,0,0,0},
	{"punsubscribe",punsubscribeCommand,- 1,"",0,NULL,0,0,0,0,0},
	{"info",sentinelInfoCommand,- 1,"",0,NULL,0,0,0,0,0}
};

sentinelcmds命令表也解释了为什么在Sentinel模式下，Redis服务器不能执行诸如SET、DBSIZE、EVAL等等这些命令，因为服务器根本没有在命令表中载入这些命令。PING、SENTINEL、INFO、SUBSCRIBE、UNSUBSCRIBE、PSUBSCRIBE 和PUNSUBSCRIBE这七个命令就是客户端可以对Sentinel执行的全部命令了。

15.1.3 初始化Sentinel状态

在应用了Sentinel的专用代码之后，接下来，服务器会初始化一个sentinel.c/sentinelState结构(后面简称“Sentinel状态”),这个结构保存了服务器中所有和Sentinel功能有关的状态(服务器的一般状态仍然由redis.h/redisServer结构保存):

struct sentinelState {
	//当前纪元，用于实现故障转移
	uint64_t current_epoch;
	
	//保存了所有被这个sentinel监视的主服务器
	//字典的键是主服务器的名字
	//字典的值则是一个指向sentinelRedisInstance结构的指针
	dict *masters;
	
	//是否进入了TILT模式?
	int tilt;
	
	//目前正在执行的脚本的数量
	int running_scripts;
	
	//进入TILT模式的时间
	mstime_t tilt_start_time;

	//最后一次执行时间处理器的时间
	mstime_t_previous_time;
	
	//一个FIFO队列，包含了所有需要执行的用户脚本
	list *scripts_queue;
} sentinel;

15.1.4 初始化Sentinel状态的masters属性

Sentinel状态中的masters字典记录了所有被Sentinel监视的主服务器的相关信息，其中：

字典的键是被监视主服务器的名字。
而字典的值则是被监视主服务器对应的sentinel.c/sentinelRedisInstance结构。每个sentinelRedisInstance结构(后面简称“实例结构”)代表一个被Sentinel监视的Redis服务器实例(instance), 这个实例可以是主服务器、从服务器，或者另外一个Sentinel。

实例结构包含的属性非常多，以下代码展示了实例结构在表示主服务器时使用的其中一部分属性：

在这里插入图片描述

sentinelRedisInstance.addr属性是一个指向sentinel.c/sentinelAddr结构的指针，这个结构保存着实例的IP地址和端口号：

typedef struct sentinelAddr {
    char *ip;
    int port;
} sentinelAddr;

对Sentinel状态的初始化将引发对masters字典的初始化，而masters字典的初始化是根据被载入的Sentinel配置文件来进行的。

如果用户在启动Sentinel时，指定了包含以下内容的配置文件：

在这里插入图片描述

那么Sentinel将为主服务器master1创建如下图1所示的实例结构，并为主服务器master2创建如下图2所示的实例结构，而这两个实例结构又会被保存到Sentinel状态的masters字典中，如下图3所示。

在这里插入图片描述

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

初始化Sentinel的最后一步是创建连向被监视主服务器的网络连接，Sentinel将成为主服务器的客户端，它可以向主服务器发送命令，并从命令回复中获取相关的信息。

对于每个被Sentinel监视的主服务器来说，Sentinel会创建两个连向主服务器的异步网络连接：

一个是命令连接，这个连接专门用于向主服务器发送命令，并接收命令回复。
另一个是订阅连接，这个连接专门用于订阅主服务器的__sentinel__:hello频道。

下图展示了一个Sentinel向被它监视的两个主服务器master1和master2创建命令连接和订阅连接的例子。

在这里插入图片描述

1.2 获取主服务器信息

Sentinel默认会以每十秒一次的频率，通过命令连接向被监视的主服务器发送INFO命令，并通过分析INFO命令的回复来获取主服务器的当前信息。

假设如下图所示，主服务器master有三个从服务器slaveO、slave1和slave2,并且一个Sentinel正在连接主服务器，那么Sentinel将持续地向主服务器发送INFO命令，并获得类似于以下内容的回复：

在这里插入图片描述

# Server
run_id:7611c59dc3a29aa6fa0609f841bb6a1019008a9c
# Replication
role:master
...
slave0:ip= 127.0.0.1,port=11111,state=online,offset=43,lag=0
slavel: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
...

通过分析主服务器返回的INFO命令回复，Sentinel可以获取以下两方面的信息：

一方面是关于主服务器本身的信息，包括run_id域记录的服务器运行ID,以及role域记录的服务器角色；
另一方面是关于主服务器属下所有从服务器的信息，每个从服务器都由一个"slave"字符串开头的行记录，每行的ip=域记录了从服务器的IP地址，而port=域则记录了从服务器的端口号。根据这些IP地址和端口号，Sentinel无须用户提供从服务器的地址信息，就可以自动发现从服务器。

根据run_id域和role域记录的信息，Sentinel将对主服务器的实例结构进行更新，例如，主服务器重启之后，它的运行ID就会和实例结构之前保存的运行ID不同，Sentinel检测到这一情况之后，就会对实例结构的运行ID进行更新。

至于主服务器返回的从服务器信息，则会被用于更新主服务器实例结构的slaves字典，这个字典记录了主服务器属下从服务器的名单：

字典的键是由Sentinel自动设置的从服务器名字，格式为ip:port:如对于IP地址为[127.0 .0.1],端口号为11111的从服务器来说，Sentinel为它设置的名字就是127.0.0.1:11111。
至于字典的值则是从服务器对应的实例结构：比如说，如果键是[127.0.0.1]:11111, 那么这个键的值就是IP地址为[127.0.0.1],端口号为11111的从服务器的实例结构。

Sentinel在分析INFO命令中包含的从服务器信息时，会检查从服务器对应的实例结构是否已经存在于slaves字典：

如果从服务器对应的实例结构已经存在，那么Sentinel对从服务器的实例结构进行更新。
如果从服务器对应的实例结构不存在，那么说明这个从服务器是新发现的从服务器，Sentinel会在slaves字典中为这个从服务器新创建一个实例结构。

对于之前列举的主服务器master和三个从服务器slaveO、slave1 和slave2的例子来说，Sentinel将分别为三个从服务器创建它们各自的实例结构，并将这些结构保存到主服务器实例结构的slaves字典里面，如下图所示。

在这里插入图片描述

对比上图中主服务器实例结构和从服务器实例结构之间的区别：

主服务器实例结构的flags属性的值为SRI_MASTER, 而从服务器实例结构的flags属性的值为SRI_SLAVE。
主服务器实例结构的name属性的值是用户使用Sentinel配置文件设置的，而从服务器实例结构的name属性的值则是Sentinel根据从服务器的IP地址和端口号自动设置的。

1.3 获取从服务器信息

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

对于上图所示的主从服务器关系来说，Sentinel将对slaveO、slave1和slave2三个从服务器分别创建命令连接和订阅连接，如下图所示。

在这里插入图片描述

在创建命令连接之后，Sentinel在默认情况下，会以每十秒一次的频率通过命令连接向从服务器发送INFO命令，并获得类似于以下内容的回复：

# Server
run_id:32be0699dd27b410f7c90dada3a6fab17f97899f
# Replication
role:slave
master host:127.0.0.1
master_port:6379
master_link_status:up
slave_repl_offset:11887
slave_priority:100
# Other sections

根据INFO命令的回复，Sentinel会提取出以下信息：

从服务器的运行ID run_id。
从服务器的角色 role。
主服务器的IP地址master_host, 以及主服务器的端口号master_port。
主从服务器的连接状态 master_link_status。
从服务器的优先级 slave_priority。
从服务器的复制偏移量 slave_repl_offset。

根据这些信息，Sentinel会对从服务器的实例结构进行更新，下图展示了Sentinel根据上面的INFO命令回复对从服务器的实例结构进行更新之后，实例结构的样子。

在这里插入图片描述

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

在默认情况下，Sentinel会以每两秒一次的频率，通过命令连接向所有被监视的主服务器和从服务器发送以下格式的命令：

PUBLISH __sentinel__:hello "<s_ip>,<s_port>,<s_runid>,<s_epoch>,<m_name>,<m_ip>,<m_port>,<m_epoch>"

这条命令向服务器的__sentinel__:hello频道发送了一条信息，信息的内容由多个参数组成：

其中以s开头的参数记录的是Sentinel本身的信息，各个参数的意义如下表1所示。
而m开头的参数记录的则是主服务器的信息，各个参数的意义如下表2所示。如果Sentinel正在监视的是主服务器，那么这些参数记录的就是主服务器的信息；如果Sentinel正在监视的是从服务器，那么这些参数记录的就是从服务器正在复制的主服务器的信息。

参数	意义
s_ip	Sentinel的IP地址
s_port	Sentinel的端口号
s_runid	Sentinel的运行ID
s_epoch	Sentinel当前的配置纪元(configuration epoch)

参数	意义
m_name	主服务器的名字
m_ip	主服务器的IP地址
m_port	主服务器的端口号
m_epoch	主服务器当前的配置纪元

以下是一条Sentinel通过PUBLISH命令向主服务器发送的信息示例：

"127.0.0.1,26379,e955b4c85598ef5b5f055bc7ebfd5e828dbed4fa,0,mymaster,127.0.0.1,6379,0"

这个示例包含了以下信息：

Sentinel的IP地址为127.0.0.1端口号为26379,运行ID为e955b4c85598ef5b5f055bc7ebfd5e828dbed4fa,当前的配置纪元为0。
主服务器的名字为mymaster,IP地址为127.0.0.1,端口号为6379,当前的配置纪元为0。

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

当Sentinel与一个主服务器或者从服务器建立起订阅连接之后，Sentinel就会通过订阅连接，向服务器发送以下命令：

SUBSCRIBE __sentinel__:hello

Sentinel对__sentinel__:hello频道的订阅会一直持续到Sentinel与服务器的连接断开为止。

这也就是说，对于每个与Sentinel连接的服务器，Sentinel既通过命令连接向服务器的__sentinel__:hello频道发送信息，又通过订阅连接从服务器的__sentinel__:hello频道接收信息，如下图所示

在这里插入图片描述

对于监视同一个服务器的多个Sentinel来说，一个Sentinel发送的信息会被其他Sentinel接收到，这些信息会被用于更新其他Sentinel对发送信息Sentinel的认知，也会被用于更新其他Sentinel对被监视服务器的认知。

假设现在有sentinel1、sentinel2、sentinel3三个Sentinel在监视同一个服务器，那么当sentinel1向服务器的 sentinel:hello频道发送一条信息时，所有订阅了__sentinel__:hello频道的Sentinel(包括sentinell自己在内)都会收到这条信息，如下图所示。

在这里插入图片描述

当一个Sentinel从__sentinel__:hello频道收到一条信息时，Sentinel会对这条信息进行分析，提取出信息中的Sentinel IP地址、Sentinel端口号、Sentinel运行ID等八个参数，并进行以下检查：

如果信息中记录的Sentinel运行ID和接收信息的Sentinel的运行ID相同，那么说明这条信息是Sentinel自己发送的，Sentinel将丢弃这条信息，不做进一步处理。
相反地，如果信息中记录的Sentinel运行ID和接收信息的Sentinel的运行ID不相同，那么说明这条信息是监视同一个服务器的其他Sentinel发来的，接收信息的Sentinel将根据信息中的各个参数，对相应主服务器的实例结构进行更新。

1.5.1 更新sentinels字典

Sentinel为主服务器创建的实例结构中的sentinels字典保存了除Sentinel本身之外，所有同样监视这个主服务器的其他Sentinel的资料：

sentinels字典的键是其中一个Sentinel的名字，格式为ip:port,比如对于IP地址为127.0.0.1,端口号为26379的Sentinel来说，这个Sentinel在sentinels字典中的键就是"127.0.0.1:26379"。
sentinels字典的值则是键所对应Sentinel的实例结构，比如对于键"127.0.0. 1:26379"来说，这个键在sentinels字典中的值就是IP为127.0.0.1,端口号为26379的Sentinel的实例结构。

当一个Sentinel接收到其他Sentinel发来的信息时(我们称呼发送信息的Sentinel为源Sentinel,接收信息的Sentinel为目标Sentinel),目标Sentinel会从信息中分析并提取出以下两方面参数：

与Sentinel有关的参数：源Sentinel的IP地址、端口号、运行ID和配置纪元。
与主服务器有关的参数：源Sentinel正在监视的主服务器的名字、IP地址、端口号和配置纪元。

根据信息中提取出的主服务器参数，目标Sentinel会在自己的Sentinel状态的masters字典中查找相应的主服务器实例结构，然后根据提取出的Sentinel参数，检查主服务器实例结构的sentinels字典中，源Sentinel的实例结构是否存在：

如果源Sentinel的实例结构已经存在，那么对源Sentinel的实例结构进行更新。
如果源Sentinel的实例结构不存在，那么说明源Sentinel是刚刚开始监视主服务器的新Sentinel,目标Sentinel会为源Sentinel创建一个新的实例结构，并将这个结构添加到sentinels字典里面。

举个例子，假设分别有[127.0.0.1]:26379、[127.0.0.1]:26380、[127.0.0.1]:26381三个Sentinel正在监视主服务器[127.0.0.1]:6379,那么当[127.0.0.1]:26379这个Sentinel接收到以下信息时：

1)"message"
2)"__sentinel__:hello"
3)"127.0.0.1,26379,e955b4c85598ef5b5f055bc7ebfd5e828dbed4fa,0,mymaster,127.0.0.1,6379,0"

1)"message"
2)"__sentinel__:hello"
3)"127.0.0.1,26381,6241bf5cf9bfc8ecd15d6eb6cc3185edfbb24903,0,mymaster,127.0.0.1,6379,0"

1) "message"
2)"__sentinel__:hello"
3)"127.0.0.1,26380,a9b22fb79ae8fad28e4ea77d20398f77f6b89377,0,mymaster,127.0.0.1,6379,0"

Sentinel将执行以下动作：

第一条信息的发送者为127.0.0.1:26379自己，这条信息会被忽略。
第二条信息的发送者为127.0.0.1:26381,Sentinel会根据这条信息中提取出的内容，对sentinels字典中127.0.0. 1:26381对应的实例结构进行更新。
第三条信息的发送者为[127.0.0.1]:26380,Sentinel会根据这条信息中提取出的内容，对sentinels字典中127.0.0. 1:26380所对应的实例结构进行更新。

下图展示了Sentinel[127.0.0.1]:26379为主服务器127.0.0. 1:6379创建的实例结构，以及结构中的sentinels字典。

在这里插入图片描述

和127.0.0.1:26379一样，其他两个Sentinel也会创建类似于下图所示的sentinels字典，区别在于字典中保存的Sentinel信息不同：

127.0.0.1:26380创建的sentinels字典会保存127.0.0.1:26379和[127.0.0. 1]:26381两个Sentinel的信息。
而127.0.0.1:26381创建的sentinels字典则会保存127.0.0. 1:26379和[127.0.0. 1]:26380两个Sentinel的信息。

因为一个Sentinel可以通过分析接收到的频道信息来获知其他Sentinel的存在，并通过发送频道信息来让其他Sentinel知道自己的存在，所以用户在使用Sentinel的时候并不需要提供各个Sentinel的地址信息，监视同一个主服务器的多个Sentinel可以自动发现对方。

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

当Sentinel通过频道信息发现一个新的Sentinel时，它不仅会为新Sentinel在sentinels字典中创建相应的实例结构，还会创建一个连向新Sentinel的命令连接，而新Sentinel也同样会创建连向这个Sentinel的命令连接，最终监视同一主服务器的多个Sentinel将形成相互连接的网络：Sentinel A有连向Sentinel B的命令连接，而SentinelB也有连向Sentinel A的命令连接。

下图展示了三个监视同一主服务器的Sentinel之间是如何互相连接的。

使用命令连接相连的各个Sentinel可以通过向其下他Sentinel发送命令请求来进行信息交换。

在这里插入图片描述

1.6 检测主观下线状态

在默认情况下，Sentinel会以每秒一次的频率向所有与它创建了命令连接的实例(包括主服务器、从服务器、其他Sentinel在内)发送PING命令，并通过实例返回的PING命令回复来判断实例是否在线。

在下图展示的例子中，带箭头的连线显示了Sentinel1和Sentinel2是如何向实例发送PING命令的：

Sentinel1将向Sentinel2、主服务器master、从服务器slave1和slave2发送PING命令。
Sentinel2将向Sentinel1、主服务器master、从服务器slave1和slave2发送PING命令。

实例对PING命令的回复可以分为以下两种情况：

有效回复：实例返回+PONG、-LOADING、-MASTERDOWN三种回复的其中一种。
无效回复：实例返回除+PONG、-LOADING、-MASTERDOWN三种回复之外的其他回复，或者在指定时限内没有返回任何回复。

在这里插入图片描述

Sentinel配置文件中的down-after-milliseconds选项指定了Sentinel判断实例进入主观下线所需的时间长度：如果一个实例在down-after-milliseconds毫秒内，连续向Sentinel返回无效回复，那么Sentinel会修改这个实例所对应的实例结构，在结构的flags属性中打开SRI_S_DOWN标识，以此来表示这个实例已经进入主观下线状态。

以上图展示的情况为例子，如果配置文件指定Sentinel1的down-after-milliseconds选项的值为50000毫秒，那么当主服务器master连续50000毫秒都向Sentinel1返回无效回复时，Sentinel1就会将master标记为主观下线，并在master所对应的实例结构的flags属性中打开SRI_S_DOWN标识，如下图所示。

在这里插入图片描述

1.7 检查客观下线状态

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

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

Sentinel使用：

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

命令询问其他Sentinel是否同意主服务器已下线，命令中的各个参数的意义如下表所示。

参数	意义
ip	被Sentinel判断为主观下线的主服务器的IP地址
port	被Sentinel判断为主观下线的主服务器的端口号
current_epoch	Sentinel当前的配置纪元，用于选举领头Sentinel
runid	可以是符号或者Sentinel的运行ID: 符号代表命令仅仅用于检测主服务器的客观下线状态，而Sentinel的运行ID则用于选举领头Sentinel

如果被Sentinel判断为主观下线的主服务器的IP为[127.0.0.1],端口号为6379,并且Sentinel当前的配置纪元为0,那么Sentinel将向其他Sentinel发送以下命令：

SENTINEL is-master-down-by-addr 127.0.0.1 6379 0 *

1.7.2 接收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>

下表分别记录了这三个参数的意义。

参数	意义
down_state	返回目标Sentinel对主服务器的检查结果，1代表主服务器已下线，0代表主服务器未下线
leader_runid	可以是符号或者目标Sentinel的局部领头Sentinel的运行ID: 符号代表命令仅仅用于检测主服务器的下线状态，而局部领头Sentinel的运行ID则用于选举领头Sentinel
leader_epoch	目标Sentinel的局部领头Sentinel的配置纪元，用于选举领头Sentinel。仅在leader_runid的值不为* 时有效，如果leader_runid的值为*,那么leader_epoch总为0

如果一个Sentinel返回以下回复作为SENTINEL is-master-down-by-addr命令的回复：

1) 1
2) *
3) 0

那么说明Sentinel也同意主服务器已下线。

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

根据其他Sentinel发回的SENTINEL is-master-down-by-addr命令回复，Sentinel将统计其他Sentinel同意主服务器已下线的数量，当这一数量达到配置指定的判断客观下线所需的数量时，Sentinel会将主服务器实例结构flags属性的SRI_O_DOWN标识打开，表示主服务器已经进入客观下线状态，如下图所示。

在这里插入图片描述

1.8 选举领头Sentinel

当一个主服务器被判断为客观下线时，监视这个下线主服务器的各个Sentinel会进行协商，选举出一个领头Sentinel, 并由领头Sentinel对下线主服务器执行故障转移操作。以下是Redis选举领头Sentinel的规则和方法：

所有在线的Sentinel都有被选为领头Sentinel的资格，换句话说，监视同一个主服务器的多个在线Sentinel中的任意一个都有可能成为领头Sentinel。
每次进行领头Sentinel选举之后，不论选举是否成功，所有Sentinel的配置纪元(configuration epoch)的值都会自增一次。配置纪元实际上就是一个计数器，并没有什么特别的。
在一个配置纪元里面，所有Sentinel都有一次将某个Sentinel设置为局部领头Sentinel的机会，并且局部领头一旦设置，在这个配置纪元里面就不能再更改。
每个发现主服务器进入客观下线的Sentinel都会要求其他Sentinel将自己设置为局部领头Sentinel。
当一个Sentinel(源Sentinel)向另一个Sentinel(目标Sentinel)发送SENTINEL is-master-down-by-addr命令，并且命令中的runid参数不是*符号而是源Sentinel的运行ID时，这表示源Sentinel要求目标Sentinel将前者设置为后者的局部领头Sentinel。
Sentinel设置局部领头Sentinel的规则是先到先得：最先向目标Sentinel发送设置要求的源Sentinel将成为目标Sentinel的局部领头Sentinel, 而之后接收到的所有设置要求都会被目标Sentinel拒绝。
目标Sentinel在接收到SENTINEL is-master-down-by-addr命令之后，将向源Sentinel返回一条命令回复，回复中的leader_runid参数和leader_epoch参数分别记录了目标Sentinel的局部领头Sentinel的运行ID和配置纪元。
源Sentinel在接收到目标Sentinel返回的命令回复之后，会检查回复中leader_epoch参数的值和自己的配置纪元是否相同，如果相同的话，那么源Sentinel继续取出回复中的leader_runid参数，如果leader_runid参数的值和源Sentinel的运行ID一致，那么表示目标Sentinel将源Sentinel设置成了局部领头Sentinel。
如果有某个Sentinel被半数以上的Sentinel设置成了局部领头Sentinel, 那么这个Sentinel成为领头Sentinel。在一个由10个Sentinel组成的Sentinel系统里面，只要有大于等于10/2+1=6个Sentinel将某个Sentinel设置为局部领头Sentinel, 那么被设置的那个Sentinel就会成为领头Sentinel。
因为领头Sentinel的产生需要半数以上Sentinel的支持，并且每个Sentinel在每个配置纪元里面只能设置一次局部领头Sentinel, 所以在一个配置纪元里面，只会出现一个领头Sentinel。
如果在给定时限内，没有一个Sentinel被选举为领头Sentinel, 那么各个Sentinel将在一段时间之后再次进行选举，直到选出领头Sentinel为止。

选举领头Sentinel的过程如下:

假设现在有三个Sentinel正在监视同一个主服务器，并且这三个Sentinel之前已经通过SENTINEL is-master-down-by-addr命令确认主服务器进入了客观下线状态，如下图所示。

那么为了选出领头Sentinel,三个Sentinel将再次向其他Sentinel发送SENTINEL is-master-down-by-addr命令，如下图所示。

在这里插入图片描述

和检测客观下线状态时发送的SENTINEL is-master-down-by-addr命令不同，Sentinel这次发送的命令会带有Sentinel 自己的运行ID, 例如：

SENTINEL is-master-down-by-addr 127.0.0.163790 e955b4c85598ef5b5f055bc7ebfd5e828dbed4fa

如果接收到这个命令的Sentinel还没有设置局部领头Sentinel的话，它就会将运行ID为e955b4c85598ef5b5f055bc7ebfd5e828dbed4fa的Sentinel设置为自己的局部领头Sentinel, 并返回类似以下的命令回复：

1) 1
2) e955b4c85598ef5b5f055bc7ebfd5e828dbed4fa
3) 0

然后接收到命令回复的Sentinel就可以根据这一回复，统计出有多少个Sentinel将自己设置成了局部领头Sentinel。

根据命令请求发送的先后顺序不同，可能会有某个Sentinel的SENTINEL is-master-down-by-addr命令比起其他 Sentinel发送的相同命令都更快到达，并最终胜出领头Sentinel的选举，然后这个领头Sentinel就可以开始对主服务器执行故障转移操作了。

1.9 故障转移

在选举产生出领头Sentinel之后，领头Sentinel将对已下线的主服务器执行故障转移操作，该操作包含以下三个步骤：

在已下线主服务器属下的所有从服务器里面，挑选出一个从服务器，并将其转换为主服务器。
让已下线主服务器属下的所有从服务器改为复制新的主服务器。
将已下线主服务器设置为新的主服务器的从服务器，当这个旧的主服务器重新上线时，它就会成为新的主服务器的从服务器。

1.9.1 选出新的主服务器

故障转移操作第一步要做的就是在已下线主服务器属下的所有从服务器中，挑选出一个状态良好、数据完整的从服务器，然后向这个从服务器发送SLAVEOF no one命令，将这个从服务器转换为主服务器。

下图展示了在一次故障转移操作中，领头Sentinel向被选中的从服务器server2发送SLAVEOF no one命令的情形。

在发送SLAVEOF no one命令之后，领头Sentinel会以每秒一次的频率(平时是每十秒一次),向被升级的从服务器发送INFO 命令，并观察命令回复中的角色(role)信息，当被升级服务器的role从原来的slave变为master时，领头Sentinel就知道被选中的从服务器已经顺利升级为主服务器了。

在这里插入图片描述

例如，在上图展示的例子中，领头Sentinel会一直向server2发送INFO命令，当server2返回的命令回复从：

# Replication
role:slave
...
# Other sections
...

变为:

# Replication
role:master
...
# Other sections
...

的时候，领头Sentinel就知道server2已经成功升级为主服务器了。

下图展示了server2升级成功之后，各个服务器和领头Sentinel的样子。

在这里插入图片描述

1.9.2 修改从服务器的复制目标

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

下图展示了在故障转移操作中，领头Sentinel向已下线主服务器serverl的两个从服务器server3和server4发送SLAVEOF 命令，让它们复制新的主服务器server2的例子。

在这里插入图片描述

下图展示了server3和server4成为server2的从服务器之后，各个服务器以及领头Sentinel的样子。

在这里插入图片描述

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

故障转移操作最后要做的是，将已下线的主服务器设置为新的主服务器的从服务器。比如说，下图1就展示了被领头Sentinel设置为从服务器之后，服务器server1的样子。

因为旧的主服务器已经下线，所以这种设置是保存在server1对应的实例结构里面的，当server1重新上线时，Sentinel就会向它发送SLAVEOF命令，让它成为server2的从服务器。

例如，下图2就展示了server1重新上线并成为server2的从服务器的例子。

在这里插入图片描述

想转码的土木狗

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
打赏
1
评论
Redis夯实基础系列-Sentinel深入浅出

Sentinel(哨岗、哨兵)是Redis的高可用性(high availability)解决方案：由一个或多个Sentinel实例(instance)组成的Sentinel系统(system)可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。
复制链接

扫一扫