引言

接上一篇，今天我们来聊一聊Redis的高可用的第二个解决方案：哨兵模式。

一、Redis哨兵模式

哨兵模式（sentinel）是Redis提供的高可用的解决方案之一。由一个或者多个sentinel示例组成的sentinel系统，可以监听任意数量的主服务器，以及这些服务器属下的所有从服务器，并在被监视的主服务进入下线状态时，自动从该主服务器属下的从服务器中选出新的主服务器，对外提供服务。

1.1 哨兵模式优缺点

• 优点：在主从复制的基础上实现了主节点的自动故障转移
• 缺点：部署麻烦、数据可能丢失、扩展麻烦、主从迁移很慢（大概在几十秒），实际项目中大部分用的是集群的解决方案

sentinel本质上是一个运行在特殊模式下的Redis服务器。不过，因为sentinel不存储业务数据，只用来监视数据节点的状态，所以它的代码和普通Redis服务器是不同的。比如：服务的端口和命令表的不同。

sentinel使用的端口及命令表

#define REDIS_SENTINEL_PORT 26379
// src/sentinel.c
struct redisCommand sentinelcmds[] = {{"ping",pingCommand,1,"fast @connection",0,NULL,0,0,0,0,0},...{"info",sentinelInfoCommand,-1,"random @dangerous",0,NULL,0,0,0,0,0},...
};

二、如何使用哨兵模式

2.1 启动哨兵模式

使用命令启动sentinel

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

假设有如下配置文件：表示该sentinel监视了两个主服务器master1和master2 ，该sentinel会创建如下图的两个sentinelRedisInstance 实例结构，结构源码及各个字段的功能描述，我们会在源码分析部分详细展开，这里不做赘述：

####################
# master1 configure #
####################
sentinel monitor master1 127.0.0.1 6379 2
sentinel down-after-milliseconds master1 30000
sentinel parallel-sync master1 1
sentinel failover-timeout master1 900000
####################
# master2 configure #
####################
sentinel monitor master2 127.0.0.1 2345 5
sentinel down-after-milliseconds master2 50000
sentinel parallel-sync master2 5
sentinel failover-timeout master2 450000

2.2 哨兵节点获取被监听对象信息

在加载完配置文件，sentinel获取到要监视的主服务器，会为每个主服务器都创建两个异步的网络连接：命令连接和订阅连接。前者主要用来向主服务器发送命令和接收命令回复，后者用来专门订阅主服务的__sentinel__:hello 频道，这个频道的作用主要用来感知和通知其他sentinel或自身sentinel的存在。

Redis是如何区分一个实例是主服务器、从服务器和sentinel的？
主要看flags字段，SRI_MASTER、SRI_SLAVE、SRI_SENTINEL

2.2.1 获取主服务器信息及下属所有从服务器。

创建完网络连接，sentinel和主服务器就可以通信了。sentinel默认以每10秒一次的频率，通过命令连接想被监视的主服务器发送INFO命令，通过INFO命令的回复获取主服务器的当前信息。这些信息包括两方面：（1）主服务器自身的信息，如自己的run_id 和角色（主/从/sentinel）；（2）该主服务器属下所有的从服务器的信息（ip、port 在线状态、复制偏移等）；

对于获取的从服务器的信息会被用来更新所属主服务器示例结构的slaves字典，这个字典保存主服务器所有的从服务器信息，字典的key是sentinel自动设置的名字（格式为：ip+port），字典的值为从服务器对应的实例结构。sentinel在分析从服务器的信息时，如果存在，则更新该实例结构，如果从服务器的实例不存在，则说明该从服务器是新发现的，会在slaves字典中为这个从服务器创建新的实例，并且为该从服务器创建两个异步连接：命令连接和订阅连接。在命令连接创建完成后，sentinel默认会以10秒一次的频率向从服务器发送INFO命令，获取从服务器的信息，类似下面的回复：

run_id:32be0699dd27b410fc790da3a6fab17f97899f  //从服务器的运行id
...
# Replication
role:slave                    //从服务器的角色role
master_host:127.0.0.1         //主服务器的ip
master_port:6379              //主服务器的port
master_link_status:up         //主从服务器的连接状态
slave_repl_offset:11887       //从服务器的复制偏移量
slave_priority:100            //从服务器的优先级
# other sectiorns
...

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

sentinel默认会以每两秒一次的频率，通过命令连接向所有被监视的主、从服务器的__sentinel_:hello频道发送以下命令：

PUBLISH __sentinel:hello ",,,,,,,"

命令说明：
所有以s_开头的参数记录的是sentinel本身的信息；以m_开头的参数表示的是主服务器的信息，如果sentinel监视的是主服务器，那么这些参数记录的就是主服务器的信息，如果监视的是从服务器，这些参数记录的是从服务器正在复制的主服务器的信息。

这个命令有什么用呢？当sentinel与一个主服务器或者从服务器建立起订阅连接后，sentinel就会通过订阅连接，向服务器发送：

SUBSCRIBE _sentinel:hello

也就是说监视了同一主服务器sentinel都订阅了该频道。当一个sentinel往该频道里发送消息是，所有的sentinel都能收到该条消息，包括自身。收到消息的sentinel会根据s_runid来判断是不是自己发出的消息，如果是自己发的就丢弃；如果是别的sentinel发的，更新相应的主服务器实例结构，具体来说就是：收到消息的sentinel会在自己的sentinel状态的masters字典中查找对应的主服务器实例，再在主服务的实例对应的sentinels字典中查找有没有发消息的sentinel的信息，如果有就更新sentinel的实例结构，如果没有说明该sentinel是刚开始监听主服务器的sentinel，为其创建sentinel结构添加到主服务器的sentinels字典中。该字典保存所有监视同一服务器的sentinel。

sentinel可以通过接收频道的信息来感知其他sentinel的存在，并通过发送频道信息让其他sentinel知道自己的存在。

当sentinel通过频道信息发现了一个新的sentinel时，不仅会在自己的sentinels字典中创建相应的实例，还会创建连向新sentinel的命令连接，而新的sentinel同样会创建连向这个sentinel的命令连接。sentinel之间通过命令连接进行接下来的一系列操作（主客观下线、选举等）。

三、sentinel工作流程

哨兵模式的工作流程可以分为五个步骤：主观下线、客观下线、哨兵选举、从库选主和故障转移

3.1 主观下线

主观下线：就是某个sentinel认为某个实例下线了，就是单纯的“我以为”，还要经过其他的sentinel的认同，才会进入“客观下线”，也就是大家都认为。

sentinel默认会以每秒一次的频率向所有与自己创建了命令连接的实例（主从、其他sentinel）发送PING命令，通过返回值来判断某个实例是否下线。在配置文件中有个参数down-after-milliseconds，这个参数指定sentinel判断一个实例主观下线的时间长度。如果一个实例在down-after-milliseconds毫秒内，连续想sentinel返回了无效回复，sentinel就会修改该实例对应的flags子弹，打开SRI_S_DOWN标识，以此标记这个实例进入主观下线状态。

回复结果：

• 有效回复： +PONG -LOADING -MASTERDOWN 三种；
• 无效回复：除有效回复外的所有回复

假设用户配置如下：

sentinel monitor master 127.0.0.1 6379 2
sentinel down-after-milliseconds master 50000

这50000毫秒不仅是sentinel判断master进入主观下线的标准，也会是sentinel判断master属下所有从服务器和所有监视该master的其他sentinel进入主观下线的标准。

注意：多个sentinel设置的主观下线时长可能不同，需要查看具体的配置文件。

3.2 客观下线

当一个sentinel认为一个主服务器为主观下线后，为了确保这个主服务器是不是真的下线了，需要向监视了这个主服务器的其他sentinel询问。当收到足够数量的下线信息后，sentinel会将主服务器判定为客观下线，设置flags的SRI_O_DOWN标识，并准备对主服务器进行故障转移操作。

通过发送 SENTINEL is-mater-down-by-addr 命令询问其他sentinel

SENTINEL is-mater-down-by-addr    

当认为主服务器已经下线状态的sentinel的数量（包括自己），超过sentinel配置中设置的quorum参数的值，那么该sentinel就任务主服务器已经进入客观下线。

// quorum 参数设置
sentinel monitor master 127.0.0.1 6379 2

不同的sentinel判断客观下线的条件也可能不同。

3.3 领头sentinel的选举

选举规则：

• 监视同一个主服务器的任意一个sentinel都有可能成为领头sentinel。
• 每次选举完领头sentinel后。不论选举是否成功，所有sentinel的配置纪元会自增1。配置纪元实际上就是个计数器，没什么特别的；
• 在一个配置纪元里，所有的sentinel都有一次能将某个sentinel设置为局部领头sentinel的机会，且机会只有一次，先到先得。
• 如果在给定时间内，没有一个sentinel被选为领头sentinel，那么各个sentinel会在一段时间后，再次进行选举。配置纪元就是选举的任期。

选举流程：

• 当一个sentinel（源sentinel）向另一个sentinel（目标sentinel）发送 SENTINEL is-master-down-by-addr 命令，并且命令中的参数不是*，而是自己的run_id，表示源sentinel要求目标sentinel将自己设置为它的局部领头sentinel。
• 目标sentinel在收到SENTINEL is-master-down-by-addr 命令后，回复中的leader_runid 参数和leader_epoch 参数分别记录自己的局部领头sentinel的运行ID和配置纪元；
• 源sentinel在收到消息后，检查leader_epoch 是不是和自己的配置纪元一致，如果一致，取出 leader_runid 与自己的 run_id 比较，如果一致，表示目标sentinel 同意选自己为局部领头sentinel，如果不一致，说明目标sentinel已经选别的sentinel为局部领头sentinel了
• 如果某个sentinel被半数以上的sentinel设置为局部领头sentinel，那么这个局部领头sentinel就称为领头sentinel。

3.4 从库选主和故障转移

在选举产生领头sentinel后，领头的sentinel将对已下线的主服务器执行故障转移操作，该操作分为三步：

1. 在已下线的主服务器属下的从服务器里选一个服务器，将其转为主服务器（SLAVEOF no one）
2. 让其他从服务器改复制新的主服务器
3. 将已下线的主服务器设置为新的主服务器的从服务器，当旧的主服务器重新上线时就会称为新的主服务器的从服务器。

在发送SLAVEOF no one命令后，领头的sentinel会以每秒一次的频率发送INFO，检查角色（role）信息，直至变为master，就顺利将从服务器升级为主服务器了。

修改从服务器的复制目标
slaveof 让从服务器复制新的额主服务器。

四、哨兵模式源码分析

sentinelState 定义：

/* Main state. */
struct sentinelState {char myid[CONFIG_RUN_ID_SIZE+1]; /* 哨兵的id */uint64_t current_epoch;         /* 当前纪元，用来实现故障转移 */dict *masters;      // 记录所有被哨兵监视的主服务器的信息，字典的键是主服务器的名字，值是该服务器对应的sentinelRedisInstance服务器实例int tilt;           /*是否进入到tilt模式 */int running_scripts;    /* 当前运行的脚本的数量*/mstime_t tilt_start_time;       /* 进入tilt的时间 */mstime_t previous_time;         /* 最后一次执行时间处理器的时间 */list *scripts_queue;            /* 保存用户所有要运行的脚本*/char *announce_ip;  /* 如果不为NULL，表示与其他sentinel通信的ip地址*/int announce_port;  /* 如果不为0，表示与其他sentinel通信的port端口 */unsigned long simfailure_flags; /*simulation 失败标志 */int deny_scripts_reconfig;  // 是否允许sentinel在运行时通过set xx改变脚本的路径// auth 命令使用的用户名和密码，用于验证char *sentinel_auth_pass;    /* Password to use for AUTH against other sentinel */char *sentinel_auth_user;    /* Username for ACLs AUTH against other sentinel. */// 支持域名，前提是设置好DNSint resolve_hostnames;       /* Support use of hostnames, assuming DNS is well configured. */int announce_hostnames;      /* Announce hostnames instead of IPs when we have them. */
} sentinel;

4.1 什么是TILT？

TITL：因为sentinel依赖本机时间驱动，如果系统时间出问题，或者因为进程阻塞导致的时间函数延迟调用。这时再去参与集群逻辑会出现不正确的决策。因此如果当前时间和上一次执行时间差为负值或者超过2s，该节点会进入TILT模式。

4.2 sentinelRedisInstance结构定义：

每一个sentinelRedisInstance表示一个被sentinel监视的Redis服务器实例。这个实例可以使主服务器、从服务器或者另一个sentinel实例。

typedef struct sentinelRedisInstance {// 标识值，记录了实例的类型，以及该实例的当前状态 在sentinel进行故障转移时用到，int flags;      /* See SRI_... defines */// 实例的名字// 主服务器的名字由用户在配置文件中设置// 从服务器以及 Sentinel 的名字由 Sentinel 自动设置// 格式为 ip:port ，例如 "127.0.0.1:26379"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;  /* 配置纪元，用于实现故障转移 */sentinelAddr *addr; /* 实例的地址 ip+port*/// 连接状态描述instanceLink *link; /* Link to the instance, may be shared for Sentinels. */// 最后一次通过发布、订阅频道发送问候信息的时间mstime_t last_pub_time;   /* Last time we sent hello via Pub/Sub. */// 最后一次从这个sentinel的发布订阅频道收到问候信息的时间。只有当设置了SRI_SENTINEL才会使用mstime_t last_hello_time; /* Only used if SRI_SENTINEL is set. Last timewe received a hello from this Sentinelvia Pub/Sub. */// 最后一次恢复 is-master-down 命令的时间mstime_t last_master_down_reply_time; /* Time of last reply toSENTINEL is-master-down command. */// mstime_t s_down_since_time; /* 主观下线时间. */mstime_t o_down_since_time; /* 客观下线时间. */mstime_t down_after_period; /* 实例多少毫秒没有响应会被判定为主观下线 */// 从实例获取INFO命令回复的时间mstime_t info_refresh;  /* Time at which we received INFO output from it. */dict *renamed_commands;     /* Commands renamed in this instance:Sentinel will use the alternative commandsmapped on this table to send things likeSLAVEOF, CONFING, INFO, ... *//* Role and the first time we observed it.* This is useful in order to delay replacing what the instance reports* with our own configuration. We need to always wait some time in order* to give a chance to the leader to report the new configuration before* we do silly things. */// 实例的角色int role_reported;mstime_t role_reported_time;// 从服务器的主服务器地址最后一次变更的时间mstime_t slave_conf_change_time; /* Last time slave master addr changed. *//* Master specific. */dict *sentinels;    /* 监视了同一个主服务的其他sentinel */// 如果该服务器时主服务器，则slaves保存该主服务下面所有的从服务器dict *slaves;       /* Slaves for this master instance. *///判断这个实例为客观下线所需的支持投票数量unsigned int quorum;/* Number of sentinels that need to agree on failure. */// 在执行故障转移时，可以同时对新的主服务器进行同步的从服务器数量int parallel_syncs; /* How many slaves to reconfigure at same time. */// 主从复制的用户和密码校验char *auth_pass;    /* Password to use for AUTH against master & replica. */char *auth_user;    /* Username for ACLs AUTH against master & replica. *//* Slave specific. */// 主从复制断开的时间mstime_t master_link_down_time; /* Slave replication link down time. */// 从服务器的优先级int slave_priority; /* Slave priority according to its INFO output. */int replica_announced; /* Replica announcing according to its INFO output. */// 执行故障转移操作时，从服务器发送 SLAVEOF  命令的时间mstime_t slave_reconf_sent_time; /* Time at which we sent SLAVE OF  */// 如果该实例是从服务器，则master保存它的主服务器的实例地址struct sentinelRedisInstance *master; /* Master instance if it's slave. */// INFO 命令的回复中记录的主服务器 IP 和 PORTchar *slave_master_host;    /* Master host as reported by INFO */int slave_master_port;      /* Master port as reported by INFO */// INFO 命令中回复的主服务的连接状态int slave_master_link_status; /* Master link status as reported by INFO */// 从服务器的复制偏移量unsigned long long slave_repl_offset; /* Slave replication offset. *//* Failover */// 如果这是一个主服务器实例，那么 leader 将是负责进行故障转移的 Sentinel 的运行 ID 。// 如果这是一个 Sentinel 实例，那么 leader 就是被选举出来的领头 Sentinel 。// 这个域只在 Sentinel 实例的 flags 属性的 SRI_MASTER_DOWN 标志处于打开状态时才有效。char *leader;       /* If this is a master instance, this is the runid ofthe Sentinel that should perform the failover. Ifthis is a Sentinel, this is the runid of the Sentinelthat this Sentinel voted as leader. */// 领头的纪元uint64_t leader_epoch; /* Epoch of the 'leader' field. */// 当前执行中的故障转移的纪元uint64_t failover_epoch; /* Epoch of the currently started failover. */// 故障转移操作的当前状态int failover_state; /* See SENTINEL_FAILOVER_STATE_* defines. */// 故障改变的时间mstime_t failover_state_change_time;// 最后一次故障转移的时间mstime_t failover_start_time;   /* Last failover attempt start time. */// SENTINEL failover-timeout   选项的值// 刷新故障迁移状态的最大时限mstime_t failover_timeout;      /* Max time to refresh failover state. */mstime_t failover_delay_logged; /* For what failover_start_time value welogged the failover delay. */// 指向被提升为新主服务器的从服务器的指针struct sentinelRedisInstance *promoted_slave; /* Promoted slave instance. *//* Scripts executed to notify admin or reconfigure clients: when they* are set to NULL no script is executed. */char *notification_script;char *client_reconfig_script;sds info; /* cached INFO output */
} sentinelRedisInstance;