前段時間寫過兩篇redis哨兵的文章,一篇是redis哨兵模式的搭建。另外一篇是redis哨兵主從切換的原理,。
當時寫的原理篇,是手動模擬主節點故障,然后查看主從切換的日志推算哨兵主從切換的流程。但是感覺這樣搞出來的流程太粗，忽略了很多細節，真正要搞明白原理，還是要看源碼才行。找時間學習了一下C語言的語法,然后梳理哨兵模式主從切換的相關源碼。研究了一段時間,算是把主流程基本搞懂了,今天把真正的原理篇補上。

直接進入正題。
redis故障轉移是由定時任務實現的。說到定時任務，就離不開serverCron方法，redis很多的定時任務邏輯都是在serverCron方法中實現的。在serverCron方法中有一段邏輯，調用了sentinelTimer方法。主從切換邏輯的入口就是這個sentinelTimer方法。源碼邏輯如下

//哨兵模式下,serverCron方法中會循環執行sentinelTimer方法，100ms一次。
if (server.sentinel_mode) sentinelTimer();

sentinelTimer方法中包含了從哨兵發現主節點下線，哨兵選主，以及最終完成主從切換的一系列流程。我把這些流程進行了分類，整理出了下面的目錄。

按照這個目錄結構，我們聊一下主從切換的流程

1、哨兵發現主節點客觀下線

首先是哨兵發現主節點下線。
進入sentinelTimer方法，先是判斷redis哨兵是否進入了TILT模式。如果未進入，會執行一個sentinelHandleDictOfRedisInstances(sentinel.masters)方法，方法入參是sentinel.masters，這個入參是：當前哨兵監聽的所有主節點
我們進入sentinelHandleDictOfRedisInstances方法里，可以看到一個循環，從sentinel.masters哈希表中挨個獲取主節點，
然后執行sentinelHandleRedisInstance方法，該方法有4個主要的邏輯。
1)、sentinelReconnectInstance(ri)方法。作用：如果哨兵和主節點斷連，重新建立與主節點的連接

2)、sentinelSendPeriodicCommands(ri)方法。作用：給主節點發送PING、INFO指令，PING主要是用來與主節點交互，確認其是否在線。INFO主要是用來獲取主節點或者從節點的信息

3)、sentinelCheckSubjectivelyDown(ri)方法。作用：判斷主節點是否客觀下線

4)、如果節點是主節點，還會繼續判斷是否執行哨兵選主以及故障切換等邏輯。
又分為3個小流程
a)、檢查主節點是否客觀下線
b)、詢問其他哨兵對于主節點下線的意見
c)、啟動故障切換
這3小步中，有一個狀態機的概念，很重要，提前說一下。狀態機，就是某個狀態對應著不同的操作，redis的主從切換是靠定時任務實現，這里面不可避免的就要涉及到狀態機。我們看一下redis的狀態機源碼實現：

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;}
}

邏輯寫的很清晰，這個狀態機里包含了故障轉移的主要流程。
說回sentinelHandleRedisInstance方法。
哨兵確定主節點是否主觀下線的邏輯是由sentinelHandleRedisInstance方法的4個步驟中的第二步和第三步共同實現的，我們分別看下。
sentinelSendPeriodicCommands方法的主要邏輯如下：

//給主節點和從節點發送INFO命令if ((ri->flags & SRI_SENTINEL) == 0 &&(ri->info_refresh == 0 ||(now - ri->info_refresh) > info_period)){retval = redisAsyncCommand(ri->link->cc,sentinelInfoReplyCallback, ri, "%s",sentinelInstanceMapCommand(ri,"INFO"));if (retval == C_OK) ri->link->pending_commands++;}
//給所有類型的節點發送PING命令if ((now - ri->link->last_pong_time) > ping_period &&(now - ri->link->last_ping_time) > ping_period/2) {sentinelSendPing(ri);}	

第二步做的事就是發送PING，然后記錄發送PING的時間、以及響應PONG的時間。
接下來，我們看第三步
sentinelCheckSubjectivelyDown，在這個方法中，就利用上面記錄的時間判斷主節點是否下線。
先計算一下上次收到PONG距離當前時間的時間差。如果哨兵和主節點已經斷連，則時間差就是上次主節點可用的時間距離當前時間的時間差。

//計算當前距離上一次發送PING命令的時長if (ri->link->act_ping_time)elapsed = mstime() - ri->link->act_ping_time;else if (ri->link->disconnected)//如果哨兵和主節點斷開了,計算當前距離連接最后可用的時長elapsed = mstime() - ri->link->last_avail_time;

拿到時間差了，緊接著就開始判斷時間差是否超過了設定值，如果超過了設定值，就認為主節點客觀下線

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)))//經過down_after_period時長+2個INFO命令的間隔后{/* 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;}}

判斷條件有兩個。一個是時間差是否大于sentinel.conf配置文件中配置的
down-after-milliseconds的值，此時會認定主節點已下線 另外一個是：如果主節點報告自己即將切換為從節點，但是過了down-after-milliseconds+兩個INFO命令的間隔后，依然沒有切換成功，此時也會認為主節點下線。
哨兵認為主節點客觀下線后，會給+sdown頻道發送一個消息，向外告知自己的發現。同時將主節點的flags字段記為宏 SRI_S_DOWN，這樣就代表，哨兵監聽的這個主節點客觀下線。

2、哨兵詢問其他哨兵對于主節點下線的意見，防止誤判

這一步的作用，是防止誤判。比如：哨兵自己的機器網絡不好，導致誤判了主節點下線。所以，發現主節點下線的哨兵需要給其他哨兵發送消息，詢問他們與主節點的連接情況。這部分邏輯在sentinelCheckObjectivelyDown(ri)中，在下面的邏輯中，在主節點的sentinels變量中獲取到監聽當前主節點的其他哨兵實例，之后獲取他們的flags變量，如果變量值為SRI_MASTER_DOWN，則將quorum值+1，最終的結果如果大于配置文件中配置的quorum值，此時會將odown值置為1，此時代表主節點客觀下線，代表主節點下線已經是一個客觀的事實。這部分邏輯如下：

void sentinelCheckObjectivelyDown(sentinelRedisInstance *master) {......if (master->flags & SRI_S_DOWN) {//獲取其他的哨兵節點di = dictGetIterator(master->sentinels);while((de = dictNext(di)) != NULL) {sentinelRedisInstance *ri = dictGetVal(de);//獲取哨兵節點中的flags標識。如果flags標識為SRI_MASTER_DOWN,此時quorum+1if (ri->flags & SRI_MASTER_DOWN) quorum++;}dictReleaseIterator(di);//如果quorum的值大于等于配置文件中配置的quorum的值時,odown的值設置為1,代表主節點客觀下線if (quorum >= master->quorum) odown = 1;}//odown值為1時,給+odown頻道發送消息，同時將主節點的flags變量標記為SRI_O_DOWN，主節點客觀下線if (odown) {if ((master->flags & SRI_O_DOWN) == 0) {//客觀下線,給+odown頻道發送消息sentinelEvent(LL_WARNING,"+odown",master,"%@ #quorum %d/%d",quorum, master->quorum);//主節點的flags標記為客觀下線master->flags |= SRI_O_DOWN;//記錄主節點的下線時間master->o_down_since_time = mstime();}}......
}

通過判斷SRI_MASTER_DOWN的值來判斷主節點客觀下線的情況。那其他哨兵節點的SRI_MASTER_DOWN變量是何時賦值的呢？
是在sentinelAskMasterStateToOtherSentinels方法中，該方法在sentinel.c文件中。首先獲取到其他監聽該主節點的哨兵節點集合，然后遍歷給這些哨兵節點發送is-master-down-by-addr命令。
回調方法是：sentinelReceiveIsMasterDownReply

void sentinelAskMasterStateToOtherSentinels(sentinelRedisInstance *master, int flags) {......di = dictGetIterator(master->sentinels);while((de = dictNext(di)) != NULL) {......retval = redisAsyncCommand(ri->link->cc,sentinelReceiveIsMasterDownReply, ri,"%s is-master-down-by-addr %s %s %llu %s",sentinelInstanceMapCommand(ri,"SENTINEL"),master->addr->ip, port,sentinel.current_epoch,(master->failover_state > SENTINEL_FAILOVER_STATE_NONE) ?sentinel.myid : "*");if (retval == C_OK) ri->link->pending_commands++;......}dictReleaseIterator(di);
}

處理is-master-down-by-addr命令的方法是sentinelCommand(client *c)。主要邏輯就是獲取哨兵節點中的主節點flags標識，是否是SRI_S_DOWN，這個標識是哨兵通過發送PING命令是否超時來賦值的，在前面哨兵判斷主節點主觀下線的部分已經說過了。如果flags標識是SRI_S_DOWN，就代表該哨兵認為主節點已下線，將判斷結果以PONG命令返回給詢問的哨兵。響應體中包含三部分內容，第一部分是當前哨兵對主節點下線的判斷，第二、第三部分是哨兵leader選舉相關的信息，后面再說。源碼如下：

void sentinelCommand(client *c) {......
//獲取主節點的結構體sentinelRedisInstance
ri = getSentinelRedisInstanceByAddrAndRunID(sentinel.masters,c->argv[2]->ptr,port,NULL);//確定節點是主節點,并且確定主節點已經下線
if (!sentinel.tilt && ri && (ri->flags & SRI_S_DOWN) &&(ri->flags & SRI_MASTER))//設置isdown變量值為1isdown = 1;......//返回的響應中包含三部分內容
addReplyMultiBulkLen(c,3);//第一部分是哨兵對主節點下線的判斷,0:未下線,1:已下線
addReply(c, isdown ? shared.cone : shared.czero);//第二部分是哨兵leader的ID或者*。這部分是哨兵選舉時的邏輯
addReplyBulkCString(c, leader ? leader : "*");//第三部分是哨兵leader的紀元。這部分是哨兵選舉時的邏輯
addReplyLongLong(c, (long long)leader_epoch);......
}

該響應結果的處理在sentinel.c文件的sentinelReceiveIsMasterDownReply方法中，拿到相應的結果后，首先判斷返回的結果是不是ARRAY類型，然后判斷ARRAY中的元素類型是不是is-master-down-by-addr命令返回的三個元素。如果是，獲取第一個元素的值是不是1，如果是1，就給主節點的flags賦值SRI_MASTER_DOWN，這就和我們上面的內容呼應起來了，下面是源碼部分的解析

void sentinelReceiveIsMasterDownReply(redisAsyncContext *c, void *reply, void *privdata) {......//返回的數據是一個ARRAY類型。并且第一個數據是Integer類型,第二個數據是String類型,第三個數據是Integer類型if (r->type == REDIS_REPLY_ARRAY && r->elements == 3 &&r->element[0]->type == REDIS_REPLY_INTEGER &&r->element[1]->type == REDIS_REPLY_STRING &&r->element[2]->type == REDIS_REPLY_INTEGER){ri->last_master_down_reply_time = mstime();//被詢問的哨兵返回的一共有三部分數據,如果第一部分的值是1,此時會將SRI_MASTER_DOWN賦值到flags變量中,ri->flags變量，是當前哨兵監聽的主節點的狀態判斷標識if (r->element[0]->integer == 1) {ri->flags |= SRI_MASTER_DOWN;} else {ri->flags &= ~SRI_MASTER_DOWN;}......
}

我們小結一下。redis哨兵每100ms運行一次，通過PING來檢測主節點是否下線，如果發現了主節點下線，會通過頻道將消息廣播出去。同時為了防止自己的誤判，會通過給其他哨兵發送is-master-down-by-addr命令來詢問其他哨兵對于主節點下線的意見，如果同意主節點下線的哨兵數大于配置文件中的quorum，此時會認為主節點客觀下線。接下來的流程就是從哨兵集群中選舉一個哨兵來執行主從切換

3、哨兵leader選舉

選舉leader前，首先判斷是否滿足舉行選舉的條件
比如：是否正在舉行選舉、上一次主從切換的時間距當前時間的時間差是否滿足條件等等。
如果舉行選舉的條件沒有問題，就會將主節點的failover_state變量設置為SENTINEL_FAILOVER_STATE_WAIT_START，該變量的初始值是：SENTINEL_FAILOVER_STATE_NONE，failover_state是一個狀態機，主要就是為了控制主從切換的流程，該狀態機有以下值，每一個值的意思，作者都有注釋，看注釋就行了。

#define SENTINEL_FAILOVER_STATE_NONE 0  /* No failover in progress. */
#define SENTINEL_FAILOVER_STATE_WAIT_START 1  /* Wait for failover_start_time*/
#define SENTINEL_FAILOVER_STATE_SELECT_SLAVE 2 /* Select slave to promote */
#define SENTINEL_FAILOVER_STATE_SEND_SLAVEOF_NOONE 3 /* Slave -> Master */
#define SENTINEL_FAILOVER_STATE_WAIT_PROMOTION 4 /* Wait slave to change role */
#define SENTINEL_FAILOVER_STATE_RECONF_SLAVES 5 /* SLAVEOF newmaster */
#define SENTINEL_FAILOVER_STATE_UPDATE_CONFIG 6 /* Monitor promoted slave. */

SENTINEL_FAILOVER_STATE_WAIT_START是流程的第二步，表明哨兵leader選舉開始。
接下來執行sentinelAskMasterStateToOtherSentinels方法。這個方法，我們前面已經提到過，作用是：詢問其他哨兵對于主節點下線的意見，防止因為自己的原因導致了誤判。那現在已經到了leader選舉階段，選leader，選新主節點了，為什么還要再回到之前的步驟，去詢問其他哨兵對于主節點下線的意見呢？其實，并不是要詢問其他哨兵對于主節點下線的意見，而是因為該方法中除了詢問的邏輯，還隱含著leader選舉的邏輯。那該方法是如何區分到底執行的是“詢問主節點是否下線”還是“執行leader選舉”呢？
實際上，是根據is-master-down-by-addr命令的最后一個參數。該參數有兩種情況，一種是 “ * ”，另外一種是配置文件中配置的哨兵的myid值

retval = redisAsyncCommand(ri->link->cc,sentinelReceiveIsMasterDownReply, ri,"%s is-master-down-by-addr %s %s %llu %s",sentinelInstanceMapCommand(ri,"SENTINEL"),master->addr->ip, port,sentinel.current_epoch,(master->failover_state > SENTINEL_FAILOVER_STATE_NONE) ?sentinel.myid : "*");

再看is-master-down-by-addr命令的處理方法sentinelCommand，在該方法中，有一段邏輯就會判斷入參client的第6個參數是不是 *，如果不是 *，就會執行哨兵leader選舉，源碼邏輯如下：

//如果run_id的值不為*,則執行哨兵leader選舉if (ri && ri->flags & SRI_MASTER && strcasecmp(c->argv[5]->ptr,"*")) {leader = sentinelVoteLeader(ri,(uint64_t)req_epoch,c->argv[5]->ptr,&leader_epoch);}

哨兵leader選舉的方法入口，就是這個sentinelVoteLeader方法。
哨兵leader選舉使用了Raft一致性協議，在介紹哨兵選舉之前，簡單說一下這個Raft協議，對理解哨兵選舉流程有幫助。

3.1、Raft協議

Raft協議的誕生是為了解決分布式一致性的問題。在Raft協議中，有三種角色，Leader、Follower、Candidate。
在一個穩定的Raft系統中，只有Leader和Follower。Leader不定時的給Follower發送心跳消息，來維護自己的Leader地位。
1)、如果某個Follower，一定時間內未收到Leader的消息，此時這個Follower會轉變成Candidate節點，開始發起Raft選舉
2)、Candidate節點首先給自己投一票，然后給其他Follower節點，發送投票請求，并等待其他節點的回復
3)、開啟一個定時器，判斷選舉過程是否超時
4)、如果在等待其他Follower節點回復時，收到了Leader的消息，說明新的Leader已經產生，此時Candidate節點會轉為Follower節點
5)、如果這個Candidate節點收到的投票確認個數超過了超過了半數節點，并且大于配置文件中的quorum數，此時該Candidate節點變成新的Leader節點，從而可以執行Leader節點需要運行的流程邏輯
在這個選舉流程中，每個Follower節點只能投一次票，如果選舉期間，Candidate節點收到的選票相同，此時會再重新發起選舉，直到選出Leader

3.2、哨兵leader選舉過程

3.2.1、投票過程

redis的哨兵Leader選舉并不是完全符合Raft協議，主要原因是：在redis哨兵模式穩定運行時，哨兵之間是平等的，沒有Leader和Follower之分，只有當主節點下線，準備選舉時，此時才會出現Leader和Follower。
我們看一下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);}//master記錄的哨兵leader的紀元小于請求哨兵的紀元。//當前哨兵的紀元小于等于請求哨兵的紀元//以上兩個條件確保了當前哨兵只能投一次票if (master->leader_epoch < req_epoch && sentinel.current_epoch <= req_epoch){//leader節點的runid設置為請求投票節點的runid,也就是Candidate節點的runidmaster->leader = sdsnew(req_runid);......//主節點記錄的leader的紀元更新為請求哨兵的紀元,代表給請求投票的哨兵投了一票master->leader_epoch = sentinel.current_epoch;......//當前哨兵將自己的投票結果,發送事件消息sentinelEvent(LL_WARNING,"+vote-for-leader",master,"%s %llu",master->leader, (unsigned long long) master->leader_epoch);......}//重置leader的紀元*leader_epoch = master->leader_epoch;//返回哨兵leader的runidreturn master->leader ? sdsnew(master->leader) : NULL;
}

當前哨兵投票完后，將自己的投票結果返回給請求投票的哨兵。
請求投票哨兵發起is-master-down-by-addr命令時，設置的回調函數是sentinelReceiveIsMasterDownReply，所以我們看下當請求投票哨兵收到其他哨兵的投票結果后，是如何進行處理的，sentinelReceiveIsMasterDownReply的邏輯如下：

void sentinelReceiveIsMasterDownReply(redisAsyncContext *c, void *reply, void *privdata) {//返回的數據是一個ARRAY類型。并且第一個數據是Integer類型,第二個數據是String類型,第三個數據是Integer類型if (r->type == REDIS_REPLY_ARRAY && r->elements == 3 &&r->element[0]->type == REDIS_REPLY_INTEGER &&r->element[1]->type == REDIS_REPLY_STRING &&r->element[2]->type == REDIS_REPLY_INTEGER){......//哨兵返回的第二部分不是*,那返回的就是哨兵leader的runidif (strcmp(r->element[1]->str,"*")) {......//master設置哨兵leader的runidri->leader = sdsnew(r->element[1]->str);//master設置哨兵leader的紀元ri->leader_epoch = r->element[2]->integer;......}}
}

執行完這部分邏輯，A哨兵就算拿到了B哨兵的選票，等到其他哨兵也回復了A之后，就開始進行下一步，計票。看看A能否當選leader

3.2.2、計票

計票的工作，其實就是計算一下所有的哨兵數量，然后再計算一下自己手里拿到的投票結果，根據一定的規則計算自己是否贏得了選舉。

char *sentinelGetLeader(sentinelRedisInstance *master, uint64_t epoch) {......//計算所有的哨兵數量voters = dictSize(master->sentinels)+1; /* All the other sentinels and me.*/......//計算選票......voters_quorum = voters/2+1;//當選leader成功的條件有兩個。//1、得票超過半數//2、得票數大于配置文件中預設的quorumif (winner && (max_votes < voters_quorum || max_votes < master->quorum))winner = NULL;winner = winner ? sdsnew(winner) : NULL;sdsfree(myvote);dictRelease(counters);//返回選舉出來的哨兵leader的runidreturn winner;
}

經過選舉，最終會得到一個哨兵leader。選出了leader，就要開始故障轉移了，那故障轉移就要選出一臺從節點，來作為新的主節點，那具體選擇哪臺呢？

4、哨兵leader選擇一臺從節點作為新主節點

選擇新主節點的邏輯，在sentinel.c文件的sentinelFailoverSelectSlave方法中。

void sentinelFailoverSelectSlave(sentinelRedisInstance *ri) {//選擇一個從節點作為新的主節點sentinelRedisInstance *slave = sentinelSelectSlave(ri);if (slave == NULL) {sentinelEvent(LL_WARNING,"-failover-abort-no-good-slave",ri,"%@");sentinelAbortFailover(ri);} else {//將選舉出來的slave節點廣播出去sentinelEvent(LL_WARNING,"+selected-slave",slave,"%@");slave->flags |= SRI_PROMOTED;ri->promoted_slave = slave;//故障轉移狀態機進入下一個階段ri->failover_state = SENTINEL_FAILOVER_STATE_SEND_SLAVEOF_NOONE;ri->failover_state_change_time = mstime();sentinelEvent(LL_NOTICE,"+failover-state-send-slaveof-noone",slave, "%@");}
}

選擇的邏輯主要在sentinelSelectSlave中。我們看一下方法的實現。首先，剔除一些不滿足條件的從節點

sentinelRedisInstance *sentinelSelectSlave(sentinelRedisInstance *master) {......if (master->flags & SRI_S_DOWN)max_master_down_time += mstime() - master->s_down_since_time;max_master_down_time += master->down_after_period * 10;......//遍歷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;//從節點上一次可用的事件距離現在超過5秒,則不參加主節點的選舉if (mstime() - slave->link->last_avail_time > SENTINEL_PING_PERIOD*5) continue;//如果從節點的優先級配置是0,則不參加主節點的選舉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;//計算當前slave上一次收到info輸出的時間差,不符合條件的剔除if (mstime() - slave->info_refresh > info_validity_time) continue;//計算當前slave上一次斷連的時間,不符合條件的剔除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;
}

之后，對滿足條件的從節點進行排序，排序邏輯在compareSlavesForPromotion中，具體邏輯為：

//入參的兩個參數，a和b都是從節點
//返回的int值小于0時,a在前b在后,否則,a在后b在前
int compareSlavesForPromotion(const void *a, const void *b) {sentinelRedisInstance **sa = (sentinelRedisInstance **)a,**sb = (sentinelRedisInstance **)b;char *sa_runid, *sb_runid;//優先級高的從節點被選舉為主節點if ((*sa)->slave_priority != (*sb)->slave_priority)return (*sa)->slave_priority - (*sb)->slave_priority;//優先級相同,選擇處理復制數據最多的從節點,處理能力強if ((*sa)->slave_repl_offset > (*sb)->slave_repl_offset) {return -1; /* a < b */} else if ((*sa)->slave_repl_offset < (*sb)->slave_repl_offset) {return 1; /* a > b */}//如果復制能力相同。按字典順序選擇runid最小的從節點作為主節點。//老版本的redis,INFO命令中沒有runid,所以runid為NULL。runid為NULL的節點比runid有值的節點大,要排在后面sa_runid = (*sa)->runid;sb_runid = (*sb)->runid;if (sa_runid == NULL && sb_runid == NULL) return 0;else if (sa_runid == NULL) return 1;  /* a > b */else if (sb_runid == NULL) return -1; /* a < b */return strcasecmp(sa_runid, sb_runid);
}

通過該邏輯就選擇出了一個從節點。然后故障轉移狀態機就變為：SENTINEL_FAILOVER_STATE_SEND_SLAVEOF_NOONE，代表開始執行主從切換。

5、從節點切換為新主節點

主從切換的具體邏輯實現是在sentinel.c文件中的sentinelSendSlaveOf方法中，通過發送SLAVEOF NO ONE指令實現，將自己的角色由從節點切換成主節點。

int sentinelSendSlaveOf(sentinelRedisInstance *ri, char *host, int port) {......//執行SLAVEOF NO ONE命令,切換當前從節點為主節點。5.0版本后,此命令廢棄,使用replicaof命令替代retval = redisAsyncCommand(ri->link->cc,sentinelDiscardReplyCallback, ri, "%s %s %s",sentinelInstanceMapCommand(ri,"SLAVEOF"),host, portstr);if (retval == C_ERR) return retval;ri->link->pending_commands++;......return C_OK;
}

從節點變成新的主節點，那客戶端需要修改配置，連接到這個新的主節點，否則繼續連接到舊的主節點就會有異常發生。那這個過程是如何實現的呢？

6、客戶端如何獲知新的主節點地址

是通過頻道實現。在哨兵模式執行主從切換的過程中，關鍵的步驟都會向頻道中發送消息，訂閱了相關頻道就可以獲取到對應的消息。我們這個場景也不例外，哨兵模式選舉出新的主節點并完成主從切換后，會向名為+switch-master的頻道發送新主節點的ip和端口，客戶端訂閱這個頻道，就可以獲取到新主節點的ip和端口，自動完成新主節點的配置切換。