【歪裏諧說】3 Redis哨兵

文章內容輸出來源：拉勾教育Java高薪訓練營，做者：孫裏

【歪裏諧說】1 JVM內存結構 https://my.oschina.net/u/4033707/blog/4444869

【歪裏諧說】2 Java容器 http://www.javashuo.com/article/p-ntqliopi-vd.html

前言

你們好，下期終於來了。此次咱們來記憶下Redis中出鏡率比較高的哨兵機制。

說實話哨兵機制的相關課程我已經聽過好多遍了，本身也複述過，可是時間一長仍是記不住。自從我想到了這個很是貼近平常的案例，時不時的回憶一下，基本上就忘不了了。

簡介

咱們像往常同樣，先來回顧下相關的基本概念。

本次的概念比較多，簡單分下類：

• Redis哨兵模式簡介

• 執行流程

• 檢測下線狀態

• 哨兵領導者選舉

• 故障轉移

Redis哨兵模式簡介

• 哨兵（Sentinel）是Redis的一個比較簡單的高可用解決方案，經過配合主從模式實現。

• 哨兵是一個特殊的Redis服務器，不會進行持久化。

• 由多個哨兵實例組成集羣，能夠監視多組主服務器和其從服務器。

• 當主服務器進入下線狀態時，哨兵能夠將該主服務器下的某一從服務器升級爲主服務器繼續提供服務，從而保證Redis的高可用。

下圖爲哨兵結構圖：哨兵集羣 + 服務節點集羣（Master主節點 + Slave從節點）。

實線部分爲直接通訊，虛線部分爲間接通訊。哨兵彼此之間只建立命令鏈接，而不建立訂閱鏈接，由於哨兵經過訂閱主服務器或從服務器，就能夠感知到新的哨兵的加入，而一旦新哨兵加入後，相互感知的哨兵經過命令鏈接來通訊就能夠了。

執行流程

• 哨兵實例啓動後，每一個實例會建立兩個連向服務器的網絡鏈接。

  • 命令鏈接：用於向主服務器發送命令，並接收響應

  • 訂閱鏈接：用於訂閱主服務器__sentinel__:hello頻道

• 執行過程當中包含三個方面的處理：檢測服務下線狀態、哨兵領導者選舉、服務故障轉移

檢測下線狀態

分爲主觀下線狀態和客觀下線狀態。

• 主觀下線狀態

哨兵每秒1次向全部與它創建了命令鏈接的實例（主服務器、從服務器和其餘哨兵）發送PING命令，如下兩種狀況即爲主觀下線（SDown）：

運行狀態錯誤

實例在規定的毫秒（down-after-milliseconds）內返回無效回覆（除了+PONG、-LOADING、-MASTERDOWN外）。

超時

實例在規定的毫秒（down-after-milliseconds）內無回覆。

• 客觀下線狀態

當一個哨兵將一個主服務器判斷爲主觀下線後哨兵會向同時監控這個主服務器的全部其餘哨兵發送查詢命令。 判斷它們是否也認爲主服務器下線。若是達到哨兵配置中的規定數量（Quorum數量）的哨兵實例都判斷主服務器爲主觀下線，則該主服務器就會被斷定爲客觀下線（ODown）。

下圖爲認定服務下線的整個流程：

哨兵領導者選舉

當一個主服務器被斷定爲客觀下線後，監視這個主服務器的全部哨兵會經過選舉算法（Raft），選出一個哨兵的領導者(Leader) 去執行故障轉移操做。

Raft協議（略）： Raft協議是用來解決分佈式系統一致性問題的協議。

選舉流程：

1. 某哨兵認定主服務器客觀下線後，若是已經投過票給其餘哨兵，在必定時間內本身就不會成爲領導者。

2. 若是該哨兵還沒投過票，那麼它就成爲候選者（Candidate）。

3. 哨兵須要完成幾件事情：

（1）更新故障轉移狀態爲start。

（2）當前週期（Epoch）加1，也就是進入新一輪投票，向其餘節點發送命令（is-master-down-by-addr）請求投票。命令會帶上本身的週期（Epoch） 。

（3）給本身投一票，投票信息包括leader、leader_epoch。

4. 當其它哨兵收到此命令時，經過判斷週期，能夠贊成或者拒絕它成爲領導者。由於只接收大於本身上一次週期的請求。

5. 候選者（Candidate）會不斷的統計本身的票數，直到他發現認同他成爲l領導者的票數超過一半並且超過它配置的規定數量（Quorum），這時它就成爲了領導者。

6. 若是出現多個領導者，則等待一段時間從新選舉。

7. 其餘哨兵等待領導者選出主服務器後，檢測到新的主服務器正常工做後，就會去掉客觀下線的標識。

8. 若是原來下線的服務器恢復了，就只能先成爲從服務器，做爲下次故障轉移的備份。

如圖所示：

故障轉移

選出的哨兵領導者會對下線的主服務器執行故障轉移操做，主要有四個步驟：

1. 選出新的主服務器

   會將失效主服務器（Master）的其中一個從服務器（Slave） 升級爲新的主服務器（Master）。

2. 關聯新的主服務器

   讓失效主服務器（Master）的其餘從服務器（Slave）改成複製新的主服務器（Master）。

3. 配置自動更新

   主服務器（Master）和從服務器（Slave）切換後， 主服務器（Master）的redis.conf 、從服務器（Slave）的redis.conf 和sentinel.conf 的配置文件的內容都會發生相應的改變，即， 主服務器（Master）的redis.conf配置文件中會多一行replicaof 的配置， sentinel.conf 的監控目標會隨之調換。

4. 集羣會向客戶端返回新的主服務器地址

   當客戶端試圖鏈接失效的主服務器（Master）時，集羣也會向客戶端返回新主服務器（Master）的地址，使得集羣可使用如今的主服務器（Master）替換失效節點。

哨兵領導者根據如下規則從客觀下線的主服務器的從服務器中選擇出新的主服務器。

1. 過濾掉主觀下線的節點

2. 選擇優先級最高的節點

   選擇slave-priority最高的節點，若是有則返回，沒有就繼續選擇。

3. 選擇複製數據最多的節點

   選擇出複製偏移量最大的節點，由於複製偏移量越大則數據複製的越完整，若是有就返回了，沒有就繼續。

4. 選擇最穩定的節點（run_id）

   選擇run_id最小的節點，由於run_id越小說明重啓次數越少。

定時任務

類比

通過上邊這麼多概念的回顧，終於到了最重要的舉栗子階段。

在線教育平臺在每次上課的時候爲了不直播事故（直播過程當中講師離線，沒法完成直播的狀況）、評估課程（考覈講師）和維護課堂秩序（禁言聊天室）等，通常都會設置課程監察人員對在線課程進行實時監控。

因此咱們想象拉勾直播的場景，把他們分爲兩組：

• 哨兵集羣：課監組，由監聽提供服務的講師狀態的課程輔導人員組成。

  包括：課程顧問姐姐、美班班-小竹子、偷學講師課程的導師-老可樂。

• 服務器集羣：講課組，由提供授課服務的講師組成。

  包括：應顛老師、老貓老師、還有新來的見習老師。

咱們按照這個類比從新再認識下剛纔講的概念。

課監模式簡介

• 課監是直播課程的一個比較簡單的高可用解決方案，經過配合主副講師模式實現。
• 課監是一個特殊的直播人員，不會進行課程講解。
• 由多個課監人員組成集羣，能夠監視多個直播課程。
• 當主講師進入離線狀態時，課監能夠將該主講師下的某一副講師升級爲主講師繼續提供授課服務，從而保證直播課程的高可用。

下圖爲哨兵結構圖：課監組+ 授課講師組（Master主講師 + Slave副講師）。

監課流程

• 課監人員上線後，每一個人員會經過兩種方式監控直播課程。
  • 溝通模式（命令連接）：用於向主講師發送消息，溝通課程中的各類問題，並接收響應
  • 關注模式（訂閱連接）：關注該直播課堂房間，能夠觀察到其餘關注者（其餘課監人員）
• 監課過程當中包含三個方面的處理：檢測講師下線狀態、課監領導者選舉、服務故障轉移。

檢測下線狀態

分爲主觀下線狀態和客觀下線狀態。

• 主觀下線狀態

課監人員實時（每秒）觀察全部須要被監課的直播課堂，如下兩種狀況即爲主觀下線（SDown）：

直播狀態錯誤

講師離崗、授課內容不符

超時

無講師影音信號，或者嚴重延遲

• 客觀下線狀態

當一個課監人員將一個主講師判斷爲主觀下線後會向同時監控這個主講師的全部其餘課監人員發送詢問。 判斷其餘人是否也認爲主講師下線。若是達到課監要求中的規定數量（Quorum數量）的課監人員都判斷主講師爲主觀下線，則該主講師就會被斷定爲客觀下線（ODown）。

課監領導者選舉

當一個主講師被斷定爲客觀下線後，監視這個主講師的全部課監人員會經過選舉算法（Raft），選出一個課監的領導者(Leader) 去執行故障轉移操做。

Raft協議（略）： Raft協議是用來解決分佈式系統一致性問題的協議。

選舉流程：

這個選舉流程你們本身對號入座地想象一下吧（主要是我懶得寫了）。要是想問爲何要選課監領導者呢？你能夠理解成總要有人要處理直播事故，總要對處理的過程和結果負責。可是這也算工做業績的一方面，因此你們並不拒絕，反而會爭先取得領導者角色，爭取升職加薪，一步一步地走上人生巔峯。而講師組的人也是如此，也是要爭上游。不然有一次不靠譜，就只能被其餘人踩在腳下，充當備胎的角色。

故障轉移

選出的課監領導者會對下線的主講師執行故障轉移操做，主要有四個步驟：

1. 選出新的主講師

   會將失效主講師（Master）的其中一個副講師（Slave） 升級爲新的主講師（Master）。

2. 關注新的主講師

   讓失效主講師（Master）的其餘副講師（Slave）改成關注新的主講師（Master）。

   這裏注意下複製這個概念。Redis中是爲了各個節點之間數據同步，而授課講師之間則是爲了同步講課內容，方便在替換上位的時候能夠立刻接着前任的內容繼續講。

3. 配置自動更新

   主講師（Master）和副講師（Slave）切換後， 他們的通信錄或者說是直播課堂的人員名單和崗位角色會隨之變化。能夠想象成是課監人員更新後發送給他們的。

4. 課監組會向聽課學員的客戶端返回新的主講師地址

   當學員試圖鏈接失效的主講師（Master）時，課監組也會向學員返回新主講師（Master）的地址。

   這裏注意下地址這個概念。能夠理解成每一個講師都是在網上異地參加直播活動，若是主講師失效，那麼其餘人要重開新的直播房間，直播課程地址也會隨之改變。因此須要課監人員及時通知學員更換。

課監領導者根據如下規則從客觀下線的主講師的副講師中選擇出新的主講師。

1. 過濾掉主觀下線的講師

2. 選擇優先級最高的講師

   選擇排名最高的講師，好比有經驗的講師和新來的實習講師中優先選擇有經驗的，若是有則返回，沒有就繼續選擇。

3. 選擇關注直播內容最多的講師

   選擇出觀看時間最長，觀看內容最新的講師，由於越新越多，再接着講時花費在溝通上的時間越少。若是有就返回了，沒有就繼續。

4. 選擇最穩定的節點

   選擇以往出現直播事故次數最少的講師，說明講師本人和其環境越穩定。

三個定時任務

1. 溝通模式（命令連接，10秒1次）

   用於向主講師發送消息，溝通課程中的各類問題，並接收響應

2. 關注模式（訂閱連接，2秒1次）

   關注該直播課堂房間，能夠觀察到其餘關注者（其餘課監人員）

3. 監控模式（心跳連接，每秒1次）

   實時觀看直播課程，進行講師是否下線的判斷。

總結

看完上邊一坨一坨的概念是否是仍是有點亂？那咱再濃縮一下吧。

其實最根本的思路就是有一羣監工隨時監控着另外一羣人，看看被監控的那羣人的頭兒有沒有好好幹活兒。要是沒有就內部先商量出一個管事兒的監工，而後這個監工再從被管着的人羣裏選出一個替代那個很差好乾活兒的人。

好了，若是你能熟記這個模型，而後再深刻學習下真正的概念，應該就離掌握不遠了。

最後感謝幾位客串出場的拉勾老師和工做人員。