Redis sentinel(哨兵)叢集原理

Redis-Sentinel是Redis官方推薦的高可用性(HA)解決方案，當用Redis做Master-slave的高可用方案時，假如master當機了，Redis-Sentinel在發現master當機後會進行自動切換主從關系。

sentinel的作用

叢集監控：sentinel節點會定期檢查redis狀态，判斷是否故障

故障自動切換:在master發生故障時，實作slave晉升成master，并維護後續正确的主從關系

提供配置:sentinel會将故障轉移的結果通知給用戶端，提供最新的master位址

監控

定時監控 Redis 資料節點

每 10 秒每個 sentinel 向 master、slaves 節點發送 INFO 指令

每 2 秒每個 sentinel 通過 master 節點的 channel(名稱為 __sentinel__:hello) 交換資訊(pub/sub)，資訊包括：

每 1 秒每個 sentinel 對其他 sentinel 和 redis master, slave 發送 PING 指令,用于心跳檢測,作為節點存活的判斷依據

主觀下線和客觀下線（發現故障）

主觀下線（subjectively down，SDOWN）：目前 Sentinel 執行個體認為某個 redis 服務為”不可用”狀态。Sentinel 向 redis master 資料節點發送消息後 30s（down-after-milliseconds） 内沒有收到有效回複（+PONG、-LOADING 或者 -MASTERDOWN），Sentinel 會将 master 标記為下線（打開 master 結構中 flags 的 SRI_S_DOWN 标記）

客觀下線（objectively down，ODOWN）：多個 Sentinel 執行個體都認為 master 處于 SDOWN 狀态，那麼此時 master 将處于 ODOWN， ODOWN可以簡單了解為master已經被叢集确定為”不可用”,将會開啟故障轉移機制。向其他 sentinel 節點發送 sentinel is-master-down-by-addr 消息詢問資料節點情況，得知達到 quorum 數量的 sentinel 節點認為資料節點已經下線

故障切換過程

發現故障(客觀下線) --> sentinel選舉  --> 選擇合适的slave成為master --> 故障轉移

Sentinel leader選舉

在确定客觀下線後，開始進行leader選舉

每個線上的 sentinel 節點都有資格成為 leader。 當确認主節點客觀下線時候會向其他 sentinel 節點發送sentinel is-master-down-by-addr指令,要求将自己設定為leader。

每個 sentinel 節點都隻能投出一票,當節點得票數超過max(quorum,sentinels/2 +1)，則被選舉成leader.

正常情況下哪個 sentinel 節點最先确認 master 客觀下線哪個 sentinel 節點就會成為執行故障轉移的 leader

選擇合适的slave成為master

健康的節點：線上的,最近成功通信過的（5s 内回複過 PING 指令）

資料比較新的（與 master 失聯時間不超過 10*down-after-milliseconds）

slave-priority（slave節點優先級）最高的slave節點

複制偏移量最大的 slave 節點（複制的最完整）

選擇 runId 最小的 slave 節點（啟動最早的節點）

故障轉移

1.在合适的slave節點上執行 SLAVEOF no one指令讓其成為新的 master 節點。

2.向剩餘的 slave 節點發送 SLAVEOF 新master 指令，讓他們成為新 master 節點的 slave 節點

3.讓剩餘的 slave 複制新 master 的資料，通過配置 sentinel parallel-syncs 規定了每次向新的主節點發起複制操作的從節點個數。

4.更新原來master 節點配置為 slave 節點,并保持對其進行關注,一旦這個節點重新恢複正常後,會指令它去複制新的master節點資訊

全部故障轉移工作完成後，Leader Sentinel 就會推送 +switch-master 消息，同時重置 master，重置操作會釋放掉原來 master 全部的 slave 對象和監聽該 master 的其他 Sentinel 對象，然後建立出新的 slave 對象

主要配置說明

bind 192.168.56.111
port 26379
daemonize yes
dir /home/redis/redis_26379
logfile sentinel.log

#指定監聽的叢集名,主節點IP,Port,客觀下線最低票數
sentinel monitor mymaster 10.10.11.146 6388 2

# 主節點的密碼配置
sentinel auth-pass mymaster 123456

# 判定節點不可達的時間，機關是毫秒
sentinel down-after-milliseconds mymaster 5000

# 故障轉移後，每次向新的主節點發起複制的從節點的個數,建議設定為1，不要并發
sentinel parallel-syncs mymaster 1

# 故障轉移的逾時時間
sentinel failover-timeout mymaster 50000  
           

常見問題

異步複制導緻的資料丢失：可能有部分資料還沒複制到slave,master就當機了此時這部分資料就丢失了。

redis 服務腦裂導緻的資料丢失:某個 master 所在機器突然網絡故障跟其他 slave 機器不能連接配接但是實際上 master 還運作着。此時哨兵可能就會認為 master 當機了然後開啟選舉将其他 slave 切換成了master.

這個時候叢集裡就會有兩個master也就是所謂的腦裂。此時雖然某個 slave 被切換成了 master,但是 client 還沒來得及切換到新的master,還繼續寫向舊 master 的資料就丢失了。因為舊 master 再次恢複的時候會被作為一個 slave 挂到新的 master 上去,自己的資料會清空重新從新的 master 複制資料。

這兩個參數可以盡量保證資料不丢失：min-slaves-to-write 1        ； min-slaves-max-lag 10