一、前言

上一篇文章Redis主從複製原理中簡要地說明了主從複製的一個基本原理，包含全量複製、複製積壓緩衝區與增量複製等內容，有興趣的同學可以先看下。

利用主從複製，可以實現讀寫分離、資料備份等功能。但如果主庫宕機後，需要運維人員手動地將一個從庫提升為新主庫，並將其他從庫slaveof新主庫，以此來實現故障恢復。

因此，主從模式的一個缺點，就在於無法實現自動化地故障恢復。Redis後來引入了哨兵機制，哨兵機制大大提升了系統的高可用性。

二、什麼是哨兵

哨兵，就是站崗放哨的，時刻監控周圍的一舉一動，在第一時間發現敵情並行出及時的警報。

Redis中的哨兵（Sentinel），則是一個特殊的Redis範例，不過它並不儲存資料。也就是說，哨兵在啟動時，不會去載入RDB檔案。

關於Redis的持久化，可以參考我的另外一篇文章談談Redis的持久化——AOF紀錄檔與RDB快照

上圖就是一個典型的哨兵架構，由資料節點與哨兵節點構成，通常會部署多個哨兵節點。

哨兵主要具有三個作用，監控、選主與通知。

監控：哨兵會利用心跳機制，週期性不斷地檢測主庫與從庫的存活性

選主：哨兵檢測到主庫宕機後，選擇一個從庫將之切換為新主庫

通知：哨兵會將新主庫的地址通知到所有從庫，使得所有從庫與舊主庫slaveof新主庫，也會將新主庫的地址通知到使用者端上

我會在下文詳細講一下監控與選主的過程

三、監控

哨兵系統是通過3個定時任務，來完成對主庫、從庫與哨兵之間的探活。

哨兵如何拿到從庫地址

首先我們會在組態檔中設定主庫地址，這樣哨兵在啟動後，會以每隔10秒的頻率向主庫傳送info命令，從而獲得當前的主從拓撲關係，這樣就拿到了所有從庫的地址。

哨兵如何感知到其他哨兵的存在

接著每隔2秒，會使用pub/sub（釋出訂閱）機制，在主庫上的_sentinel_:hello的頻道上釋出訊息，訊息內容包括哨兵自己的ip、port、runid與主庫的設定。

每個哨兵都會訂閱該頻道，在該頻道上釋出與消費訊息，從而實現哨兵之間的互相感知。

哨兵是如何實現對節點的監控

利用啟動設定與info命令可以獲取到主從庫地址，利用釋出訂閱可以感知到其餘的哨兵節點。

在此基礎上，哨兵會每隔1秒向主庫、從庫與其他哨兵節點傳送PING命令，因此來進行互相探活。

主觀下線與客觀下線

當某個哨兵在 down-after-milliseconds（預設是30秒） 設定的連續時間內，仍然沒有收到主庫的正確響應，則當前哨兵會認為主庫主觀下線，並將其標記為sdown（subjective down）

為了避免當前哨兵對主庫的誤判，因此這個時候還需要參考其他哨兵的意見。

接著當前哨兵會向其他哨兵傳送 sentinel is-master-down-by-addr 命令，如果有半數以上（由quorum引數決定）的哨兵認為主庫確實處於主觀下線狀態，則當前哨兵認為主庫客觀下線，標記為odown（objective down）

四、選主

一旦某個主庫被認定為客觀下線時，這個時候需要進行哨兵選舉，選舉出一個領導者哨兵，來完成主從切換的過程。

哨兵選舉

哨兵A在向其他哨兵傳送 sentinel is-master-down-by-addr 命令時，同時要求其他哨兵同意將其設定為Leader，也就是想獲得其他哨兵的投票。

在每一輪選舉中，每個哨兵僅有一票。投票遵循先來先到的原則，如果某個哨兵沒有投給別人，就會投給哨兵A。

首先獲得半數以上投票的哨兵，將被選舉稱為Leader。

這裡的哨兵選舉，採用的是Raft演演算法。這裡不對Raft做詳細的探討，有興趣的同學，可以參考我的另外一篇文章22張圖，帶你入門分散式一致性演演算法Raft

該文章採用大量的圖例，相信你可以從中學習到全新的知識，從而開啟分散式一致性演演算法的大門，大夥們記得等我搞完Paxos與Zab。

過半投票機制也常用於很多演演算法中，例如RedLock，在半數以上的節點上加鎖成功，才代表申請到了分散式鎖，具體可參考這篇文章的最後我用了上萬字，走了一遍Redis實現分散式鎖的坎坷之路，從單機到主從再到多範例，原來會發生這麼多的問題

在Zookeeper選舉中，同樣也用到了過半投票機制，在這篇文章中面試官：能給我畫個Zookeeper選舉的圖嗎？我從原始碼角度分析了Zookeeper選舉的過程。

故障恢復

在選舉到領導者哨兵後，將由該哨兵完成故障恢復工作。

故障恢復分為以下兩步：

首先需要在各個從庫中，選出一個健康的且資料最新的從庫出來。
將該從庫提升為新主庫，即執行slaveof no one，其他從節點slaveof新主庫。

詳細說一下第一步，挑選是有條件的。首先要過濾出不健康的節點，再按某種規則排序，最後取第一個從庫，我們直接從原始碼入手：

sentinelRedisInstance *sentinelSelectSlave(sentinelRedisInstance *master) {
    sentinelRedisInstance **instance =
        zmalloc(sizeof(instance[0])*dictSize(master->slaves));
    sentinelRedisInstance *selected = NULL;
    int instances = 0;
    mstime_t max_master_down_time = 0;

    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;

    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秒內沒有迴應哨兵的ping命令
        if (mstime() - slave->link->last_avail_time > SENTINEL_PING_PERIOD*5) continue;
        //優先順序為0
        if (slave->slave_priority == 0) continue;
        //沒在3秒或5秒（依據主庫狀態）內完成對info命令的迴應
        if (mstime() - slave->info_refresh > info_validity_time) continue;
        //與主庫的斷開時間，超過max_master_down_time
        if (slave->master_link_down_time > max_master_down_time) continue;
        //健康的節點加入到instance陣列中
        instance[instances++] = slave;
    }
    //按照某種規則進行快速排序
    qsort(instance,instances,sizeof(sentinelRedisInstance*),compareSlavesForPromotion);
    //選取第一個
    selected = instance[0];
    return selected;
}

int compareSlavesForPromotion(const void *a, const void *b) {
    sentinelRedisInstance **sa = (sentinelRedisInstance **)a,
                          **sb = (sentinelRedisInstance **)b;
    char *sa_runid, *sb_runid;
    //首先比較優先順序，誰的優先順序越小（除了0），就選誰
    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
    sa_runid = (*sa)->runid;
    sb_runid = (*sb)->runid;
    //低版本的Redis，在info命令中不存在runid，因此可能為null
    //為null的runid，認為它比任何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);
}

因此，以下從庫會被過濾出：

主觀下線、客觀下線或斷線
沒在5秒內完成對哨兵ping命令的迴應
priority=0
沒在3秒或5秒內（由主庫狀態決定）內完成對info命令的迴應
與主庫的斷開時間，超過max_master_down_time

剩下的節點，就是健康的節點，此時再執行一次快速排序，排序的規則如下：

比較優先順序（priority），誰的優先順序越小（除了0），就選誰
比較複製偏移量。誰的偏移量大，就選誰
比較runid，按照字母順序排序。誰靠前，則選誰

五、總結

本文算是Redis哨兵的一個入門文章，主要講了哨兵的作用，例如監控、選主和通知。

在Redis讀寫分離的情況下，使用哨兵可以很輕鬆地做到故障恢復，提升了整體的可用性。

但哨兵無法解決Redis單機寫的瓶頸，這就需要引入叢集模式，相應的文章也被列為明年的寫作計劃中。

Redis哨兵機制原理淺析