17.Sentinel

Redis Sentinel 高可用机制

最新推荐文章于 2022-05-06 21:05:24 发布

原创最新推荐文章于 2022-05-06 21:05:24 发布 · 797 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#redis #sentinel

Redis设计与实现专栏收录该内容

24 篇文章

订阅专栏

Sentinel

Sentinel（哨岗、哨兵）是Redis的高可用性（high availability）解决方案。

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

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

启动并初始化Sentinel

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

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

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

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

初始化服务器；

Sentinel本质上只是一个运行在特殊模式下的Redis服务器，它使用了和普通模式不同的命令表。
将普通Redis服务器使用的代码替换成Sentinel专用代码；
初始化Sentinel状态；（sentinelState）
根据给定的配置文件，初始化Sentinel的监视主服务器列表；（sentinelRedisInstance）

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

对Sentinel状态的初始化将引发对masters字典的初始化，而masters自动的初始化是根据被载入的Sentinel配置文件来进行的。
创建连向主服务器的网络连接。

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

1). 一个是命令连接，这个连接专门用于向主服务器发送命令，并接收命令回复。

2). 另一个是订阅连接，这个连接专门用于订阅主服务器的_sentinel_:hell频道。

Sentinel与服务器之间交互

获取主服务器信息

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

通过分析主服务器返回的INFO命令回复，Sentinel可以获取主服务器本身的信息和主服务器属下所有从服务器的信息，信息存放结构如下：

获取从服务器信息

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

在创建命令连接后，Sentinel默认会通过命令连接每十秒向从服务器发送一次INFO命令，并获取到从服务器的信息。

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

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

PUBLISH_sentinel_:hello “<s_ip>,<s_port>,<s_runid>,<s_epoch>,<m_name>,<m_ip>,<m_port>,<m_epoch>”

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

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

SUBSCRIBE_sentinel_:hello

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

Sentinel需要通过接收主服务器或者从服务器发来的频道信息来发现未知的新Sentinel。

也就是说，对于每个与Sentinel连接的服务器，Sentinel即通过命令连接向服务器的 _sentinel_:hello频道发送信息，又通过订阅连接从服务器的 _sentinel_:hello频道接收信息。

更新sentinels字典

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

当一个Sentinel接收到其他Sentinel发来的信息时，该Sentinel会从信息中分析并提取出与Sentinel和主服务器有关的参数，并更新相应的实体结构。

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

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

Sentinel实现主观下线检测和客观下线检测

使用命令连接相连的各个Sentinel可以通过向其他Sentinel发送命令请求来进行信息交换，来实现主观下线检测和客观下线检测。

检测主观下线状态：

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

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

检测客观下线状态：

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

选举领头Sentinel

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

以下是Redis选举领头Sentinel的规则和方法：

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