??假如面試官讓你聊聊Sentinel（哨兵），看完這篇文章足矣！??

本文已收錄于專欄

??《Redis精通系列》??

上千人點贊收藏，全套Redis學習資料，大廠必備技能！

目錄

1、簡介

2、Sentinel初始化與網路連接

2.1 初始化Sentinel服務器

2.2 替換普通Redis代碼為Sentinel的專用代碼

2.3 初始化Sentinel狀態

2.4 初始化Sentinel監視的主服務器串列

2.5 創建連接主服務器的網路連接

2.6 創建連接從服務器的網路連接

2.7 創建Sentinel之間的網路連接

3、Sentinel作業

3.1 檢測Master是否主觀下線

3.2 檢測Master是否客觀下線

3.3 選舉領頭Sentinel

3.4 故障轉移

1、簡介

主從復制奠定了Redis分布式的基礎，但是普通的主從復制并不能達到高可用的狀態，在普通的主從復制模式下，如果主服務器宕機，就只能通過運維人員手動切換主服務器，很顯然這種方案并不可取，
針對上述情況，Redis官方推出了可抵抗節點故障的高可用方案——Redis Sentinel（哨兵），Redis Sentinel（哨兵）：由一個或多個Sentinel實體組成的Sentinel系統，它可以監視任意多個主從服務器，當監視的主服務器宕機時，自動下線主服務器，并且擇優選取從服務器升級為新的主服務器，
?

如下示例：當舊Master下線時長超過用戶設定的下線時長上限，Sentinel系統就會對舊Master執行故障轉移操作，故障轉移操作包含三個步驟：

1. 在Slave中選擇資料最新的作為新的Master
2. 向其他Slave發送新的復制指令，讓其他從服務器成為新的Master的Slave
3. 繼續監視舊Master，如果其上線則將舊Master設定為新Master的Slave

本文基于如下資源清單進行開展：

?

2、Sentinel初始化與網路連接

Sentinel并沒有什么特別神奇的地方，它就是一個更加簡單的Redis服務器，在Sentinel啟動的時候它會加載不同的命令表和組態檔，因此從本質上來講Sentinel就是一個擁有較少命令和部分特殊功能的Redis服務，當一個Sentinel啟動時它需要經歷如下步驟：

1. 初始化Sentinel服務器
2. 替換普通Redis代碼為Sentinel的專用代碼
3. 初始化Sentinel狀態
4. 根據用戶給定的Sentinel組態檔，初始化Sentinel監視的主服務器串列
5. 創建連接主服務器的網路連接
6. 根據主服務獲取從服務器資訊，創建連接從服務器的網路連接
7. 根據發布/訂閱獲取Sentinel資訊，創建Sentinel之間的網路連接

2.1 初始化Sentinel服務器

Sentinel本質上就是一個Redis服務器，因此啟動Sentinel需要啟動一個Redis服務器，但是Sentinel并不需要讀取RDB/AOF檔案來還原資料狀態，
?

2.2 替換普通Redis代碼為Sentinel的專用代碼

Sentinel用于較少的Redis命令，大部分命令在Sentinel客戶端都不支持，并且Sentinel擁有一些特殊的功能，這些需要Sentinel在啟動時將Redis服務器使用的代碼替換為Sentinel的專用代碼，在此期間Sentinel會載入與普通Redis服務器不同的命令表，
Sentinel不支持SET、DBSIZE等命令；保留支持PING、PSUBSCRIBE、SUBSCRIBE、UNSUBSCRIBE、INFO等指令；這些指令在Sentinel作業中提供了保障，
?

2.3 初始化Sentinel狀態

裝載Sentinel的特有代碼之后，Sentinel會初始化sentinelState結構，該結構用于存盤Sentinel相關的狀態資訊，其中最重要的就是masters字典，

struct sentinelState {

    //當前紀元，故障轉移使用
    uint64_t current_epoch; 

    // Sentinel監視的主服務器資訊 
    // key -> 主服務器名稱 
    // value -> 指向sentinelRedisInstance指標
    dict *masters; 
    // ...
} sentinel;

2.4 初始化Sentinel監視的主服務器串列

Sentinel監視的主服務器串列保存在sentinelState的masters字典中，當sentinelState創建之后，開始對Sentinel監視的主服務器串列進行初始化，

• masters的key是主服務的名字
• masters的value是一個指向sentinelRedisInstance指標

主服務器的名字由我們sentinel.conf組態檔指定，如下主服務器名字為redis-master（我這里是一主二從的配置）：

daemonize yes
port 26379
protected-mode no
dir "/usr/local/soft/redis-6.2.4/sentinel-tmp"
sentinel monitor redis-master 192.168.211.104 6379 2
sentinel down-after-milliseconds redis-master 30000
sentinel failover-timeout redis-master 180000
sentinel parallel-syncs redis-master 1

sentinelRedisInstance實體保存了Redis服務器的資訊（主服務器、從服務器、Sentinel資訊都保存在這個實體中），

typedef struct sentinelRedisInstance {

    // 標識值，標識當前實體的型別和狀態，如SRI_MASTER、SRI_SLVAE、SRI_SENTINEL
    int flags;

    // 實體名稱 主服務器為用戶配置實體名稱、從服務器和Sentinel為ip:port
    char *name;

    // 服務器運行ID
    char *runid;

    //配置紀元，故障轉移使用
    uint64_t config_epoch; 

    // 實體地址
    sentinelAddr *addr;

    // 實體判斷為主觀下線的時長 sentinel down-after-milliseconds redis-master 30000
    mstime_t down_after_period; 

    // 實體判斷為客觀下線所需支持的投票數 sentinel monitor redis-master 192.168.211.104 6379 2
    int quorum;

    // 執行故障轉移操作時，可以同時對新的主服務器進行同步的從服務器數量 sentinel parallel-syncs redis-master 1
    int parallel-syncs;

    // 重繪故障遷移狀態的最大時限 sentinel failover-timeout redis-master 180000
    mstime_t failover_timeout;

    // ...
} sentinelRedisInstance;

根據上面的一主二從配置將會得到如下實體結構：

2.5 創建連接主服務器的網路連接

當實體結構初始化完成之后，Sentinel將會開始創建連接Master的網路連接，這一步Sentinel將成為Master的客戶端，
Sentinel和Master之間會創建一個命令連接和一個訂閱連接：

• 命令連接用于獲取主從資訊
• 訂閱連接用于Sentinel之間進行資訊廣播，每個Sentinel和自己監視的主從服務器之間會訂閱sentinel:hello頻道（注意Sentinel之間不會創建訂閱連接，它們通過訂閱sentinel:hello頻道來獲取其他Sentinel的初始資訊）

Sentinel在創建命令連接完成之后，每隔10秒鐘向Master發送一次INFO指令，通過Master的回復資訊可以獲得兩方面的知識：

• Master本身的資訊
• Master下的Slave資訊

2.6 創建連接從服務器的網路連接

根據主服務獲取從服務器資訊，Sentinel可以創建到Slave的網路連接，Sentinel和Slave之間也會創建命令連接和訂閱連接，

當Sentinel和Slave之間創建網路連接之后，Sentinel成為了Slave的客戶端，Sentinel也會每隔10秒鐘通過INFO指令請求Slave獲取服務器資訊，
到這一步Sentinel獲取到了Master和Slave的相關服務器資料，這其中比較重要的資訊如下：

• 服務器ip和port
• 服務器運行id run id
• 服務器角色role
• 服務器連接狀態mater_link_status
• Slave復制偏移量slave_repl_offset（故障轉移中選舉新的Master需要使用）
• Slave優先級slave_priority

此時實體結構資訊如下所示：

2.7 創建Sentinel之間的網路連接

此時是不是還有疑問，Sentinel之間是怎么互相發現對方并且相互通信的，這個就和上面Sentinel與自己監視的主從之間訂閱sentinel:hello頻道有關了，
Sentinel會與自己監視的所有Master和Slave之間訂閱sentinel:hello頻道，并且Sentinel每隔2秒鐘向sentinel:hello頻道發送一條訊息，訊息內容如下：

PUBLISH _sentinel_:hello "<s_ip>,<s_port>,<s_runid>,<s_epoch>,<m_ip>,<m_port>,<m_runid>,<m_epoch>"

其中s代碼Sentinel，m代表Master；ip表示IP地址，port表示埠、runid表示運行id、epoch表示配置紀元，
?

多個Sentinel在組態檔中會配置相同的主服務器ip和埠資訊，因此多個Sentinel均會訂閱sentinel:hello頻道，通過頻道接收到的資訊就可獲取到其他Sentinel的ip和port，其中有如下兩點需要注意：

• 如果獲取到的runid與Sentinel自己的runid相同，說明訊息是自己發布的，直接丟棄
• 如果不相同，則說明接收到的訊息是其他Sentinel發布的，此時需要根據ip和port去更新或新增Sentinel實體資料

Sentinel之間不會創建訂閱連接，它們只會創建命令連接：

此時實體結構資訊如下所示：

3、Sentinel作業

Sentinel最主要的作業就是監視Redis服務器，當Master實體超出預設的時限后切換新的Master實體，這其中有很多細節作業，大致分為檢測Master是否主觀下線、檢測Master是否客觀下線、選舉領頭Sentinel、故障轉移四個步驟，
?

3.1 檢測Master是否主觀下線

Sentinel每隔1秒鐘，向sentinelRedisInstance實體中的所有Master、Slave、Sentinel發送PING命令，通過其他服務器的回復來判斷其是否仍然在線，?

sentinel down-after-milliseconds redis-master 30000

在Sentinel的組態檔中，當Sentinel PING的實體在連續down-after-milliseconds配置的時間內回傳無效命令，則當前Sentinel認為其主觀下線，Sentinel的組態檔中配置的down-after-milliseconds將會對其sentinelRedisInstance實體中的所有Master、Slave、Sentinel都適應，

無效指令指的是+PONG、-LOADING、-MASTERDOWN之外的其他指令，包括無回應

如果當前Sentinel檢測到Master處于主觀下線狀態，那么它將會修改其sentinelRedisInstance的flags為SRI_S_DOWN

3.2 檢測Master是否客觀下線

當前Sentinel認為其下線只能處于主觀下線狀態，要想判斷當前Master是否客觀下線，還需要詢問其他Sentinel，并且所有認為Master主觀下線或者客觀下線的總和需要達到quorum配置的值，當前Sentinel才會將Master標志為客觀下線，

當前Sentinel向sentinelRedisInstance實體中的其他Sentinel發送如下命令：

SENTINEL is-master-down-by-addr <ip> <port> <current_epoch> <runid>

• ip：被判斷為主觀下線的Master的IP地址
• port：被判斷為主觀下線的Master的埠
• current_epoch：當前sentinel的配置紀元
• runid：當前sentinel的運行id，runid

current_epoch和runid均用于Sentinel的選舉，Master下線之后，需要選舉一個領頭Sentinel來選舉一個新的Master，current_epoch和runid在其中發揮著重要作用，這個后續講解，
?

接收到命令的Sentinel，會根據命令中的引數檢查主服務器是否下線，檢查完成后會回傳如下三個引數：

• down_state：檢查結果1代表已下線、0代表未下線
• leader_runid：回傳*代表判斷是否下線，回傳runid代表選舉領頭Sentinel
• leader_epoch：當leader_runid回傳runid時，配置紀元會有值，否則一直回傳0

1. 當Sentinel檢測到Master處于主觀下線時，詢問其他Sentinel時會發送current_epoch和runid，此時current_epoch=0，runid=*
2. 接收到命令的Sentinel回傳其判斷Master是否下線時down_state = 1/0，leader_runid = *，leader_epoch=0

3.3 選舉領頭Sentinel

down_state回傳1，證明接收is-master-down-by-addr命令的Sentinel認為該Master也主觀下線了，如果down_state回傳1的數量（包括本身）大于等于quorum（組態檔中配置的值），那么Master正式被當前Sentinel標記為客觀下線，
此時，Sentinel會再次發送如下指令：

SENTINEL is-master-down-by-addr <ip> <port> <current_epoch> <runid>

此時的runid將不再是0，而是Sentinel自己的運行id（runid）的值，表示當前Sentinel希望接收到is-master-down-by-addr命令的其他Sentinel將其設定為領頭Sentinel，這個設定是先到先得的，Sentinel先接收到誰的設定請求，就將誰設定為領頭Sentinel，
發送命令的Sentinel會根據其他Sentinel回復的結果來判斷自己是否被該Sentinel設定為領頭Sentinel，如果Sentinel被其他Sentinel設定為領頭Sentinel的數量超過半數Sentinel（這個數量在sentinelRedisInstance的sentinel字典中可以獲取），那么Sentinel會認為自己已經成為領頭Sentinel，并開始后續故障轉移作業（由于需要半數，且每個Sentinel只會設定一個領頭Sentinel，那么只會出現一個領頭Sentinel，如果沒有一個達到領頭Sentinel的要求，Sentinel將會重新選舉直到領頭Sentinel產生為止），
?

3.4 故障轉移

故障轉移將會交給領頭sentinel全權負責，領頭sentinel需要做如下事情：

1. 從原先master的slave中，選擇最佳的slave作為新的master
2. 讓其他slave成為新的master的slave
3. 繼續監聽舊master，如果其上線，則將其設定為新的master的slave

這其中最難的一步是如果選擇最佳的新Master，領頭Sentinel會做如下清洗和排序作業：

1. 判斷slave是否有下線的，如果有從slave串列中移除
2. 洗掉5秒內未回應sentinel的INFO命令的slave
3. 洗掉與下線主服務器斷線時間超過down_after_milliseconds * 10 的所有從服務器
4. 根據slave優先級slave_priority，選擇優先級最高的slave作為新master
5. 如果優先級相同，根據slave復制偏移量slave_repl_offset，選擇偏移量最大的slave作為新master
6. 如果偏移量相同，根據slave服務器運行id run id排序，選擇run id最小的slave作為新master

新的Master產生后，領頭sentinel會向已下線主服務器的其他從服務器（不包括新Master）發送SLAVEOF ip port命令，使其成為新master的slave，
?

到這里Sentinel的的作業流程就算是結束了，如果新master下線，則回圈流程即可！