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

发布时间：2025-11-04 20:17:59 来源：云智核 作者：域名

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

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

当前哨兵主观认定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的主观判断结果:

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

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

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

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

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

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

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

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

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

(1) 选举源码入口

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

(2) 确认故障转移

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

如果伤处条件都排除则：

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

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

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

(4) 对端哨兵处理发起选举的投票结果

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

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

(5) 处理投票结果

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

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

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

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

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

小结

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

相关文章