怎樣入門Redis哨兵Sentinel模式

本篇文章為大家展示了怎樣入門Redis哨兵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節點。

• 確認主從關系。

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

作用：

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

> 通過master節點的__sentinel__:hello頻道進行交互，所有sentinel訂閱這個頻道并每2秒向該頻道發布信息

3. 每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節點集合

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

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

4. 客戶端保持和sentinel節點集合的聯系，即訂閱sentinel節點相關頻道，時刻獲取關于主節點的相關信息

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

需要說明的問題

• 盡可能在不同物理機上和同一個網絡部署Redis sentinel的所有節點

• Redis sentinel中的sentinel節點個數應該大于等于3且最好是奇數。（節點數多可以保證高可用）

• Redis sentinel中的數據節點和普通數據節點沒有區別。每個sentinel節點在本質上還是一個Redis實例，只不過和Redis數據節點不同的是，其主要作用是監控Redis數據節點

• 客戶端初始化時連接的是sentinel節點集合，不再是具體的Redis節點，但sentinel只是配置中心不是代理。

上述內容就是怎樣入門Redis哨兵Sentinel模式，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。