文章目录
- 前言
- 一、快速开始
- 1.配置
- 2.启动
- 3.故障转移
- 二、原理
- 1.主流程
- 1.1 哨兵工作入口:
- 1.2 任督二脉
- 2.监视
- 2.1 主观下线
- 2.2 客观下线
- 3.哨兵Leader
- 4.故障转移
- 总结
前言
本文参考源码版本为
redis6.2
哨兵是啥?站岗、放哨、巡逻之人,这种模式在生活中也十分常见,军队、安保、押运等等,都需要时刻注意周边异样,并及时作出响应。
redis 哨兵也是如此。前面文章我们分析了 redis 副本机制,本质就是多个数据副本,为防止单副本故障而生。
在 redis 服务遇到故障崩溃时,我们可以通过切换副本节点对外提供服务,你可以写一些脚本,做到一键切换,十分方便;前提是,需要人为判断是否需要故障切换,在工作时间遇到可能还能忍受,要是凌晨两三点呢?
所以,我们可以选择更加智能一些,比如,你想继续写一个自动检测故障的脚本,当检查到 redis 故障时,直接切换从节点顶上就OK了;没错,思路是这样,不过,路子有点野。
有广大需求,肯定就会有人身先士卒,把它做成工具,然后你直接拿来用即可。本文的主角,redis 哨兵就登场了。
redis 哨兵,本质没有多神秘,按照上面思路,你我也能搞一套,关键是你需要花一些精力,还要不断验证它的鲁棒性,如果你还觉得OK,那可以试试咯。
好,回到正题,我们来聊聊 redis 哨兵,要做到自动切换,需要做哪些操作?
- 首先,需要探测到主从节点是否正常?redis 采用定期 PING 的方式。
- 当主节点故障,我们将从在线的从节点列表选择一个提升为主节点。
- 然后通知其他从节点,主节点已更新,需要连接到新主节点。
- 同时,我们还需要继续监听旧主节点,当其重新上线时,将其降级为从节点。
流程上是这样,不过还有些问题需要考虑。比如主节点实际正常在线,只不过主从节点间的网络出了问题,导致从节点一直无法 PING 通,导致从节点误判了?
为了避免单哨兵误判的情况出现,redis 提供了多哨兵支持,只要半数以上的哨兵节点都认为主节点下线了,才真正认为主节点下线,然后准备故障转移。
值得注意的是,在故障转移之前,我们需要先选择一个哨兵节点来完成这个工作。
一、快速开始
哨兵,本质也是一个 redis 服务,其启动方式都相似。我们先快速搭建 3 哨兵 + 1主 + 1从的集群来看看:
1.配置
首先从官网下载 redis,主节点使用默认配置,从节点则 copy 默认配置并修改端口为 6378,配置文件命名为 redis_6378.conf。
然后配置三个哨兵,配置文件分别命名为 sentinel.conf、sentinel2.conf、sentinel3.conf,其中 sentinel.conf 配置如下:
port 26379sentinel monitor mymaster 127.0.0.1 6379 2sentinel down-after-milliseconds mymaster 5000sentinel failover-timeout mymaster 60000sentinel parallel-syncs mymaster 1
另外哨兵的配置文件也类似,端口分别定义为 26380、26381。以上配置中, quorum = 2。
2.启动
首先,启动主节点:
然后启动从节点:
最后启动3个哨兵节点,在命令行分别执行:
➜ redis-sentinel sentinel.conf ➜ redis-sentinel sentinel2.conf ➜ redis-sentinel sentinel3.conf
效果如下:
我们通过命令 ps -ef | grep redis 来查看启动状态:
可以发现所有服务都已启动,我们随意进入一个哨兵节点,查看监控效果:
➜~ redis-cli -p 26379127.0.0.1:26379> SENTINEL master mymaster 1) "name" 2) "mymaster" 3) "ip" 4) "127.0.0.1" 5) "port" 6) "6379" 7) "runid" 8) "a749c4af7998c2330d0e31cc596b571b7d46d4d8" 9) "flags"10) "master"11) "link-pending-commands"12) "0"13) "link-refcount"14) "1"15) "last-ping-sent"16) "0"17) "last-ok-ping-reply"18) "739"19) "last-ping-reply"20) "739"21) "down-after-milliseconds"22) "60000"23) "info-refresh"24) "8197"25) "role-reported"26) "master"27) "role-reported-time"28) "299300"29) "config-epoch"30) "5"31) "num-slaves"32) "1"33) "num-other-sentinels"34) "3"35) "quorum"36) "2"37) "failover-timeout"38) "180000"39) "parallel-syncs"40) "1"
以上可以看到主节点信息。另外,你可以通过命令:
SENTINEL replicas mymasterSENTINEL sentinels mymaster
分别查看 从节点信息、其他哨兵信息等。
3.故障转移
模拟主节点故障,命令行输入:
➜~ redis-cli -p 6379 DEBUG sleep 70OK
通过上图,我们可以看到完整的故障转移过程。另外,上图也是被选举为哨兵leader 的节点。
然后我们查看主节点信息是否切换:
➜~ redis-cli -p 26379127.0.0.1:26379> SENTINEL master mymaster 1) "name" 2) "mymaster" 3) "ip" 4) "127.0.0.1" 5) "port" 6) "6378" 7) "runid" 8) "2ae9dd98368bcc17c3b679f424a716a84f62bfb5" 9) "flags"10) "master"11) "link-pending-commands"
可以发现主节点已经变成了 127.0.0.1:6378,即 已经完成了切换。
二、原理
我们先来看看,redis 哨兵主要做了哪些工作?在此之前,先看看它会监听哪些节点
:
首先,哨兵的主要职责是保障 redis 服务能正常对外提供服务。因此,肯定是要监听 redis 主节点的在线状态。
其次,当主节点挂掉之后,需要进行故障转移,也就是需要知道所有从节点的信息。因此,哨兵的第二项职责便是监听从节点的状态。
另外,前面部分提到,单哨兵可能并不是那么健壮,我们一般需要搞一个哨兵集群。因此,第三项职责便是哨兵节点间的沟通交流。
简单来说,我们从一个哨兵的角度来看,其会保持与下面三类节点的交流,如下图:
当然,监听节点的目的是为了获取信息,对这些信息进一步处理并采取相应的行动才是目的:
- 哨兵集群信息沟通交流
- master 节点下线判断
- 哨兵集群 leader 选举
- 哨兵 leader 执行故障转移
- 通知客户端,master – slave 变更信息
正常监听是这样:
当 master 节点出现故障,哨兵集群执行故障转移后,变成了这样:
值得注意的是,原 master 节点下线后,哨兵也会持续监听,当其重新上线后,将其处理为新的从节点。
1.主流程
1.1 哨兵工作入口:
哨兵工作的主要工作在前面部分基本已经介绍过了,接下来我们继续看看这些工作是如何串联起里的。
入口方法:server.c#serverCron 中 的 sentinelTimer
方法。我们来看看哨兵相关主干逻辑:
// sentinel.c#sentinelHandleRedisInstance()void sentinelHandleRedisInstance(sentinelRedisInstance *ri) {// 主要维护与 master、slave 以及其他 sentinel 之间的连接信息sentinelReconnectInstance(ri);// 周期性操作:PING、INFO 以及 PUBLISHsentinelSendPeriodicCommands(ri);...// 哨兵主观下线判断sentinelCheckSubjectivelyDown(ri);/* Masters and slaves */if (ri->flags & (SRI_MASTER|SRI_SLAVE)) {/* Nothing so far. */}/* Only masters */// 如果维护的是与master节点的连接if (ri->flags & SRI_MASTER) {// 哨兵进行客观下线判断sentinelCheckObjectivelyDown(ri);// 是否需要故障转移if (sentinelStartFailoverIfNeeded(ri))// 尝试选出哨兵leadersentinelAskMasterStateToOtherSentinels(ri,SENTINEL_ASK_FORCED);// 哨兵故障转移状态机(执行故障转移)sentinelFailoverStateMachine(ri);// 故障转移完成后,做一些清理操作sentinelAskMasterStateToOtherSentinels(ri,SENTINEL_NO_FLAGS);}}
可以看到 redis 哨兵主干逻辑在处理:
- 与其他节点维护连接信息
- 与其他节点保持连接信息(PING)
- 哨兵主观下线判断
如果监控的是主节点,那将进一步处理:
- 哨兵客观下线判断
- 是否需要故障转移,如果需要,则选出哨兵 leader,由 leader 来完成故障转移
- 哨兵 leader 执行故障转移,这个过程有多阶段,这里使用状态机来处理。
- 故障转移之后,做一些清理工作(比如 flag)
值得注意的是,当前哨兵监听的所有节点,都会执行 sentinelCheckSubjectivelyDown
方法,也就是主观判断节点是否下线,如果下线了就更新 flag。
1.2 任督二脉
哨兵,本质也是一个 redis 服务,既能接收请求又能定期监视相关节点,这是如何做到的?
我们知道,事件是贯穿 redis 的核心机制,客户端发来的请求封装为文件事件
,另外还有一些后台周期性的任务封装为时间事件
。
哨兵的工作过程号称是异步
的,比如发出 PING 之后不需要等待响应,而是当响应到来时,通过回调函数来继续处理。哨兵的异步操作是如何实现的?
哨兵在启动时会创建相关连接,并将对应已连接的 fd 向操作系统内核注册,当有请求到来时,和一般的 redis 请求类似,服务正常处理请求即可。
在哨兵主动发起通信时,主要借助于客户端工具 hiredis,其封装了 RESP 通信协议,发送请求时,这个过程不必等待结果返回,因此,异步体现在这里。
我画了张图,大概是这样:
值得注意的是,redis 哨兵的异步过程是与主线程轮训(事件)紧密相连。
2.监视
俗话说,一个人的判断具有具有主观色彩,三人成众,便是代表了大众;redis 哨兵集群也是如此,通过全员投票模式,半数以上哨兵认为主节点下线了,就代表了大众,可以执行故障转移。
2.1 主观下线
从单个哨兵节点的角度来看,当其对 master 节点进行单方面的检测发现已经离线了,有主观性质在里面,也叫主观下线
。
主观下线条件:
- PING 相关:指定参数 down-after-milliseconds 时长没有正常响应则视为下线
- INFO 相关:从 master 角色切换到 slave 角色也认为是下线
主观下线相关逻辑:
void sentinelCheckSubjectivelyDown(sentinelRedisInstance *ri) {.../* Update the SDOWN flag. We believe the instance is SDOWN if: * * 1) It is not replying. * 2) We believe it is a master, it reports to be a slave for enough time *to meet the down_after_period, plus enough time to get two times *INFO report from the instance. */if (elapsed > ri->down_after_period ||(ri->flags & SRI_MASTER && ri->role_reported == SRI_SLAVE && mstime() - ri->role_reported_time >(ri->down_after_period+SENTINEL_INFO_PERIOD*2))){/* Is subjectively down */if ((ri->flags & SRI_S_DOWN) == 0) {sentinelEvent(LL_WARNING,"+sdown",ri,"%@");ri->s_down_since_time = mstime();ri->flags |= SRI_S_DOWN;}} ... }
2.2 客观下线
当我们需要判断主节点是否真正下线时,是需要做到尽可能公平公正的判断。这时候,群众投票,就是不错的选择,这种方式便是客观下线
的判断依据。
redis 提供了变量 quorum 来控制,quorum 有两层含义:
- 客观下线判断条件:只有哨兵主观下线 >= quorum 才认为客观下线
- 哨兵 leader 选举:投票半数以上 + 大于等于 quorum 两个条件
客观下线相关逻辑:
void sentinelCheckObjectivelyDown(sentinelRedisInstance *master) {...if (master->flags & SRI_S_DOWN) {quorum = 1; /* the current sentinel. *//* Count all the other sentinels. */di = dictGetIterator(master->sentinels);while((de = dictNext(di)) != NULL) {sentinelRedisInstance *ri = dictGetVal(de);if (ri->flags & SRI_MASTER_DOWN) quorum++;}dictReleaseIterator(di);// 如果大于指定参数,则客观下线if (quorum >= master->quorum) odown = 1;}...}
哨兵 leader 选举相关逻辑:
char *sentinelGetLeader(sentinelRedisInstance *master, uint64_t epoch) {.../* Check what's the winner. For the winner to win, it needs two conditions: * 1) Absolute majority between voters (50% + 1). * 2) And anyway at least master->quorum votes. */di = dictGetIterator(counters);while((de = dictNext(di)) != NULL) {uint64_t votes = dictGetUnsignedIntegerVal(de);if (votes > max_votes) {max_votes = votes;winner = dictGetKey(de);}}dictReleaseIterator(di);/* Count this Sentinel vote: * if this Sentinel did not voted yet, either vote for the most * common voted sentinel, or for itself if no vote exists at all. */if (winner)myvote = sentinelVoteLeader(master,epoch,winner,&leader_epoch);elsemyvote = sentinelVoteLeader(master,epoch,sentinel.myid,&leader_epoch);if (myvote && leader_epoch == epoch) {uint64_t votes = sentinelLeaderIncr(counters,myvote);if (votes > max_votes) {max_votes = votes;winner = myvote;}}voters_quorum = voters/2+1;if (winner && (max_votes < voters_quorum || max_votes < master->quorum))winner = NULL;...}
综上,客观下线判断、哨兵 leader 选举都与 quorum 参数有关,因此,设置合适的 quorum 参数十分重要;
另外哨兵 leader 选举还有半数以上哨兵投票的限制,因此通常采用奇数个哨兵节点比较合理。
3.哨兵Leader
哨兵集群一般包含多个,而执行故障转移这个过程只需一个哨兵节点即可,那究竟由谁来真正执行故障转移?
redis 采用的是投票
的方式,在主节点进入客观下线状后,哨兵会向哨兵集群其他节点发送以下命令来赢得投票:
SENTINEL IS-MASTER-DOWN-BY-ADDR <ip> <port> <current-epoch> <runid>
哨兵接收请求入口:sentinel.c#sentinelCommand(),然后具体哨兵 leader 选举逻辑可以定位到:
// sentinel.c#sentinelVoteLeader()char *sentinelVoteLeader(sentinelRedisInstance *master, uint64_t req_epoch, char *req_runid, uint64_t *leader_epoch) {if (req_epoch > sentinel.current_epoch) {sentinel.current_epoch = req_epoch;sentinelFlushConfig();sentinelEvent(LL_WARNING,"+new-epoch",master,"%llu",(unsigned long long) sentinel.current_epoch);}if (master->leader_epoch < req_epoch && sentinel.current_epoch <= req_epoch){sdsfree(master->leader);master->leader = sdsnew(req_runid);master->leader_epoch = sentinel.current_epoch;sentinelFlushConfig();sentinelEvent(LL_WARNING,"+vote-for-leader",master,"%s %llu",master->leader, (unsigned long long) master->leader_epoch);/* If we did not voted for ourselves, set the master failover start * time to now, in order to force a delay before we can start a * failover for the same master. */if (strcasecmp(master->leader,sentinel.myid))master->failover_start_time = mstime()+rand()%SENTINEL_MAX_DESYNC;}*leader_epoch = master->leader_epoch;return master->leader " />sdsnew(master->leader) : NULL;}
首先,所有在线的 Sentinel 都有被选为哨兵 leader
的资格。
其次,每次进行哨兵 leader 选举之后,不论选举是否成功,所有 Sentinel 的配置纪元(epoch)的值都会自增一次。配置纪元实际上就是一个计数器,并没有什么特别的。
在一个配置纪元里面,所有 Sentinel 都有一次将某个 Sentinel 设置为局部哨兵 leader 的机会,并且局部 leader 一旦设置,在这个配置纪元里面就不能再更改。
每个发现主服务器进入客观下线的 Sentinel 都会要求其 他Sentinel 将自己设置为局部哨兵 leader。
当主节点客观下线后,哨兵 leader 选举规则
如下:
- 当一个Sentinel(源Sentinel)向另一个 Sentinel(目标Sentinel)发送 SENTINEL is-master-down-by-addr 命令,并且命令中的 runid 参数不是 * 符号而是源 Sentinel 的运行ID时,这表示源 Sentinel 要求目标 Sentinel 将前者设置为后者的
局部
哨兵 leader。 - Sentinel 设置局部哨兵 leader 的规则是
先到先得
:最先向目标 Sentinel 发送设置要求的源Sentinel 将成为目标 Sentinel 的局部哨兵 leader,而之后接收到的所有设置要求都会被目标Sentinel 拒绝。 - 目标 Sentinel 在接收到 SENTINEL is-master-down-by-addr 命令之后,将向源 Sentinel 返回一条命令回复,回复中的 leader_runid 参数和 leader_epoch 参数分别记录了目标 Sentinel 的局部哨兵 leader 的运行 ID 和配置纪元。
- 源 Sentinel 在接收到目标 Sentinel 返回的命令回复之后,会检查回复中 leader_epoch 参数的值和自己的配置纪元是否相同,如果相同的话,那么源 Sentinel 继续取出回复中的 leader_runid 参数,如果 leader_runid 参数的值和源 Sentinel 的运行 ID 一致,那么表示目标Sentinel 将源 Sentinel 设置成了局部哨兵 leader。
- 如果有某个 Sentinel 被半数以上的 Sentinel 设置成了局部哨兵 leader,那么这个 Sentinel 成为哨兵 leader。
- 因为哨兵 leader 的产生需要半数以上 Sentinel 的支持,并且每个 Sentinel 在每个配置纪元里面只能设置一次局部哨兵 leader,所以在一个配置纪元里面,只会出现唯一的哨兵 leader。
- 如果在给定时限内,没有一个 Sentinel 被选举为哨兵 leader,那么各个 Sentinel 将在一段时间之后再次进行选举,直到选出领头 Sentinel 为止。
4.故障转移
故障转移本质要做的是,在从节点列表中选择一个作为新的主节点
,并通知其他从节点、客户端等。
故障转移通过状态机的形式呈现,大致做了这些事情:
// sentinel.c#sentinelFailoverStateMachine()void sentinelFailoverStateMachine(sentinelRedisInstance *ri) {serverAssert(ri->flags & SRI_MASTER);if (!(ri->flags & SRI_FAILOVER_IN_PROGRESS)) return;switch(ri->failover_state) {case SENTINEL_FAILOVER_STATE_WAIT_START:sentinelFailoverWaitStart(ri);break;case SENTINEL_FAILOVER_STATE_SELECT_SLAVE: // 执行新主节点选举sentinelFailoverSelectSlave(ri);break;case SENTINEL_FAILOVER_STATE_SEND_SLAVEOF_NOONE:sentinelFailoverSendSlaveOfNoOne(ri);break;case SENTINEL_FAILOVER_STATE_WAIT_PROMOTION:sentinelFailoverWaitPromotion(ri);break;case SENTINEL_FAILOVER_STATE_RECONF_SLAVES:sentinelFailoverReconfNextSlave(ri);break;}}
我们挑个重点的来看看,通常情况下,从节点有多个,我们改选择哪个来作为新的主节点呢?看看选举主节点的总体逻辑:
sentinelRedisInstance *sentinelSelectSlave(sentinelRedisInstance *master) {...di = dictGetIterator(master->slaves);while((de = dictNext(di)) != NULL) {sentinelRedisInstance *slave = dictGetVal(de);mstime_t info_validity_time;if (slave->flags & (SRI_S_DOWN|SRI_O_DOWN)) continue;if (slave->link->disconnected) continue;if (mstime() - slave->link->last_avail_time > SENTINEL_PING_PERIOD*5) continue;if (slave->slave_priority == 0) continue;/* If the master is in SDOWN state we get INFO for slaves every second. * Otherwise we get it with the usual period so we need to account for * a larger delay. */if (master->flags & SRI_S_DOWN)info_validity_time = SENTINEL_PING_PERIOD*5;elseinfo_validity_time = SENTINEL_INFO_PERIOD*3;if (mstime() - slave->info_refresh > info_validity_time) continue;if (slave->master_link_down_time > max_master_down_time) continue;instance[instances++] = slave;}dictReleaseIterator(di);if (instances) {qsort(instance,instances,sizeof(sentinelRedisInstance*),compareSlavesForPromotion);selected = instance[0];}zfree(instance);return selected;}
总结下新主节点选举规则如下:
- 删除列表中所有处于下线或者断线状态的从服务器,这可以保证列表中剩余的从服务器都是正常在线的。
- 删除列表中所有最近五秒内没有回复过哨兵 leader 的 INFO 命令的从服务器,这可以保证列表中剩余的从服务器都是最近成功进行过通信的。
- 删除所有与已下线主服务器连接断开超过down-after-milliseconds*10毫秒的从服务器。即,列表中剩余的从服务器保存的数据都是比较新的。
- 然后,哨兵 leader 将根据从服务器的优先级,对列表中剩余的从服务器进行排序,并选出其中优先级最高的从服务器。
- 如果有多个具有相同最高优先级的从服务器,那么哨兵 leader 将按照从服务器的复制偏移量,对具有相同最高优先级的所有从服务器进行排序,并选出其中偏移量最大的从服务器(复制偏移量最大的从服务器就是保存着最新数据的从服务器)。
- 最后,如果有多个优先级最高、复制偏移量最大的从服务器,那么领头Sentinel将按照运行ID对这些从服务器进行排序,并选出其中运行 ID 最小的从服务器。
当选择出新主节点之后,然后向其他从节点发送以下命令,即连接到新主节点:
SLAVEOF new_masertip new_master_port
总结
哨兵,主从集群的监护者,其核心目的是能自动
完成故障转移。为防止单哨兵故障,一般选择使用哨兵集群,哨兵之间会自动发现对方。
从哨兵角度看,可以监视主节点、从节点,并且和其他哨兵节点保持通信。在监视过程中,单方面判断监视节点下线的叫主观下线,半数以上哨兵都认为下线的叫客观下线。
当主节点客观下线后,哨兵集群内部会协商选出一个哨兵 leader 来负责执行故障转移操作。当哨兵 leader 选出后,leader 便开始在从节点列表中选择一个合适的从节点作为新的主节点;然后将其他从节点关联到新的主节点。
另外,原主节点也要监视,当其重新上线时,会作为新主节点的从节点。
相关参考:
- redis 副本机制
- High availability with Redis Sentinel
- <> 「黄健宏」
- <>「陈雷」