Redis高可用之哨兵模式（第二部分）_keepalived + redis 哨兵模式

引言

接上一篇，今天我们来聊一聊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},
	...
};

1
2
3
4
5
6
7
8
9

二、如何使用哨兵模式

2.1 启动哨兵模式

使用命令启动sentinel

redis-sentinel /path/sentinel.conf

redis-server /path/sentinel.conf --sentinel
1
2
3

假设有如下配置文件：表示该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
1
2
3
4
5
6
7
8
9
10
11
12
13
14

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
...
1
2
3
4
5
6
7
8
9
10
11

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

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

PUBLISH __sentinel:hello "<s_ip>,<s_port>,<s_run_id>,<s_epoch>,<m_name>,<m_ip>,<m_port>,<m_epoch>"
1

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

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

SUBSCRIBE _sentinel:hello
1

也就是说监视了同一主服务器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
1
2

这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 <ip> <port> <current_epoch> <run_id>
1

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

// quorum 参数设置
sentinel monitor master 127.0.0.1 6379 2
1
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 <new_master_ip> <new_master_port> 让从服务器复制新的额主服务器。

四、哨兵模式源码分析

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. */
    // 支持域名，前提是设置好DNS
    int resolve_hostnames;       /* Support use of hostnames, assuming DNS is well configured. */
    int announce_hostnames;      /* Announce hostnames instead of IPs when we have them. */
} sentinel;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

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 time
                                 we received a hello from this Sentinel
                                 via Pub/Sub. */
    // 最后一次恢复 is-master-down 命令的时间
    mstime_t last_master_down_reply_time; /* Time of last reply to
                                             SENTINEL 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 commands
                                   mapped on this table to send things like
                                   SLAVEOF, 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 <new-master> 命令的时间
    mstime_t slave_reconf_sent_time; /* Time at which we sent SLAVE OF <new> */
    // 如果该实例是从服务器，则master保存它的主服务器的实例地址
    struct sentinelRedisInstance *master; /* Master instance if it's slave. */
    // INFO 命令的回复中记录的主服务器 IP 和 PORT
    char *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 of
                           the Sentinel that should perform the failover. If
                           this is a Sentinel, this is the runid of the Sentinel
                           that 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 <master-name> <ms> 选项的值
	// 刷新故障迁移状态的最大时限
    mstime_t failover_timeout;      /* Max time to refresh failover state. */
    
    mstime_t failover_delay_logged; /* For what failover_start_time value we
                                       logged 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;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111

推荐一个零声学院免费教程，个人觉得老师讲得不错，
分享给大家：[Linux，Nginx，ZeroMQ，MySQL，Redis，
fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，
TCP/IP，协程，DPDK等技术内容，点击立即学习: