更多內容，歡迎關注微信公眾號：全菜工程師小輝。公眾號回覆關鍵詞，領取免費學習資料。

當主伺服器宕機後，需要手動把一臺從伺服器切換為主伺服器，這就需要人工干預，費事費力，還會造成一段時間內服務不可用。 所以更多時候，我們優先考慮哨兵(sentinel) 模式。

Redis sentinel是Redis高可用實現方案：故障發現、故障自動轉移、配置中心、客戶端通知。從Redis的2.6版本開始提供的，但是當時這個版本的模式是不穩定的，直到Redis的2.8版本以後，這個哨兵模式才穩定下來，在生產環境中，如果想要使用Redis的哨兵模式，也會盡量使用Redis的2.8版本之後的版本。

哨兵雖然有一個單獨的可執行檔案Redis-sentinel ，但實際上它只是一個執行在特殊模式下的 Redis伺服器，你可以在啟動一個普通Redis伺服器時通過給定--sentinel

選項來啟動哨兵，哨兵的一些設計思路和zookeeper非常類似。

sentinel的定時任務

sentinel機制中有三種重要的定時任務。

1. 每10秒每個sentinel對master和slave執行info

作用：

• 發現slave節點。
• 確認主從關係。

1. 每2秒每個sentinel通過master節點的channel交換資訊(pub/sub)

作用：

• 互相通訊掌握節點的資訊和自身資訊，可以感知新加入的sentinel

通過master節點的__sentinel__:hello頻道進行互動，所有sentinel訂閱這個頻道並每2秒向該頻道釋出資訊

1. 每1秒每個sentinel對其他sentinel和master，slave進行ping

作用：

• 心跳檢測

主觀下線和客觀下線

主觀下線

主觀下線：單個sentinel節點對Redis節點通訊失敗的“偏見”。

這是一種主觀下線。因為在複雜的網路環境下，這個sentinel與這個master不通，但是如果master與其他的sentinel都是通的呢？所以是一種“偏見”。

這是依靠的第三種定時：每秒去ping一下週圍的sentinel和Redis。對於slave Redis,可以使用這個主觀下線，因為他不需要進行故障轉移；但是對於master Redis，必須使用客觀下線。

客觀下線

客觀下線：所有sentinel節點對master Redis節點失敗“達成共識”（超過quorum個則統一，quorum可配置）。

這是依靠的第二種定時：每兩秒，sentinel之間進行“商量”（一個 sentinel 可以通過向另一個 sentinel 傳送 SENTINEL is-master-down-by-addr 命令來詢問對方是否認為給定的伺服器已下線。）

對於master redis的下線，必須要達成共識才可以，因為涉及故障轉移，僅僅依靠一個sentinel判斷是不夠的

領導者選舉

當sentinel叢集需要故障轉移的時候會在叢集中選出Leader執行故障轉移操作。sentinel採用了Raft協議實現了sentinel間選舉Leader的演算法，不過也不完全跟論文描述的步驟一致。sentinel叢集執行過程中故障轉移完成，所有sentinel又會恢復平等。Leader僅僅是故障轉移操作出現的角色。

選舉流程

1. 某個sentinel認定master客觀下線的節點後，該sentinel會先看看自己有沒有投過票，如果自己已經投過票給其他sentinel了，在2倍故障轉移的超時時間自己就不會成為Leader。相當於它是一個Follower。
   
2. 如果該sentinel還沒投過票，那麼它就成為Candidate。
   
3. 和Raft協議描述的一樣，成為Candidate，sentinel需要完成幾件事情
   3.1 更新故障轉移狀態為start
   3.2 當前epoch加1，相當於進入一個新term，在sentinel中epoch就是Raft協議中的term。
   3.3 更新自己的超時時間為當前時間隨機加上一段時間，隨機時間為1s內的隨機毫秒數。
   3.4 向其他節點發送is-master-down-by-addr命令請求投票。命令會帶上自己的epoch。
   3.5 給自己投一票，在sentinel中，投票的方式是把自己master結構體裡的leader和leader_epoch改成投給的sentinel和它的epoch。
4. 其他sentinel會收到Candidate的is-master-down-by-addr命令。如果sentinel當前epoch和Candidate傳給他的epoch一樣，說明他已經把自己master結構體裡的leader和leader_epoch改成其他Candidate，相當於把票投給了其他Candidate。投過票給別的sentinel後，在當前epoch內自己就只能成為Follower。
5. Candidate會不斷的統計自己的票數，直到他發現認同他成為Leader的票數超過一半而且超過它配置的quorum（quorum可以參考《redis sentinel設計與實現》）。sentinel比Raft協議增加了quorum，這樣一個sentinel能否當選Leader還取決於它配置的quorum。
6. 如果在一個選舉時間內，Candidate沒有獲得超過一半且超過它配置的quorum的票數，自己的這次選舉就失敗了。
7. 如果在一個epoch內，沒有一個Candidate獲得更多的票數。那麼等待超過2倍故障轉移的超時時間後，Candidate增加epoch重新投票。
8. 如果某個Candidate獲得超過一半且超過它配置的quorum的票數，那麼它就成為了Leader。
9. 與Raft協議不同，Leader並不會把自己成為Leader的訊息發給其他sentinel。其他sentinel等待Leader從slave選出master後，檢測到新的master正常工作後，就會去掉客觀下線的標識，從而不需要進入故障轉移流程。

故障轉移過程

1. 當多個sentinel發現並確認了master有問題
2. 接著會選舉出一個sentinel作為領導
3. 再選舉出一個slave作為master
4. 通知其餘的slave，新的master是誰
5. 通知客戶端一個主從的變化
6. 最後，sentinel會等待舊的master復活，然後將新master成為slave

那麼，如何選擇“合適”的slave節點呢？

1. 選擇slave-priority(slave節點優先順序，人為配置)最高的slave節點，如果存在則返回，不存在則繼續。
2. 其次會選擇複製偏移量最大的slave節點(複製得最完整)，如果存在則返回，不存在則繼續
3. 最後會選擇run_id最小的slave節點(啟動最早的節點)

客戶端實現高可用的基本原理

故障轉移後客戶端無法感知將無法保證正常的使用。所以，實現客戶端高可用的步驟如下:

1. 客戶端獲取sentinel節點集合

1. 客戶端通過sentinel get-master-addr-by-name master-name這個api來獲取對應主節點資訊

1. 客戶端驗證當前獲取的“主節點”是真正的主節點，這樣的目的是為了防止故障轉移期間主節點的變化

1. 客戶端保持和sentinel節點集合的聯絡，即訂閱sentinel節點相關頻道，時刻獲取關於主節點的相關資訊

從上面的模型可以看出，Redis sentinel客戶端只有在初始化和切換主節點時需要和sentinel進行通訊來獲取主節點資訊，所以在設計客戶端時需要將sentinel節點集合考慮成配置（相關節點資訊和變化）發現服務。

需要說明的問題

• 儘可能在不同物理機上和同一個網路部署Redis sentinel的所有節點
• Redis sentinel中的sentinel節點個數應該大於等於3且最好是奇數。（節點數多可以保證高可用）
• Redis sentinel中的資料節點和普通資料節點沒有區別。每個sentinel節點在本質上還是一個Redis例項，只不過和Redis資料節點不同的是，其主要作用是監控Redis資料節點
• 客戶端初始化時連線的是sentinel節點集合，不再是具體的Redis節點，但sentinel只是配置中心不是代理。

更多內容，歡迎關注微信公眾號：全菜工程師小輝。公眾號回覆關鍵詞，領取免費學習資料。

相關推薦