Redis 哨兵機制
Redis 哨兵機制
為什麼要有哨兵（sentinel）機制
在 Redis 主從架構中，當主伺服器宕機，需要手動將從伺服器切換為主伺服器，這需要人工干預，不僅費時費力而且還會造成一段時間內服務不可用。
哨兵機制就是為了解決主從複製的缺點，以實現自動故障轉移
什麼是哨兵機制
Redis 的哨兵（Sentinel）系統（由一個或多個 Sentinel 例項組成）用於管理多個 Redis 主伺服器（Master），以及這些主伺服器屬下的所有從伺服器（Slave），並在被監控的主伺服器進入下線狀態時，自動將下線主伺服器（Master）屬下的某個從伺服器（Slave）升級為新的主伺服器（Master），然後由新的主伺服器代替已下線的主伺服器（Master）繼續處理 Redis 客戶端傳送的命令請求。
該系統執行以下三個任務：
-
監控（Monitoring）
哨兵（sentinel）會不斷地檢查你的 Master 和 Slave 是否正常執行。
-
提醒（Notification）
當被監控地某個 Redis 出現問題時，哨兵可以通過 API 向管理員或者其他應用程式傳送通知。
-
自動故障轉移（Automatic failover）
當一個 Master 不能正常工作時，哨兵會開始一次自動故障轉移操作，它會將失效 Master 的其中一個 Slave 升級為新的 Master，並且讓失效的 Master 的其他 slave 改為複製新的 Master；當客戶端試圖連結失效地 Master 時，叢集也會向客戶端返回新的 Master 地址，使得叢集可以使用新的 Master 代替失效地 Master。
哨兵機制的高可用（HA）
原理：哨兵系統監控到有 Redis 主伺服器（Master）出現故障時，將從哨兵系統中選舉一個哨兵（sentinel）作為領導者，由它負責完成故障轉移，從而實現高可用性。
哨兵的實時監控任務
任務1：每個哨兵節點每10 秒會向主節點和從節點發送 info 命令獲取最新地拓撲結構圖，哨兵配置時只需要配置對主節點地監控即可，通過向主節點發送 info，獲取從節點的資訊，並當有新的從節點加入時可以馬上感知到。
任務2：每個哨兵節點每隔 2 秒會向 Redis 資料節點的指定頻道上傳送該哨兵節點對於主節點地判斷以及當前哨兵節點的資訊，同時每個哨兵節點也會訂閱該頻道，來了解其他哨兵節點的資訊及對主節點的判斷，其實就是通過釋出/訂閱來完成的
任務3：每隔 1 秒每個哨兵會向主節點、從節點及其餘哨兵節點發送一次ping命令做一次心跳檢測，這個也是哨兵判斷節點是否正常的重要依據。
主觀下線：根據定時任務 3 對沒有有效回覆的節點做主觀下線處理。
客觀下線：當主觀下線的節點是主節點時，此時該哨兵 3 節點會尋求其他哨兵節點對主伺服器（Master）的判斷，當同意該主伺服器（Master）下線的數量達到配置指定的數量時，此時哨兵節點則認為該主伺服器確實有問題，則將主伺服器標註為進入客觀下線狀態。
領導者哨兵（Sentinel）選舉機制
當一個主伺服器（Master）進入客觀下線狀態時，哨兵系統會進行協商，選舉出一個哨兵領導者，而領導者哨兵的選舉規則如下：
- 每個線上的哨兵節點都可以成為領導者，當有哨兵確認（比如哨兵3）主伺服器（Master）客觀下線時，會向其他哨兵傳送投票請求，要求將自己設定為領導者哨兵；
- 其他哨兵收到投票請求後，遵循先到先得：即最先收到的請求會投票同意，接著收到的請求都將投票拒絕
- 如果哨兵3發現自己在選舉的票數達到半數以上，則選舉勝出，將會成為領導者，否則繼續選舉
故障轉移流程
選舉出領導者哨兵之後，接著就由它完成對下線主伺服器執行故障轉移操作，如下：
故障轉移流程
- 將從伺服器 slave-1 升級為主伺服器（Master）
- 將從伺服器 slave-2 指向新的伺服器（Master）
- 通知 Redis 客戶端主伺服器（Master）已經更換
- 將故障恢復的原主伺服器（Master）變成從伺服器（Slave）
選擇從伺服器升級為主服務的規則
- 過濾掉所有不健康的（下線或者短線），沒有回覆哨兵 ping 響應的從伺服器
- 選擇 slave-priority 從伺服器優先順序最高的
- 優先順序相同則選擇複製偏移量最大的從伺服器（也就是複製資料最完整）
- 偏移量相同則按照執行從伺服器 ID 進行排序，選出其中執行 ID 最小的從伺服器
總結
redis 哨兵的作用
- 監控主伺服器（Master）和從伺服器（Slave）是否正常執行
- 一旦主伺服器（Master）出現故障時，選舉一個領導者哨兵，讓它將從伺服器（Slave）轉換為主伺服器（Master），實現故障轉移