禅与计算机
sharkchili
2024-07-16
目录

聊聊Redis哨兵选举与故障转移的实现

# 写在文章开头

上一篇文章我们将哨兵主观下线的核心流程都分析完成，这一篇我们将接着之前的思路，将哨兵获取客观下线结果并结合raft协议完成哨兵leader选举完成故障转移的流程分析完成，希望对你有帮助。

Hi，我是 sharkChili ，是个不断在硬核技术上作死的技术人，是 CSDN的博客专家 ，也是开源项目 Java Guide 的维护者之一，熟悉 Java 也会一点 Go ，偶尔也会在 C源码 边缘徘徊。写过很多有意思的技术博客，也还在研究并输出技术的路上，希望我的文章对你有帮助，非常欢迎你关注我的公众号： 写代码的SharkChili 。

同时也非常欢迎你star我的开源项目mini-redis:https://github.com/shark-ctrl/mini-redis (opens new window)

因为近期收到很多读者的私信，所以也专门创建了一个交流群，感兴趣的读者可以通过上方的公众号获取笔者的联系方式完成好友添加，点击备注 “加群” 即可和笔者和笔者的朋友们进行深入交流。

# 详解哨兵选举与故障转移流程

# 获取客观下线结果判断

当前哨兵主观认定master下线之后，为了明确知晓master节点是否真的下线，哨兵节点还会通过cc即异步命令指针所维护的socket连接发起is-master-down-by-addr的sentinel指令进行询问，其他哨兵所回复的结果都会通过回调函数sentinelReceiveIsMasterDownReply函数处理。

这段请求最终会被其他哨兵sentinel命令所对应的函数sentinelCommand执行，他们各自会在内部查看自己对于master判断是否是主观下线，如果是则返回1。

最后我们的哨兵收到这个结果1，则通过位运算加master节点状态flags类加上客观下线的判断标识64，这里redis为了提升运算效率，采用的二进制|=运算，这一点我们在阅读大量的redis中源码都会看到二进制运算这一点优化：

对此我们也给出哨兵处理每一个master实例的函数入口，可以看到在调用sentinelCheckSubjectivelyDown完成主观下线的检查之后，又会调用sentinelAskMasterStateToOtherSentinels并传入SENTINEL_NO_FLAGS即仅仅检查其他哨兵对于当前master的主观判断结果:

//这个入参包含恰哨兵实例和当前主节点的从节点信息
void sentinelHandleRedisInstance(sentinelRedisInstance *ri) {
   //......
    //3. 主观判断是否下线
    sentinelCheckSubjectivelyDown(ri);

   //......

    /* Only masters */
    if (ri->flags & SRI_MASTER) {
      
       //......
        //传入master信息ri以及标识SENTINEL_NO_FLAGS意味仅了解其他哨兵对于master节点状态的判断
        sentinelAskMasterStateToOtherSentinels(ri,SENTINEL_NO_FLAGS);
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

步入sentinelAskMasterStateToOtherSentinels即可看到哨兵询问其他哨兵对于master判断的逻辑，可以看到它遍历出每一个哨兵实例，通过异步连接cc指针所指向的连接发起SENTINEL is-master-down-by-addr指令获取其他哨兵节点对于master下线的看法，并注册sentinelReceiveIsMasterDownReply函数处理返回结果：

#define SENTINEL_ASK_FORCED (1<<0)
void sentinelAskMasterStateToOtherSentinels(sentinelRedisInstance *master, int flags) {
    dictIterator *di;
    dictEntry *de;

    di = dictGetIterator(master->sentinels);
    //遍历哨兵实例
    while((de = dictNext(di)) != NULL) {
        sentinelRedisInstance *ri = dictGetVal(de);
       	//......

        /* Ask */
        ll2string(port,sizeof(port),master->addr->port);
        //发送is-master-down-by-addr命令获取其他哨兵客观下线的结果，并通过sentinelReceiveIsMasterDownReply作为回调处理接收结果
        retval = redisAsyncCommand(ri->cc,
                    sentinelReceiveIsMasterDownReply, NULL,
                    "SENTINEL is-master-down-by-addr %s %s %llu %s",
                    master->addr->ip, port,
                    sentinel.current_epoch,
                    //若大于SENTINEL_FAILOVER_STATE_NONE则说明执行故障切换，传入server.runid  
                    (master->failover_state > SENTINEL_FAILOVER_STATE_NONE) ?
                    server.runid : "*");
        if (retval == REDIS_OK) ri->pending_commands++;
    }
    dictReleaseIterator(di);
}
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

其他哨兵收到sentinel指令后就会调用sentinelCommand处理这条指令，其内部会判断自己所维护的master的flags二进制位是否包含SRI_S_DOWN，如果是则说明被请求的哨兵节点同样认为master已下线，则直接回复master的leaderid以及shared.cone即1(代表确认当前master确实下线)：

void sentinelCommand(redisClient *c) {
    //......
    else if (!strcasecmp(c->argv[1]->ptr,"is-master-down-by-addr")) {//处理客观下线请求
        //......
       

       
        //如果master主观判定下线即flags包含SRI_S_DOWN这个主观下线标识，则isdown设置为1
        if (!sentinel.tilt && ri && (ri->flags & SRI_S_DOWN) &&
                                    (ri->flags & SRI_MASTER))
            isdown = 1;

        //上文isdown 设置为1，返回 shared.cone告知对应leaderid的master被我方认定为下线
        //响应3部分内容，下线状态、leader id以及当前leader的纪元
        addReplyMultiBulkLen(c,3);
        addReply(c, isdown ? shared.cone : shared.czero);
        addReplyBulkCString(c, leader ? leader : "*");
        addReplyLongLong(c, (long long)leader_epoch);
        if (leader) sdsfree(leader);
    } //......
    return;
//......
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

最终我们的sentinel的回调函数sentinelReceiveIsMasterDownReply处理对端的结果，发现返回值为1，说明该节点对于我们的来说客观认为master下线了。

所以我们的哨兵就需要记录这个消息，因为我们维护master->sentinels的字典记录其他哨兵信息，所以定位到其他哨兵客观下线的回复后，我们就会从这个字典中找到这个哨兵的结构体将其flags累加一个SRI_MASTER_DOWN的常数值64，意味这个哨兵客观认定这个master下线了：

void sentinelReceiveIsMasterDownReply(redisAsyncContext *c, void *reply, void *privdata) {
  //......


    if ( //......)
    {
    //更新上次响应时间
        ri->last_master_down_reply_time = mstime();
        if (r->element[0]->integer == 1) {//如果返回（cone默认设置为1）1则说明其他哨兵认为master下线，累加将当前维护的哨兵字段的flags累加SRI_MASTER_DOWN
            ri->flags |= SRI_MASTER_DOWN;
        } else {
           //......
        }
        //......
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

# 启动故障转移

上一步收集其他哨兵的判断并更新到各自的flags位后，当前哨兵的定时任务再次遍历master调用sentinelHandleRedisInstance处理当前master，其内部会遍历当前哨兵维护的哨兵数组获取这些哨兵对于master下线的看法，如果累加到的哨兵对于下线的看法大于或者等于我们配置quorum之后，则会判定会客观下线：

我们还是从sentinelHandleRedisInstance方法查看方法入口，可以看到哨兵定时执行该方法时会调用sentinelCheckObjectivelyDown检查客观下线状态：

void sentinelHandleRedisInstance(sentinelRedisInstance *ri) {
   //......
    if (ri->flags & SRI_MASTER) {
       //......
       //检查其当前是否客观下线
        sentinelCheckObjectivelyDown(ri);
        //......
    }
}
1
2
3
4
5
6
7
8
9

步入其内部即可看到笔者所说的，遍历哨兵查看下线结果并更新master下线状态的逻辑：

void sentinelCheckObjectivelyDown(sentinelRedisInstance *master) {
   //......
    //如果是主观下线，步入该逻辑
    if (master->flags & SRI_S_DOWN) {
        //自己的票数设置进去，quorum为1
        quorum = 1; /* the current sentinel. */
      
      
        //遍历其他哨兵，如果为客观下线则累加quorum
        di = dictGetIterator(master->sentinels);
        while((de = dictNext(di)) != NULL) {
            sentinelRedisInstance *ri = dictGetVal(de);

            if (ri->flags & SRI_MASTER_DOWN) quorum++;
        }
       //如果投票数大于配置的quorum，则odown 为1，即说明客观认定下线了
       
        if (quorum >= master->quorum) odown = 1;
    }

    //如果明确客观下线，则广播+odown事件
    if (odown) {
        if ((master->flags & SRI_O_DOWN) == 0) {
            sentinelEvent(REDIS_WARNING,"+odown",master,"%@ #quorum %d/%d",
                quorum, master->quorum);
         //累加标识，并更新master下线时间
            master->flags |= SRI_O_DOWN;
            master->o_down_since_time = mstime();
        }
    } else {
       //......
    }
}
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

# 发起新纪元leader选举

基于上述结果redis会判断是否发起故障转移，若需要则通知其他哨兵进行leader选举，收到通知的哨兵会检查当前纪元是否小于发起选举的哨兵纪元，若符合要求且在此期间没有别的哨兵发起选举，则向其投票。

后续我们的哨兵收到并收集这些响应之后，更新自己所维护的哨兵数组中的leader_epoch，通过遍历这个哨兵数组中的leader_epoch是否和自己所生成的leader_epoch一致，如果统计结果超过半数，则说明自己当选leader，由此开始进行故障转移：

# 选举源码入口

我们还是以sentinelHandleRedisInstance作为程序入口，可以看到其内部调用sentinelStartFailoverIfNeeded判断是否需要进行故障转移，然后调用sentinelAskMasterStateToOtherSentinels并传入SENTINEL_ASK_FORCED发起leader选举请求：

//这个入参包含恰哨兵实例和当前主节点的从节点信息
void sentinelHandleRedisInstance(sentinelRedisInstance *ri) {
   	//......
    if (ri->flags & SRI_MASTER) {
         	//......
        //  判断是否要进行故障切换，若需要则调用sentinelAskMasterStateToOtherSentinels传入SENTINEL_ASK_FORCED进行leader选举
        if (sentinelStartFailoverIfNeeded(ri))
            sentinelAskMasterStateToOtherSentinels(ri,SENTINEL_ASK_FORCED);
        // 执行故障切换
        sentinelFailoverStateMachine(ri);
       //......
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13

# 确认故障转移

我们步入sentinelStartFailoverIfNeeded即可看到其对于是否进行故障转移的判断，逻辑比较简单：

  1. 明确是否客观认定下线。
  2. 明确是否处于故障转移。
  3. 近期是否有进行故障转移。

如果伤处条件都排除则：

  1. failover_state 即故障转移状态设置为等待故障转移，后续的函数状态机会根据这个标识进行故障转移处理。
  2. flags标识累加处于故障转移中。
  3. 更新master纪元为哨兵纪元+1，用于后续哨兵leader选举后更新纪元使用。

对此我们给出sentinelStartFailoverIfNeeded的判断，可以看到它会按照上文所说的流程进行判断，明确排除三种情况后调用sentinelStartFailover设置故障转移状态：

int sentinelStartFailoverIfNeeded(sentinelRedisInstance *master) {
   //是否客观下线，若不是则返回0
    if (!(master->flags & SRI_O_DOWN)) return 0;

   //是否处于故障转移中，如果是则直接返回0
    if (master->flags & SRI_FAILOVER_IN_PROGRESS) return 0;

   
    //距离上次故障转移时间是否小于2倍的超时时间，如果是则返回0
    if (mstime() - master->failover_start_time <
        master->failover_timeout*2)
    {
        if (master->failover_delay_logged != master->failover_start_time) {
            time_t clock = (master->failover_start_time +
                            master->failover_timeout*2) / 1000;
            char ctimebuf[26];

            ctime_r(&clock,ctimebuf);
            ctimebuf[24] = '\0'; /* Remove newline. */
            master->failover_delay_logged = master->failover_start_time;
            redisLog(REDIS_WARNING,
                "Next failover delay: I will not start a failover before %s",
                ctimebuf);
        }
        return 0;
    }
    //启动故障转移 并返回1
    sentinelStartFailover(master);
    return 1;
}
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

步入sentinelStartFailover即可看到我们上文所说故障转移状态更新：

void sentinelStartFailover(sentinelRedisInstance *master) {
    redisAssert(master->flags & SRI_MASTER);
    //故障转移等待启动
    master->failover_state = SENTINEL_FAILOVER_STATE_WAIT_START;
    //设置为正在故障转移
    master->flags |= SRI_FAILOVER_IN_PROGRESS;
    //更新纪元
    master->failover_epoch = ++sentinel.current_epoch;
   //......
}
1
2
3
4
5
6
7
8
9
10

# 发起投票

结果上述步骤明确知晓redis需要进行故障转移之后，哨兵会再次调用sentinelAskMasterStateToOtherSentinels方法传入当前哨兵的server.runid向其他哨兵发起投票请求，并通过sentinelReceiveIsMasterDownReply处理响应结果：

void sentinelAskMasterStateToOtherSentinels(sentinelRedisInstance *master, int flags) {
   	//遍历其他哨兵
    di = dictGetIterator(master->sentinels);
    while((de = dictNext(di)) != NULL) {
     

      	//......
      	//因为failover_state 在上一步已经改为传入自己的SENTINEL_FAILOVER_STATE_WAIT_START即等待故障转移，故大于SENTINEL_FAILOVER_STATE_NONE，于是传入哨兵的server.runid发起投票选举
        retval = redisAsyncCommand(ri->cc,
                    sentinelReceiveIsMasterDownReply, NULL,
                    "SENTINEL is-master-down-by-addr %s %s %llu %s",
                    master->addr->ip, port,
                    sentinel.current_epoch,
                    //若大于SENTINEL_FAILOVER_STATE_NONE则说明执行故障切换，传入server.runid  
                    (master->failover_state > SENTINEL_FAILOVER_STATE_NONE) ?
                    server.runid : "*");
        if (retval == REDIS_OK) ri->pending_commands++;
    }
    dictReleaseIterator(di);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# 对端哨兵处理发起选举的投票结果

上述步骤发起投票的哨兵节点发起投票后，收到投票请求的哨兵实例就会进行如下检查：

  1. master纪元小于发起投票请求的哨兵纪元req_epoch。
  2. 当前哨兵纪元小于req_epoch。

如果符合要求则说明发起投票请求的哨兵可以作为leader，当前实例将leader 设置为该节点，然后回复结果给发送结果的实例：

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(REDIS_WARNING,"+new-epoch",master,"%llu",
            (unsigned long long) sentinel.current_epoch);
    }
    //如果master纪元小于发起选举的纪元且当前哨兵纪元小于等于发起选举的纪元
    if (master->leader_epoch < req_epoch && sentinel.current_epoch <= req_epoch)
    {
        sdsfree(master->leader);
        //设置当前的master为candidate的runid
        master->leader = sdsnew(req_runid);
        //更新纪元
        master->leader_epoch = sentinel.current_epoch;
        sentinelFlushConfig();
        //投票给发起选举的人
        sentinelEvent(REDIS_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,server.runid))
            master->failover_start_time = mstime()+rand()%SENTINEL_MAX_DESYNC;
    }

    *leader_epoch = master->leader_epoch;
    return master->leader ? sdsnew(master->leader) : NULL;
}
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

# 处理投票结果

收到响应后sentinelReceiveIsMasterDownReply回调函数就会解析出其他哨兵的leader_epoch 信息，作为后续选举leader的依据，如果半数以上的leader_epoch 为当前哨兵所设置的run_id，则说明当前哨兵作为leader进行故障转移：

void sentinelReceiveIsMasterDownReply(redisAsyncContext *c, void *reply, void *privdata) {
    sentinelRedisInstance *ri = c->data;
    redisReply *r;
    REDIS_NOTUSED(privdata);

	   //......
        if (strcmp(r->element[1]->str,"*")) {//不为*则采集投票结果
           //......
           	//基于返回结果更新当前哨兵维护的哨兵数组中leader的leader_epoch 信息(记录的是作为leader的哨兵的run_id)，作为后续选举leader使用
            ri->leader = sdsnew(r->element[1]->str);
            ri->leader_epoch = r->element[2]->integer;
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 选举出leader并广播通告

最后基于状态机模式，根据当前master状态为SENTINEL_FAILOVER_STATE_WAIT_START于是调用sentinelFailoverWaitStart选举leader

void sentinelFailoverStateMachine(sentinelRedisInstance *ri) {
    redisAssert(ri->flags & SRI_MASTER);

    if (!(ri->flags & SRI_FAILOVER_IN_PROGRESS)) return;

    switch(ri->failover_state) {
        //如果状态为SENTINEL_FAILOVER_STATE_WAIT_START，则调用sentinelFailoverWaitStart选举出leader
        case SENTINEL_FAILOVER_STATE_WAIT_START:
            sentinelFailoverWaitStart(ri);
            break;
       //......
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13

步入sentinelFailoverWaitStart即可看到该方法调用sentinelGetLeader，如果发现是自己则发送广播告知自己为leader进行故障转移：

void sentinelFailoverWaitStart(sentinelRedisInstance *ri) {
   //......
    //获取leader
    leader = sentinelGetLeader(ri, ri->failover_epoch);
    isleader = leader && strcasecmp(leader,server.runid) == 0;
    sdsfree(leader);

    //......
    //告知当选的leader是自己
    sentinelEvent(REDIS_WARNING,"+elected-leader",ri,"%@");
    ri->failover_state = SENTINEL_FAILOVER_STATE_SELECT_SLAVE;
    ri->failover_state_change_time = mstime();
    sentinelEvent(REDIS_WARNING,"+failover-state-select-slave",ri,"%@");
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14

对此我们也给出选举哨兵leader的核心方法sentinelGetLeader，核心步骤为：

  1. 如果投票结果给出的leader值不为空(这个leader记录的是其他哨兵投票的实例的run_id)且纪元和当前选举纪元一致，则给对应的leader票数+1。
  2. 将这个投票结果存入counter这个字典中。
  3. 遍历counter如果这个值大于配置的quorum或哨兵的半数以上，则将其设置为winner，即最后的leader，由此让这个leader哨兵进行故障转移：

对应的我们也给出这段代码的实现：

char *sentinelGetLeader(sentinelRedisInstance *master, uint64_t epoch) {
  //......
  	//设置voters 为哨兵数+1
    voters = dictSize(master->sentinels)+1; /* All the other sentinels and me. */

 /* Count other sentinels votes */
    //根据纪元遍历其他哨兵的选票结果
    di = dictGetIterator(master->sentinels);
    while((de = dictNext(di)) != NULL) {
        sentinelRedisInstance *ri = dictGetVal(de);
        //如果其他哨兵投票的leader值不为空，且纪元和当前投票纪元一致，则给这个leader的对应的run_id对应的投票数做个自增
        if (ri->leader != NULL && ri->leader_epoch == sentinel.current_epoch)
            sentinelLeaderIncr(counters,ri->leader);
    }

//......
//找到得票最多的
    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);

   //......
   
   //如果票数大于一半+1或大于配置的quorum则设置为leader
    voters_quorum = voters/2+1;
    if (winner && (max_votes < voters_quorum || max_votes < master->quorum))
        winner = NULL;

    winner = winner ? sdsnew(winner) : NULL;
    //......
    return winner;
}
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

# 小结

自此我们来小结一下哨兵选举与故障转移的大体过程：

  1. 当前哨兵主观认定下线之后，通过异步连接询问其它哨兵是否客观认定master下线。
  2. 超过半数的哨兵认为下线则当前哨兵就认为master下线于是开启发起投票选举。
  3. 更新自己的纪元并携带runid到其它哨兵节点上拉票。
  4. 基于回调函数获取其它哨兵选票结果进行遍历汇总，用以一个字典以哨兵runid为key，投票值为value进行维护。
  5. 汇总后通知全局哨兵leader。
  6. leader进行故障转移。

我是 sharkchili ，CSDN Java 领域博客专家，mini-redis的作者，我想写一些有意思的东西，希望对你有帮助，如果你想实时收到我写的硬核的文章也欢迎你关注我的公众号： 写代码的SharkChili 。

同时也非常欢迎你star我的开源项目mini-redis:https://github.com/shark-ctrl/mini-redis (opens new window)

因为近期收到很多读者的私信，所以也专门创建了一个交流群，感兴趣的读者可以通过上方的公众号获取笔者的联系方式完成好友添加，点击备注 “加群” 即可和笔者和笔者的朋友们进行深入交流。

# 参考

strcasecmp()函数 :https://blog.csdn.net/weixin_43322104/article/details/118516388 (opens new window)

编辑 (opens new window)
上次更新: 2026/03/26, 01:05:31
Redis哨兵是如何完成初始化的
来聊聊Redis哨兵如何主观认定下线

← 来聊聊Redis哨兵如何主观认定下线→

最近更新
01
基于EasyExcel实现高效导出
03-25
02
从开源框架中学习那些实用的位运算技巧
03-25
03
浅谈分布式架构设计思想和常见优化手段
03-25
更多文章>
Theme by Vdoing | Copyright © 2025-2026 Evan Xu | MIT License | 桂ICP备2024034950号 | 桂公网安备45142202000030
×
×