【Redis-09】Redis哨兵机制的实现原理-Sentinel

 Sentinel是Redis高可用性的解决方案：由一个或者多个Sentinel实例组成的哨兵系统监视多个主从服务器，并实现主从服务器的故障转移。

 Sentinel本质上只是一个运行在特殊模式下的Redis服务器，使用以下命令可以启动并初始化一个Sentinel实例：

redis-sentinel /path/../sentinel.conf
redis-server /path/../sentinel.conf --sentinel

 下面我们看一下，启动一个Sentinel实例后，它做了哪些初始化步骤吧。

1. 启动并初始化Sentinel

1.1 初始化服务器

 首先Sentinel也是一台Redis服务器，所以启动后的第一步就是初始化服务器，但是这里的初始化和之前我们普通的Redis服务器不太一样，有些步骤不需要执行，例如载入持久化文件还原数据库状态等等。

1.2 使用Sentinel专用代码

 初始化后的第二步就是将一部分Redis服务器的代码替换成为Sentinel的专用代码，比如服务器的默认端口号，比如Sentinel模式下的命令表等等，正是由于两者使用的命令表不同，所以在哨兵模式下，有些普通键值对命令无法正常执行。

1.3 初始化Sentinel的状态

 接下来Sentinel服务器会初始化一个SentinelState的结构，这里面用于保存和哨兵模式相关的一些状态属性。源代码如下，先混个眼熟，下面我们讲解各部分过能时会用到里面的属性。

struct sentinelState {
	// 当前sentinel的运行id
    char myid[CONFIG_RUN_ID_SIZE+1]; /* This sentinel ID. */
    // 当前纪元
    uint64_t current_epoch;         /* Current epoch. */
    // 所监视的主服务器字典
    dict *masters;      /* Dictionary of master sentinelRedisInstances.
                           Key is the instance name, value is the
                           sentinelRedisInstance structure pointer. */
    int tilt;           /* Are we in TILT mode? */
    int running_scripts;    /* Number of scripts in execution right now. */
    mstime_t tilt_start_time;       /* When TITL started. */
    mstime_t previous_time;         /* Last time we ran the time handler. */
    list *scripts_queue;            /* Queue of user scripts to execute. */
    char *announce_ip;  /* IP addr that is gossiped to other sentinels if
                           not NULL. */
    int announce_port;  /* Port that is gossiped to other sentinels if
                           non zero. */
    unsigned long simfailure_flags; /* Failures simulation. */
    int deny_scripts_reconfig; /* Allow SENTINEL SET ... to change script
                                  paths at runtime? */
} sentinel;

1.4 初始化sentinelState的masters属性

 这个masters属性是一个指针，指向一个dict结构，记录了所有被Sentinel监视的主服务器的信息，记住，这里是主服务器。其中key = 主服务器的名字，value = 主服务器的实例结构（由sentinelRedisInstance结构实现）

 这里提到了**sentinelRedisInstance结构，它可以是主服务器，从服务器或者另一个Sentinel实例。这里仅展示一部分代码片段：

typedef struct sentinelRedisInstance {
    // 该实例当前的状态
    int flags;      /* See SRI_... defines */
    // 该实例的名字
    char *name;     /* Master name from the point of view of this sentinel. */
    // 实例运行的id
    char *runid;    /* Run ID of this instance, or unique ID if is a Sentinel.*/
    // 配置纪元，用于实现故障转义
    uint64_t config_epoch;  /* Configuration epoch. */
    // 实例的地址
    sentinelAddr *addr; /* Master host. */
    ...
} sentinelRedisInstance;

 这里面有一个addr指针，保存着当前实例的ip地址和端口号，指向的是一个sentinelAddr实例，看代码如下所示：

typedef struct sentinelAddr {
    char *ip;	/* 实例的ip地址 */
    int port;	/* 实例的端口号 */
} sentinelAddr;

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

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

1. 一个是命令连接，这个用于发送命令并接受回复消息；
2. 一个是订阅链接，用于监听__sentinel__:hello频道。

2.获取主服务器的信息

 在初始化一个Sentinel实例并且连接到主服务器之后，Sentinel接下来会以每10s一次的频率，通过命令连接向所有被监视的主服务器发送INTO命令，并通过分析命令回复来获取服务器当前的状态信息。这里会包含两方面的信息，分别是：

1. 一方面是关于主服务器本身的信息，比如run_id服务器运行id，role角色信息等；
2. 主服务器下所有从服务器的信息，每个从服务器会通过一个“slave”字符串开头的行记录，基于此，Sentinel无需用户提供，就可以知道所有从服务器的信息。

 通过以上的回复信息，Sentinel就可以对主服务器实例结构的部分信息进行更新，而且会将从服务器的实例记录到主服务器的 slaves字典中，当然如果之前 slaves已经存在此从服务器的实例，会对这部分实例的内容进行更新，这是存在于sentinelRedisInstance里面的一个属性：

typedef struct sentinelRedisInstance {
    ...
    // 表示主服务器下的所有从服务器信息
    dict *slaves;       /* Slaves for this master instance. */
    ...
} sentinelRedisInstance;

 综上，Sentinel监视主从服务器的示意图如下：

3. 获取从服务器的信息

 通过第二步，Sentinel检测到了从服务器的存在，那么接下来，Sentinel除了会给从服务器创建实例外，还会创建连接到从服务器的命令连接和订阅连接。之后，Sentinel也会以每10s一次的频率通过命令连接向服务器发送 INTO命令。同理根据命令的回复，Sentinel会对从服务器的内容属性进行更新，包括从服务器的运行ID run_id，服务器的role，从服务器的复制偏移量，此从服务器对应主服务器的信息等。

4.发布与订阅消息

4.1 发布消息

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

PUBLISH __sentinel__hello: "sentinel-ip,sentinel-端口号,sentinel-runid,sentinel-纪元,服务器名称,服务器ip,服务器端口号,服务器纪元"

 通过这条命令，所有服务器都会在这个__sentinel__:hello频道上执行发布操作。

4.2 订阅消息

 Sentinel与主服务器和从服务器建立连接后，会订阅此服务器__sentinel__:hello这个频道。也就是说，Sentinel既通过命令连接要求各服务器向这个频道发送消息，也从这个频道上接收消息，这是为什么呢？

 其实，对于监视同一个服务器的Sentinel来说，他们会通过监听这个频道获悉正在监听此服务器的其他Sentinel实例，用于更新自己的sentinels字典。所以在接收到__sentinel__:hello这个频道的消息后，Sentinel还要做下面这几件事情：

1. 更新当前sentinel实例监听主服务器的sentinels字典：当一个Sentinel接收到来自其他Sentinel发来的问候消息时，会分析并提取出其他sentinel和master的参数，并检查自身的sentinels字典里面是否包含此sentinel实例，如果不包含就添加，如果包含会比对数据并进行更新。这里祭出源码：

typedef struct sentinelRedisInstance {
    ...
    // 表示监听当前主服务器下的所有sentinel实例（这里不包含当前的sentinel实例）
    dict *sentinels;    /* Other sentinels monitoring the same master. */
    ...
} sentinelRedisInstance;

2. 创建与其他Sentinel的命令连接：在经历步骤1之后，如果发现了新的Sentinel实例，会创建一个连接到新Sentinel的命令连接，同理新Sentinel在收到新消息后也会创建与当前Sentinel的链接，最终所有的Sentinel之间，会形成一张相互连接的网络。这里需要注意一下，Sentinel实例之间不会创建订阅链接，所以其实是新上线的Sentinel通过与主服务的订阅链接告诉所有Sentinel实例，然后他们之间再互相创建命令连接。
   

5. 检测主观下线状态

 经过这么多复杂的过程后，Sentinel就会以每秒一次的频率向所有与他创建了命令连接的实例（我们来看一下这些实例有哪些，分别是主服务器、从服务器、其他Sentinel实例）发送PING消息，并通过对方的回复确定是否在线。
 如果实例在指定的时间内（down-after-milliseconds毫秒）没有回复，Sentinel会将此实例标记为下线的状态（flags = SRI_S_DOWN）,此实例相对于此Sentinel就进入了主观下线状态。然而对于监视同一个服务器的多个Sentinel实例而言，由于设置的判断阈值时间不一样，会存在其他Sentinel实例判断此服务器仍然在线。

6. 检测客观下线状态

 当Sentinel将一个主服务器判定为主观下线后，为了防止因网络问题误判造成的假死结果，Sentinel会向其他所有的Sentinel实例咨询，当收到足够的主观下线回复后，就会将主服务器标记为客观下线，并进行故障转移，步骤如下：

1. 源Sentinel向其他Sentinel实例发送询问命令 sentinel is-master-down-by-addr，命令中包含主服务器的ip、端口号、当前纪元等信息。
2. 其他Sentinel实例接收 sentinel is-master-down-by-addr 命令后检查主服务器的状态（是否SRI_S_DOWN），并回复结果（是否主观下线）
3. 源Sentinel接收其他Sentinel命令，当反馈的主服务器主观下线数量超过配置的阈值数量（quonum）时，将此服务器的客观下线状态标识（flags = SRI_O_DOWN）打开。

7. 选举领头Sentinel

 经过上面客观下线的判定后，监视下线主服务器的所有Sentinel会进行协商选举出一个领头Sentinel，由领头Sentinel对下线的主服务器进行故障转移。这里需要注意的是，检测主观和客观下线的可能不是一个Sentinel，由于时间先后顺序，监视同一个主服务器的Sentinel实例会陆续执行主观下线到客观下线的判定执行。下面我们看下选举领头Sentinel的选取规则：

1. 最先判定客观下线的Sentinel实例（称为源1Sentinel）会向监视此服务器的所有Sentinel实例（目标Sentinel）发送 sentinel is-master-down-by-addr ，命令中会包含主服务器的ip、端口号、当前纪元，还有一个自身的runid。
2. 目标Sentinel由于是首次收到领头Sentinel的选举，此时会将源1Sentinel设置为自身的leader，并给源1Sentinel回复一条命令，命令中包含源1的runid和当前纪元。后面再有其他Sentinel要求此目标Sentinel选举自身当leader的命令到来，都会被目标Sentinel拒绝，因为在当前纪元只能有一次选举权。
3. 源1Sentinel接收到目标Sentinel的命令消息后，判断纪元和runid与自身的值是否相同，如果相同，那么表示目标已经将源1自己设置为领头Sentinel了。在向所有目标Sentinel发送完命后，如果源1收集到半数以上的回复后，就会成为最终的领头Sentinel。
4. 下面其余陆续发现了服务器客观下线的源2/3/n…Sentinel，也会执行这些动作，看谁先能获得半数以上的投票就会成为leader。当然也可能在给定的时间内，没有一个Sentinel被选举为领头Sentinel，那就会过一段时间后，再次进行选举，步骤相同。

8. 故障转移

 经过第7步，在选举出领头Sentinel后，领头Sentinel会对已下线的主服务器执行故障转移操作，这里面包包含三个步骤：

1. 从主服务器的从服务器中选举出一个状态良好、数据完整的从服务器，然后向这个从服务器发送slave no one，于是此从服务器转换为主服务器（server2）。这里选举的规则是：
   • 优先选择优先级最高的从服务器；
   • 其次选择偏移量比较高的从服务器；
   • 再次会按照运行ID进行排序，选取最小运行ID的从服务器；
2. 向已下线主服务器（server1）的其余从服务器发送slaveof的命令，实现更换其余从服务器复制的主服务器目标。
3. 将已下线的主服务器（server1）设置为从服务器，当已下线的主服务器再次上线时，领头Sentinel就会向他发送slaveof的命令，使得server1成为server2的从服务器。

9. 总结

 以上就是哨兵机制的实现原理，我整理自《Redis设计与实现这本书》，如果您觉得有问题，就给我留言吧，感谢关注和点赞。