Redis之哨兵

简介

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

启动并初始化Sentinel

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

$ redis-sentinel /path/to/your/sentinel.conf 或者命令
$ redis-server /path/to/your/sentinel.conf --sentinel

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

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

在详细讲解Sentinel初始化之前，我们先看一个典型的sentinel.conf配置，因为后面的流程也会涉及到配置中的内容：

//哨兵端口号
port 16000 
//关闭保护模式
protected-mode no 
//守护进程
daemonize yes 
//哨兵程序的工作路径
dir /usr/local/redis/sentinel/ 
//master的访问密码
sentinel auth-pass mymaster 111222
//Sentinel去监视一个名为mymaster的主redis master服务，这个主实例的IP地址端口号为192.168.1.161和17000，quorum为2
sentinel monitor mymaster 192.168.1.161 6379 2
//如果哨兵5s内未收到mymaster的有效ping回复，则认为mymaster处于down状态
sentinel down-after-milliseconds mymaster 5000
//执行切换的超时时间，如果在该时间（ms）内未能完成failover操作，则认为该failover失败，生产环境需要根据数据量设置该值 
sentinel failover-timeout mymaster 300000 
//在执行故障转移时，主从切换完成后最多可以有多少个从Redis实例可以同时向新的Redis Master发起同步数据请求，在从Redis实例较多的情况下这个数字越小，同步的时间越长，完成故障转移所需的时间就越长
sentinel parallel-syncs mymaster 2

sentinel auth-pass resque 333444
sentinel monitor resque 192.168.1.162 6380 4
sentinel down-after-milliseconds resque 5000
sentinel failover-timeout resque 300000 
sentinel parallel-syncs resque 2

针对上面的配置文件我们重点分析下quorum的作用。quorum在哨兵中有两层含义。第一层含义为：如果某个哨兵认为其监听的Master处于下线的状态，这个状态在Redis中标记为S_DOWN，即主观下线。假设quorum配置为2，则当有两个哨兵同时认为一个Master处于下线的状态时，会标记该Master为O_DOWN，即客观下线。只有一个Master处于客观下线状态时才会开始执行切换。第二层含义为：假设有5个哨兵，quorum配置为4。首先，判断客观下线需要4个哨兵才能认定。其次，当开始执行切换时，会从5个哨兵中选择一个leader执行该次选举，此时一个哨兵也必须得到4票才能被选举为leader，而不是3票（即哨兵的大多数）。

初始化服务器

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

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

• 普通Redis服务器在初始化时会通过载入RDB文件或者AOF文件来还原数据库状态，但因为Sentinel并不使用数据库，所以初始化Sentinel时就不会载入RDB文件或者AOF文件。
• 初始化时，使用的代码也不同。例如：普通Redis服务器使用redis.h/REDIS_SERVERPORT常量的值作为服务器端口，而sentinel则使用sentinel.c/REDIS_SENTINEL_PORT常量的值作为服务器端口；普通Redis服务器使用redis.c/redisCommandTable作为命令表，Sentinel服务器使用sentinel.c/sentinelcmds作为服务器的命令表，所以在Sentinel模式下，Redis服务器不能执行诸如SET、DBSIZE等等这些命令，因为服务器根本没有在命令表中载入这些命令。

初始化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;

初始化Sentinel状态的master属性

Sentinel状态中masters字典记录了所有被sentinel监视的主服务器的相关信息，其中：字典的键是被监视主服务器的名字；字典的值是被监视主服务器对应的sentinel.c/sentinelRedisInstance结构。

typedef struct sentinelRedisInstance {
    //标识值，记录了实例的类型，以及该实例的当前状态
    int flags;
 
    //实例的名字
    //主服务器的名字由用户在配置文件中设置
    //从服务器以及Sentinel 的名字由Sentinel 自动设置
    //格式为ip:port ，例如"127.0.0.1:26379"
    char *name;
 
    //实例的运行ID
    char *runid;
 
    //主服务器属下所有的从服务器
    dict *slaves;
 
    //配置纪元，用于实现故障转移
    uint64_t config_epoch;
 
    //实例的地址
    sentinelAddr *addr;
 
    // SENTINEL down-after-milliseconds 选项设定的值
    //实例无响应多少毫秒之后才会被判断为主观下线（subjectively down ）
    mstime_t down_after_period;

    // SENTINEL monitor     选项中的quorum 参数
    //判断这个实例为客观下线（objectively down ）所需的支持投票数量
    int quorum;
 
    // SENTINEL parallel-syncs   选项的值
    //在执行故障转移操作时，可以同时对新的主服务器进行同步的从服务器数量
    int parallel_syncs;
 
    // SENTINEL failover-timeout   选项的值
    //刷新故障迁移状态的最大时限
    mstime_t failover_timeout;
    // ...
} sentinelRedisInstance;

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

由配置文件可知，由于某个sentinel服务器的配置文件中只配置了多个主服务器的信息，所以在初始化Sentinel状态时，并不会初始化与这些主服务器相关的从服务器以及监视这些主服务器的其他sentinel节点的信息，那么从服务器和其他sentinel节点的信息是什么时候载入的呢？又是如何载入的呢？下面我们会详细讲解。

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

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

• 命令连接，这个连接专门用于向主服务器发送命令，并接受命令回复。
• 订阅连接，这个链接专门用于订阅主服务器的_sentinel_:hello频道。

事实上，sentinel不但会和主服务器之间建立命令连接和订阅连接，也会和所有的从服务器之间建立命令连接和订阅连接，并且会和监视主服务器的其他sentinel服务器建立命令连接，但sentinel之间不会创建订阅连接。
需要注意的是，sentinel与主服务器、从服务器、其他sentinel服务器建立网络连接的时机是不同的。

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

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

Sentinel的时间任务

在我们启动Sentinel时，我们看main()具体代码会发现，主流程只是进行了一些初始化，那何时建立命令连接和消息连接的呢？答案是在Redis的时间任务serverCron中。
哨兵中每次执行serverCron时，都会调用sentinelTimer()函数。该函数会建立连接，并且定时发送心跳包并采集信息。该函数主要功能如下：

• 建立命令连接和订阅连接。订阅连接建立之后会订阅Redis服务的_sentinel_:hello频道
• 在命令连接上每10s发送INFO命令进行信息采集；每1s在命令连接上发送ping命令探测存活性；每2s在命令连接上发布一条信息，包含：哨兵的ip，哨兵的端口、哨兵的ID（40字节的随机字符串）、当前纪元（用于选举和主从切换）、Redis Master的名称、Redis Master的ip、Redis Master的端口、Redis Master的配置纪元（用于选举和主从切换）。
• 检测服务是否处于主观下线状态。
• 检测服务是否处于客观下线状态并且需要进行主从切换。

发送INFO命令

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

• 一方面是关于主服务器本身的信息
  Sentinel会根据返回的主服务器的信息对主服务器的实例结构进行更新。
• 另一方面是关于主服务器属下所有从服务器的信息
  对于返回的从服务器信息，则会被用于更新主服务器实例结构的slaves字典，这个字典记录了主服务器属下从服务器的名单。
  当Sentinel发现主服务器有新的从服务器出现时，Sentinel除了会为这个新的从服务器创建相应的实例结构之外，Sentinel还会创建连接到从服务器的命令连接和订阅连接。
  在创建命令连接后，Sentinel默认会以每10s一次的频率通过命令连接向从服务器发送INFO命令，并通过返回的内容：从服务器运行ID即run_id、从服务器的角色、所属主服务器的ip和端口、从服务器的优先级、从服务器的复制偏移量等信息，对从服务器的实例结构进行更新。

发送_sentinel__:hello

默认情况下，Sentinel会以每两秒一次的频率，通过命令连接向所有被监视的主服务器和从服务器_sentinel__:hello开头的命令。

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

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

对于监视同一个服务器的多个Sentinel来说，一个Sentinel发送的信息会被其他Sentinel接收到，这些信息会被用于更新其他Sentinel对发送信息Sentinel的认知，也会被用于更新其他的Sentinel对被监视服务器的认知。
换句话说，一个Sentinel从_sentinel__:hello频道接收到一条信息时，Sentinel会对这条信息进行分析，提取出信息中的Sentinel IP地址、Sentinel端口号、Sentinel运行ID等八个参数，并进行以下检查：

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

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

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

发送PING命令

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

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

注意一：主观下线时长选项的作用范围
用户设置的down-after-milliseconds选项的值，不仅会被Sentinel用来判断主服务器的主观下线状态，还会被用于判断主服务器属下的所有从服务器，以及所有同样监视这个主服务器的其他Sentinel的主观下线状态。
注意二：多个Sentinel设置的主观下线时长可能不同
对于监视同一个主服务器的多个sentinel来说，它们设置的down-after-milliseconds的值可能不同，这样一来，当一个Sentinel将主服务器判断为主观下线是，其他的Sentinel可能仍然会认为此主服务器处于在线状态。
检测客观下线
当Sentinel将一个主服务器判断为主观下线后，为了确认这个主服务器是否真的下线了，它会向同样监视这个主服务器的其他Sentinel进行询问，看它们是否也认为此主服务器已进入了下线状态（可以是主观下线或者客观下线）。当Sentinel从其他Sentinel那里接收到足够数量的已下线判断之后，Sentinel就会将此主服务器判定为客观下线，并对主服务器执行故障转移操作。

注意一：判断客观下线的判断条件
当认为主服务器已经进入下线状态的Sentinel的数量，超过Sentinel配置中设置的quorum参数的值，那么该Sentinel就会认为此主服务器已经进入客观下线状态。
注意二：不同Sentinel判断客观下线的条件可能不同
对于监视同一个主服务器的多个Sentinel来说，它们将主服务器判断为客观下线的条件可能也不同：当一个Sentinel将主服务器判断为客观下线时，其他Sentinel可能并不这么认为。

选举领头Sentinel

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

• 所有在线的Sentinel都有被选举为领头Sentinel的资格，换句话说，监视同一个主服务器的多个在线Sentinel中的任意一个都有可能成为领头Sentinel。
• 每次进行领头Sentinel选举之后，无论选举是否成功，所有Sentinel的配置纪元的值都会自增一次。配置纪元实际上就是一个计数器。
• 在一个配置纪元里，所有Sentinel都有一次将某个Sentinel设置为局部领头Sentinel的机会，并且局部领头一旦设置，在这个配置纪元里面就不能再更改。
• 每个发现主服务器进入客观下线的Sentinel都会要求其他Sentinel将自己设置为局部领头Sentinel。
• 当一个sentinel（源Sentinel）向另一个Sentinel（目标Sentinel）发送命令时，会带上源Sentinel的runID，这表示源Sentinel要求目标Sentinel将自己设置为后者的局部领头Sentinel。
• Sentinel设置局部领头Sentinel的规则是先到先得：最先向目标Sentinel发送设置要求的源Sentinel将成为目标Sentinel的局部领头Sentinel，而之后接收到的所有设置要求都会被目标Sentinel拒绝。
• 目标Sentinel在接收到命令之后，将向源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会将已下线主服务器的所有从服务器保存到一个列表里面，然后按照以下规则，一项一项地对列表进行过滤：

• 删除列表中所有处于下线或者断线状态的从服务器，这可以保证列表中剩余的从服务器都是正常在线的。
• 删除列表中所有最近五秒内没有回复过领头Sentinel的INFO命令的从服务器，这可以保证列表中剩余的从服务器都是最近成功进行过通信的。
• 删除所有与已下线主服务器连接断开超时down-after-milliseconds10毫秒的从服务器：down-after-milliseconds选项指定了判断主服务器下线所需的时间，而删除断开时长超过down-after-milliseconds10毫秒的从服务器，则可以保证列表中剩余的从服务器都没有过早地与主服务器断开连接，换句话说，列表中剩余的从服务器保存的数据都是比较新的。
• 之后，领头Sentinel将根据从服务器的优先级，对列表中剩余的从服务器进行排序，选出其中优先级最高的从服务器。如果有多个具有相同最高优先级的从服务器，那么领头Sentinel将按照从服务器的复制偏移量，选出其中复制偏移量最大的从服务器。如果有多个最大优先级和复制偏移量都相同的从服务器，则从中选出运行ID最小的从服务器。

修改从服务器的复制目标

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

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

故障转移操作最后要做的是，将已下线的主服务器设置为新的主服务器的从服务器。
因为旧的主服务器已经下线，所有这种设置是保存在旧的主服务器对应的实例结构里面的，当旧的主服务器重新上线时，Sentinel就会向它发送SLAVEOF命令，让它成为新的主服务器的从服务器。

学习链接

Redis之详解