Redis哨兵（Sentinel）模式快速入門
- 2019 年 10 月 3 日
- 筆記
更多內容，歡迎關注微信公眾號：全菜工程師小輝。公眾號回復關鍵詞，領取免費學習資料。
當主伺服器宕機後，需要手動把一台從伺服器切換為主伺服器，這就需要人工干預，費事費力，還會造成一段時間內服務不可用。 所以更多時候，我們優先考慮哨兵(sentinel) 模式。
Redis sentinel是Redis高可用實現方案：故障發現、故障自動轉移、配置中心、客戶端通知。從Redis的2.6版本開始提供的，但是當時這個版本的模式是不穩定的，直到Redis的2.8版本以後，這個哨兵模式才穩定下來，在生產環境中，如果想要使用Redis的哨兵模式，也會盡量使用Redis的2.8版本之後的版本。
哨兵雖然有一個單獨的可執行文件Redis-sentinel ，但實際上它只是一個運行在特殊模式下的 Redis伺服器，你可以在啟動一個普通Redis伺服器時通過給定--sentinel選項來啟動哨兵，哨兵的一些設計思路和zookeeper非常類似。
sentinel的定時任務
sentinel機制中有三種重要的定時任務。
- 每10秒每個sentinel對master和slave執行info
作用：
- 發現slave節點。
- 確認主從關係。
- 每2秒每個sentinel通過master節點的channel交換資訊(pub/sub)
作用：
- 互相通訊掌握節點的資訊和自身資訊，可以感知新加入的sentinel
通過master節點的__sentinel__:hello頻道進行交互，所有sentinel訂閱這個頻道並每2秒向該頻道發布資訊
- 每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僅僅是故障轉移操作出現的角色。
選舉流程
- 某個sentinel認定master客觀下線的節點後，該sentinel會先看看自己有沒有投過票，如果自己已經投過票給其他sentinel了，在2倍故障轉移的超時時間自己就不會成為Leader。相當於它是一個Follower。
- 如果該sentinel還沒投過票，那麼它就成為Candidate。
- 和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。 - 其他sentinel會收到Candidate的is-master-down-by-addr命令。如果sentinel當前epoch和Candidate傳給他的epoch一樣，說明他已經把自己master結構體里的leader和leader_epoch改成其他Candidate，相當於把票投給了其他Candidate。投過票給別的sentinel後，在當前epoch內自己就只能成為Follower。
- Candidate會不斷的統計自己的票數，直到他發現認同他成為Leader的票數超過一半而且超過它配置的quorum（quorum可以參考《redis sentinel設計與實現》）。sentinel比Raft協議增加了quorum，這樣一個sentinel能否當選Leader還取決於它配置的quorum。
- 如果在一個選舉時間內，Candidate沒有獲得超過一半且超過它配置的quorum的票數，自己的這次選舉就失敗了。
- 如果在一個epoch內，沒有一個Candidate獲得更多的票數。那麼等待超過2倍故障轉移的超時時間後，Candidate增加epoch重新投票。
- 如果某個Candidate獲得超過一半且超過它配置的quorum的票數，那麼它就成為了Leader。
- 與Raft協議不同，Leader並不會把自己成為Leader的消息發給其他sentinel。其他sentinel等待Leader從slave選出master後，檢測到新的master正常工作後，就會去掉客觀下線的標識，從而不需要進入故障轉移流程。
故障轉移過程
- 當多個sentinel發現並確認了master有問題
- 接著會選舉出一個sentinel作為領導
- 再選舉出一個slave作為master
- 通知其餘的slave，新的master是誰
- 通知客戶端一個主從的變化
- 最後，sentinel會等待舊的master復活，然後將新master成為slave
那麼，如何選擇「合適」的slave節點呢？
- 選擇slave-priority(slave節點優先順序，人為配置)最高的slave節點，如果存在則返回，不存在則繼續。
- 其次會選擇複製偏移量最大的slave節點(複製得最完整)，如果存在則返回，不存在則繼續
- 最後會選擇run_id最小的slave節點(啟動最早的節點)
客戶端實現高可用的基本原理
故障轉移後客戶端無法感知將無法保證正常的使用。所以，實現客戶端高可用的步驟如下:
- 客戶端獲取sentinel節點集合
- 客戶端通過sentinel get-master-addr-by-name master-name這個api來獲取對應主節點資訊
- 客戶端驗證當前獲取的「主節點」是真正的主節點，這樣的目的是為了防止故障轉移期間主節點的變化
- 客戶端保持和sentinel節點集合的聯繫，即訂閱sentinel節點相關頻道，時刻獲取關於主節點的相關資訊
從上面的模型可以看出，Redis sentinel客戶端只有在初始化和切換主節點時需要和sentinel進行通訊來獲取主節點資訊，所以在設計客戶端時需要將sentinel節點集合考慮成配置（相關節點資訊和變化）發現服務。
需要說明的問題
- 儘可能在不同物理機上和同一個網路部署Redis sentinel的所有節點
- Redis sentinel中的sentinel節點個數應該大於等於3且最好是奇數。（節點數多可以保證高可用）
- Redis sentinel中的數據節點和普通數據節點沒有區別。每個sentinel節點在本質上還是一個Redis實例，只不過和Redis數據節點不同的是，其主要作用是監控Redis數據節點
- 客戶端初始化時連接的是sentinel節點集合，不再是具體的Redis節點，但sentinel只是配置中心不是代理。
更多內容，歡迎關注微信公眾號：全菜工程師小輝。公眾號回復關鍵詞，領取免費學習資料。
