redis高可用---sentinal叢集

1.哨兵的介紹

哨兵是redis叢集架構中非常重要的一個元件，主要功能如下

（1）叢集監控，負責監控redis master和slave程序是否正常工作

（2）消息通知，如果某個redis執行個體有故障，那麼哨兵負責發送消息作為報警通知給管理者

（3）故障轉移，如果master node挂掉了，會自動轉移到slave node上

（4）配置中心，如果故障轉移發生了，通知client用戶端新的master位址

2.哨兵的核心知識

（1）哨兵至少需要3個執行個體，來保證自己的健壯性

（2）哨兵 + redis主從的部署架構，是不會保證資料零丢失的，隻能保證redis叢集的高可用性

2.1Sentinel叢集選舉Leader

如果需要從redis叢集選舉一個節點為主節點，首先需要從Sentinel叢集中選舉一個Sentinel節點作為Leader。

每一個Sentinel節點都可以成為Leader，當一個Sentinel節點确認redis叢集的主節點主觀下線後，會請求其他Sentinel節點要求将自己選舉為Leader。被請求的Sentinel節點如果沒有同意過其他Sentinel節點的選舉請求，則同意該請求(選舉票數+1)，否則不同意。

如果一個Sentinel節點獲得的選舉票數達到Leader最低票數(quorum和Sentinel節點數/2+1的最大值)，則該Sentinel節點選舉為Leader；否則重新進行選舉。

3.哨兵主從架構資料流失問題,異步複制和叢集腦裂

3.1 異步複制導緻的資料丢失

因為master->slave是異步複制的，是以slave有可能資料還未複制過來，master就已經當機了，這時slave資料就存在流失

3.2 腦裂導緻的資料丢失

腦裂，也就是說，master所在機器突然脫離了正常的網絡，導緻跟其他slave機器不能連接配接，但是實際上master還運作着

此時哨兵就誤以為master當機，哨兵就可以選舉，使得其他slave切換成master

但是用戶端跟舊的master是連結上的，用戶端還在向舊master寫資料，而新的master這些資料沒有了，當舊的master恢複了，變成新的master的slave，自己資料就會清空，重新從新的master複制資料，是以資料流失

3.3 解決異步複制和腦裂導緻的資料丢失

min-slaves-to-write 1

min-slaves-max-lag 10

這個配置，意味着至少一台slave不能超過10s，如果slave都超過10s,這個時候，master就不會在接收用戶端請求，這樣就可以減少異步複制和腦袋流失的資料，最多就丢失10s資料

（1）減少異步複制的資料丢失

有了min-slaves-max-lag這個配置，就可以確定說，一旦slave複制資料和ack延時太長，就認為可能master當機後損失的資料太多了，那麼就拒絕寫請求，這樣可以把master當機時由于部分資料未同步到slave導緻的資料丢失降低的可控範圍内

（2）減少腦裂的資料丢失

如果一個master出現了腦裂，跟其他slave丢了連接配接，那麼上面兩個配置可以確定說，如果不能繼續給指定數量的slave發送資料，而且slave超過10秒沒有給自己ack消息，那麼就直接拒絕用戶端的寫請求

這樣腦裂後的舊master就不會接受client的新資料，也就避免了資料丢失

上面的配置就確定了，如果跟任何一個slave丢了連接配接，在10秒後發現沒有slave給自己ack，那麼就拒絕新的寫請求

是以在腦裂場景下，最多就丢失10秒的資料

4 哨兵核心原理和slave選舉

4.1、sdown和odown轉換機制

sdown和odown兩種失敗狀态

sdown是主觀當機，就一個哨兵如果自己覺得一個master當機了，那麼就是主觀當機

odown是客觀當機，如果quorum數量的哨兵都覺得一個master當機了，那麼就是客觀當機

sdown達成的條件很簡單，如果一個哨兵ping一個master，超過了is-master-down-after-milliseconds指定的毫秒數之後，就主觀認為master當機

sdown到odown轉換的條件很簡單，如果一個哨兵在指定時間内，收到了quorum指定數量的其他哨兵也認為那個master是sdown了，那麼就認為是odown了，客觀認為master當機

4.2、哨兵叢集的自動發現機制

哨兵互相之間的發現，是通過redis的pub/sub系統實作的，每個哨兵都會往__sentinel__:hello這個channel裡發送一個消息，這時候所有其他哨兵都可以消費到這個消息，并感覺到其他的哨兵的存在

每隔兩秒鐘，每個哨兵都會往自己監控的某個master+slaves對應的__sentinel__:hello channel裡發送一個消息，内容是自己的host、ip和runid還有對這個master的監控配置

每個哨兵也會去監聽自己監控的每個master+slaves對應的__sentinel__:hello channel，然後去感覺到同樣在監聽這個master+slaves的其他哨兵的存在

每個哨兵還會跟其他哨兵交換對master的監控配置，互相進行監控配置的同步

4.3、slave配置的自動糾正

哨兵會負責自動糾正slave的一些配置，比如slave如果要成為潛在的master候選人，哨兵會確定slave在複制現有master的資料; 如果slave連接配接到了一個錯誤的master上，比如故障轉移之後，那麼哨兵會確定它們連接配接到正确的master上

4.4、slave->master選舉算法

如果一個master被認為odown了，而且majority哨兵都允許了主備切換，那麼某個哨兵就會執行主備切換操作，此時首先要選舉一個slave來

會考慮slave的一些資訊

（1）跟master斷開連接配接的時長

（2）slave優先級

（3）複制offset

（4）run id

如果一個slave跟master斷開連接配接已經超過了down-after-milliseconds的10倍，外加master當機的時長，那麼slave就被認為不适合選舉為master

(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

接下來會對slave進行排序

（1）按照slave優先級進行排序，slave priority（配置從的優先級）越低，優先級就越高

（2）如果slave priority相同，那麼看replica offset（副本偏移量），哪個slave複制了越多的資料，offset越靠後，優先級就越高

4.5、quorum和majority

每次一個哨兵要做主備切換，首先需要quorum數量的哨兵認為odown，然後選舉出一個哨兵來做切換，這個哨兵還得得到majority哨兵的授權，才能正式執行切換

如果quorum < majority，比如5個哨兵，majority就是3，quorum設定為2，那麼就3個哨兵授權就可以執行切換

但是如果quorum >= majority，那麼必須quorum數量的哨兵都授權，比如5個哨兵，quorum是5，那麼必須5個哨兵都同意授權，才能執行切換

4.6、configuration epoch

哨兵會對一套redis master+slave進行監控，有相應的監控的配置

執行切換的那個哨兵，會從要切換到的新master（salve->master）那裡得到一個configuration epoch，這就是一個version号，每次切換的version号都必須是唯一的

如果第一個選舉出的哨兵切換失敗了，那麼其他哨兵，會等待failover-timeout時間，然後接替繼續執行切換，此時會重新擷取一個新的configuration epoch，作為新的version号

4.7、configuraiton傳播

哨兵完成切換之後，會在自己本地更新生成最新的master配置，然後同步給其他的哨兵，就是通過之前說的pub/sub消息機制

這裡之前的version号就很重要了，因為各種消息都是通過一個channel去釋出和監聽的，是以一個哨兵完成一次新的切換之後，新的master配置是跟着新的version号的

其他的哨兵都是根據版本号的大小來更新自己的master配置的（3）如果上面兩個條件都相同，那麼選擇一個run id比較小的那個slave