什麼是哨兵？

哨兵（Sentinel）是 redis 的高可用性解決方案，前面我們講的主從複製它是高可用的基礎，需要人工介入才能完成故障轉移，哨兵可以解決這個問題，在主從複製情況下，當主節點發生故障時，哨兵可以自動的發現故障並且完成故障轉移，實現真正的 redis 高可用。在哨兵叢集中，哨兵會監視所有的 redis 伺服器和其他 sentinel 節點狀態，來保證 redis 的高可用。

哨兵的搭建

哨兵本質也是一個 redis 服務，只是跟普通的 redis 服務提供了不一樣的功能。哨兵是一個分散式架構，因為你要保證 redis 高可用，首先需要保證自己高可用，所以如果我們需要搭建哨兵的話，最少需要部署三個例項，最好是奇數個，因為在後續的故障轉移中會涉及到投票。

哨兵的配置檔案我們可以在 redis 的 GitHub 專案下下載，在專案下有一個叫做 sentinel.conf 的檔案，可以使用它作為我們哨兵的配置模板，當然你也可以使用 redis.conf 配置檔案，只需要新增哨兵相關配置就好了。

哨兵相關的配置項不多，主要有以下幾個配置項：

// 埠號，預設是 redis 例項+20000，所以我們沿用這個規則就好了
port 26379 
// 是否守護程序執行
daemonize yes 
// 日誌存放的位置，這個非常重要，通過日誌可以檢視故障轉移的過程
logfile "26379.log" 
// 監視一個名為 mymaster（自定義） 的 redis 主伺服器， 這個主伺服器的 IP 地址為 127.0.0.1 ， 埠號為 6379 ， 
// 最後面的 2 代表著至少有兩個哨兵認為主伺服器出現故障才會進行故障轉移，否則認定主服務未失效
sentinel monitor mymaster 127.0.0.1 6379 2 
// 哨兵判斷伺服器失效的響應時間，超過這個時間未接收到伺服器的迴應，就認為該伺服器失效了
sentinel down-after-milliseconds mymaster 30000 
// 完成故障轉移之後，最多多少個從伺服器可以同時發起資料複製，數字越小，說明完成全部從服務資料複製的時間越長
// 數字越大，對主伺服器的壓力就變大了
sentinel parallel-syncs mymaster 1 
// 故障轉移超時時間
sentinel failover-timeout mymaster 180000
 

對於每個 Sentinel 例項配置除了 port 和 logfile 不同之外，其他配置項都是一樣的。修改好配置後，我們可以使用 ./redis-sentinel sentinel.conf 命令來啟動哨兵，命令跟 redis 例項啟動差不多，因為哨兵也是 redis 例項，所以我們可以使用 ./redis-cli -p 26379 info sentinel 命令檢視當前的哨兵資訊，如下圖所示：

問題：如何在只配置 master 伺服器的情況下，發現從伺服器和其他 Sentinel ？

從伺服器的發現，Sentinel 可以通過詢問主伺服器來獲取從伺服器的資訊，對於發現其他 Sentinel 節點，則通過釋出與訂閱功能實現，通過向頻道 sentinel:hello 傳送資訊來實現的，主要有以下兩步：

1、每個 Sentinel 每 2 秒會通過釋出與訂閱功能向所有的主服務和從伺服器的 sentinel:hello 頻道傳送一條資訊， 資訊中包含了 Sentinel 的 IP 地址、埠號和執行 ID （runid）

2、每個 Sentinel 都訂閱了被它監視的所有主伺服器和從伺服器的 sentinel:hello 頻道， 查詢之前未出現過的 sentinel （looking for unknown sentinels）。 當一個 Sentinel 發現一個新的 Sentinel 時， 它會將新的 Sentinel 新增到一個列表中， 這個列表儲存了 Sentinel 已知的， 監視同一個主伺服器的所有其他 Sentinel

哨兵故障轉移原理

故障轉移是哨兵的主要工作，這背後的實現邏輯也是非常的複雜，具體的實現邏輯還請檢視相關書籍，我對哨兵的故障轉移總結了以下三點：

1、監聽伺服器

每個 Sentinel 節點每隔 1 秒對主節點、從節點、其他 Sentinel 節點發送 ping 命令做心跳檢測，來判斷伺服器的狀態。

節點也會對 Sentinel 進行相應的回覆，在這些回覆中，以下三種回覆是有效回覆：

• 返回 +PONG
• 返回 -LOADING
• 返回 -MASTERDOWN

如果節點在哨兵配置檔案設定的 master-down-after-milliseconds 選項的值內，一直沒有哪怕一次有效回覆，那麼 Sentinel 會把該伺服器標記為下線狀態，我們把這種下線稱為主觀下線，也就是說只有這個 sentinel 認為該伺服器是下線狀態。

如果被主觀下線的伺服器是主伺服器時，sentinel 為了確認這個主伺服器是否真的下線，該 Sentinel 會向其他的同樣監聽主伺服器的 Sentinel 進行詢問，看他們是否也認為主伺服器進入下線狀態，當有足夠多的 Sentinel 都認為主伺服器下線時，該 Sentinel 會將主伺服器判斷為客觀下線，這是真正的下線了，並且會對它進行故障轉移操作。

2、選舉 Sentinel 節點完成轉移任務

故障轉移並不是所有的 sentinel 共同完成，而是選舉出一臺 sentinel 節點作為領導者來完成這次故障轉移，所以當主伺服器被標記為客觀下線時，sentinel 之間就會通過 Raft 演算法選舉出一個領導者來完成故障轉移工作。redis 選舉領頭的 sentinel 的規則和方法大致如下：

• 所有線上的 sentinel 都有資格被選為領導者，也就是說每個 sentinel 都有成為領導者的機會
• 當 sentinel 標記主伺服器為主觀下線時，會向其他 Sentinel 節點發送 sentinel is-master-down-by-addr 命令， 要求將自己設定為領導者
• 收到命令的 Sentinel 節點，採用先到先得的規則，如果沒有同意過其他 Sentinel 節點的 sentinel is-master-down-by-addr 命令，將同意該請求，否則拒絕
• 如果該 Sentinel 節點發現自己的票數已經超過半數，那麼它將成為領導者
• 如果在規定時間內，沒有選舉出 sentinel 領導者，那麼將在一段時間後再次選舉，知道選出 sentinel 領導者為止。

3、選舉新 master 伺服器完成故障轉移

選舉出來的 sentinel 領導者將完成剩下的故障轉移工作，故障轉移主要有以下三步：

1、挑選出新的主伺服器

在已下線的主伺服器的所有從伺服器中，挑選出一個從伺服器，並將其轉換為主伺服器，選擇新的主伺服器的規則如下：

• 在失效主伺服器屬下的從伺服器當中， 那些被標記為主觀下線、已斷線、或者最後一次回覆 PING 命令的時間大於五秒鐘的從伺服器都會被淘汰
• 在失效主伺服器屬下的從伺服器當中， 那些與失效主伺服器連線斷開的時長超過 down-after 選項指定的時長十倍的從伺服器都會被淘汰
• 在經歷了以上兩輪淘汰之後剩下來的從伺服器中， 選出複製偏移量（replication offset）最大的那個從伺服器作為新的主伺服器； 如果複製偏移量不可用， 或者從伺服器的複製偏移量相同， 那麼帶有最小執行 ID 的那個從伺服器成為新的主伺服器

對挑選出來的從伺服器執行 slaveof no one 命令，使其成為主節點。

2、修改其他從伺服器的複製目標

當新的主伺服器出現後，sentinel 的領導者下一步需要做的就是，讓其他從伺服器去複製新的主伺服器，通過向其他從伺服器傳送 slaveof new_master port 命令來完成，複製規則和配置檔案的 parallel-syncs 引數有關

3、將舊的主伺服器變成從伺服器
故障轉移操作最後要做的就是將已下線的主伺服器設定為新的主服務的從伺服器，並保持對其關注，等它恢復後命令它去複製新的主節點。

上面就是 redis 哨兵的一些知識，希望看完之後你有所收穫。

最後

目前網際網路上很多大佬都有 Redis 系列教程，如有雷同，請多多包涵了。原創不易，碼字不易，還希望大家多多支援。若文中有所錯誤之處，還望提出，謝謝。

歡迎掃碼關注微信公眾號：「平頭哥的技術博文」，和平頭哥一起學習，一起進步。

相關推薦