Redis3.0-----Sentinel

最新推荐文章于 2024-07-21 21:53:33 发布

shiwenbo1994

最新推荐文章于 2024-07-21 21:53:33 发布

阅读量301

点赞数

分类专栏： Redis

本文链接：https://blog.csdn.net/shiwenbo1994/article/details/99116956

版权

Redis 专栏收录该内容

15 篇文章 0 订阅

订阅专栏

简介

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的初始化过程和普通Redis服务器的初始化过程并不完全相同。如下图所示：
《Redis设计与实现》

使用Sentinel专用代码

第二步是将一部分普通Redis服务器使用的代码替换成Sentinel专用代码。

初始化Sentinel状态

接下来服务器会初始化一个sentinelState结构，这个结构保存了服务器中所有和Sentinel功能有关的状态。

struct entinelState {
	// 当前纪元，用于实现故障转移
	unit64_t current_epoch;
	// 保存了所有被这个sentinel监视的主服务器
	// 字典的键是主服务器的名字
	// 字典的值则是一个指向sentinelRedisInstance 结构指针
	dict *master;
	// 是否进入了TILT模式？
	int tilt;
	// 目前正在执行的脚本的数量
	int running_scripts;
	// 进入TILT模式的时间
	mstime_t tilt_start_time;
	// 最后一次执行时间处理器的时间
	mstime_t previous_time;
	//一个FIFO队列，包含了所有需要执行的用户脚本
	list *scripts_queue;
}sentinel;

初始化Sentinel状态的masters属性

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

字典的键是被监视主服务器的名字。
而字典的值则是被监视主服务器对应sentinelRedisInstance结构。
每个sentinelRedisInstance结构代表一个被Sentinel监视的Redis服务器实例，这个实例可以是主服务器、从服务器、或者另外一个Sentinel。

typedef struct sentinelRedisInstance {
	// 标识值，记录了实例的类型，以及该实例的当前状态
	int flags;
	// 实例的名字
	// 主服务器的名字由用户在配置文件中设置
	// 从服务器以及Sentinel的名字由Sentinel自动设置
	// 格式为ip:port,例如“127.0.0.1:26379”
	char name;
	//实例的运行ID;
	char *runid;
	// 配置纪元，用于实现故障转移
	uint64_t config_epoch;
	// 实例的地址
	sentinelAddr *add;
	// 实例无响应多少毫秒之后才会被判断为主观下线
	mstime_t down_after_period;
	// 判断这个实例为客观下线所需的支持投票数量
	int quorum;
	// 在执行故障转移操作时，可以同时对新的主服务器进行同步的从服务器数量
	int parallel_syncs;
	// 刷新故障迁移状态的最大时限
	mstime_t failover_timeout;	
} sentinelRedisInstance;

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

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

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

为什么有两个连接？如果在信息发送时，想要接收信息的客户端不在线或者断线，那么这个客户端就会丢失这条信息。因此，为了不丢失_sentinel_:hello频道的任何信息，Sentinel必须专门用一个订阅连接来接收该频道的信息。另一个方面，除了订阅频道之外，Sentinel还必须向主服务器发送命令，以此来与主服务器进行通信，所以Sentinel还必须向主服务器创建命令连接。因为Sentinel需要与多个实例创建多个网络连接，所以Sentinel使用的是异步连接。

获取主服务器信息

Sentinel默认会以每十秒一次的频率，通过命令向被监视的主服务器发送INFO命令，并通过分析INFO命令的回复来获取主服务器的当前信息。
《Redis设计与实现》
通过分析主服务器返回的INFO命令回复，Sentinel可以获取以下两方面的信息。

一方面是关于主服务器本身的信息，包括run_id域记录的服务器运行ID,以及role域记录的服务器角色；
另一方面是关于主服务器属下所有从服务器的信息，每个从服务器都由一个“slave”字符串开头的行记录，每行的ip=域记录了从服务器的IP地址，而port=域则记录了从服务器的端口号。根据这些IP地址和端口号，Sentinel无须用户提供从服务器的地址信息，就可以自动发现从服务器
主服务器实例结构和从服务器实例结构之间的区别：
主服务器实例结构的flags属性的值为SRI_MASTER，而从服务器实例结构的flags属性的值为SRI_SLAVE。
主服务器实例结构的name属性的值是用户使用Sentinel配置文件设置的，而从服务器实例结构的name属性的值则是Sentinel根据从服务器的IP地址和端口号自动设置的。

获取从服务器信息

当Sentinel发现主服务器有新的从服务器出现时，Sentinel除了会为这个新的从服务器创建相应的实例结构之外，Sentinel还会创建连接到从服务器的命令连接和订阅连接。
《Redis设计与实现》
根据INFO命令的回复，Sentinel会对从服务器的实例结构进行更新，如下图所示：

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

在默认情况下，Sentinel会以每两秒一次的频率，通过命令连接向所有被监视的主服务器和从服务器发送以下格式的命令：
PUBLISH _sentinel_:hello "<s_ip>,<s_port>,<s_runid>,<s_epoch>,<m_name>,<m_ip>,<m_epoch>"

其中以s_开头的参数记录是Sentinel本身的信息，各个参数的以下如下表所示：
而m_开头的参数记录的是主服务器的信息，各个参数的意义如下表所示。

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

当Sentinel与一个主服务器或者从服务器建立起订阅连接后，Sentinel就会通过订阅连接，向从服务器发送以下命令：
SUBSCRIBE _sentinel_ :hello
Sentinel对_sentinel_:hello频道的订阅会一直持续到Sentinel与服务器的连接断开为止。
对于每个与Sentinel连接的服务器，Sentinel既通过命令连接向服务器的sentinel_:hello频道发送信息，又通过订阅连接从服务器的_sentinel_:hello频道接收信息，如图所示：
《Redis设计与实现》

更新sentinels字典

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

sentinels字典的键是其中一个Sentinel的名字，格式为ip:port.
sentinels字典的值则是键所对应Sentinel的实例结构。

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

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

Sentinel之间不会创建订阅连接 Sentinel在连接主服务器或者从服务器时，会同时创建命令连接和订阅连接，但是在连接其他Sentinel时，却只会创建命令连接，而不创建订阅连接。这是因为Sentinel需要通过接收主服务器或者从服务器发来的频道信息来发现未知的新的Sentinel，所以才需要建立订阅连接，而相互已知的Sentinel只要使用命令连接进行通信就足够了。

检测主观下线状态

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

有效回复：实例返回+PONG、-LOADING、 -MASTERDOWN三种回复的其中一种。
有效回复：实例返回除+PONG、-LOADING、-MASTERDOWN三种回复之外的其他回复，或者在指定时限内没有返回任何回复。
Sentinel配置文件中的down-after-milliseconds选项制定了Sentinel判断实例进入主观下线所需的时间长度：如果一个实例在down-after-milliseconds毫秒内，连续向Sentinel返回无效回复，那么Sentinel会修改这个实例所对应的实例结构，在结构的flags属性中打开SRI_S_DOWN标识，以此来表示这个实例已经进入主观下线状态。

检查客观下线状态

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

客观下线状态的判断条件当认为主服务器已经进入下线状态的Sentinel的数量，超过Sentinel配置中设置的quorum参数的值，那么该Sentinel就会认为主服务器已经进入客观下线状态。比如说，如果Sentinel在启动时载入了以下配置： `sentinel monitor master 127.0.0.1 6379 2` 那么包括当前Sentinel在内，只要总共有两个Sentinel认为主服务器已经进入下线状态，那么当前Sentinel就将主服务器判断为客观下线。

选举领头Sentinel

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

所有在线的Sentinel都有被选为领头Sentinel的资格。
每次进行领头Sentinel选举之后，不论选举是否成功，所有Sentinel的配置纪元的值都会自增一次。
在一个配置纪元里面，所有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 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称为领头Sentinel.
因为领头Sentinel的产生需要半数以上Sentinel的支持，并且每个Sentinel在每个配置纪元里面只能设置一次局部领头Sentinel，所以在一个配置纪元里面，只会出现一个领头Sentinel.
如果在给定时限内，没有一个Sentinel被选举为领头Sentinel，那么各个Sentinel将在一段时间之后再次进行选举，直到选出领头Sentinel为止。

故障转移

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

参考

《Redis设计与实现》

shiwenbo1994

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Redis3.0-----Sentinel

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

扫一扫

专栏目录