1 哨兵的作用

哨兵是redis集群架構中非常重要的一個組件，主要功能如下：?

集群監控：負責監控redis master和slave進程是否正常工作?

消息通知：如果某個redis實例有故障，那么哨兵負責發送消息作為報警通知給管理員?

故障轉移：如果master node掛掉了，會自動轉移到slave node上?

配置中心：如果故障轉移發生了，通知client客戶端新的master地址

2 哨兵的核心知識

故障轉移時，判斷一個master node是宕機了，需要大部分的哨兵都同意才行，涉及到了分布式選舉的問題

哨兵至少需要3個實例，來保證自己的健壯性

哨兵 + redis主從的部署架構，是不會保證數據零丟失的，只能保證redis集群的高可用性

3 sdown和odown

sdown和odown兩種失敗狀態

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

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

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

odown達成的條件：如果一個哨兵在指定時間內，收到了quorum指定數量的其他哨兵也認為那個master是sdown了，那么就認為是odown了，客觀認為master宕機

4 quorum和majority

quorum：確認odown的最少的哨兵數量

majority：授權進行主從切換的最少的哨兵數量

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

如果quorum < majority，比如5個哨兵，majority就是3，quorum設置為2，那么就3個哨兵授權就可以執行切換，但是如果quorum >= majority，那么必須quorum數量的哨兵都授權，比如5個哨兵，quorum是5，那么必須5個哨兵都同意授權，才能執行切換

5 為什么哨兵至少3個節點

哨兵集群必須部署2個以上節點。如果哨兵集群僅僅部署了個2個哨兵實例，那么它的majority就是2（2的majority=2，3的majority=2，5的majority=3，4的majority=2），如果其中一個哨兵宕機了，就無法滿足majority>=2這個條件，那么在master發生故障的時候也就無法進行主從切換。

6 腦裂以及redis數據丟失

主備切換的過程，可能會導致數據丟失?
（1）異步復制導致的數據丟失?
因為master -> slave的復制是異步的，所以可能有部分數據還沒復制到slave，master就宕機了，此時這些部分數據就丟失了?
（2）腦裂導致的數據丟失?
腦裂，也就是說，某個master所在機器突然脫離了正常的網絡，跟其他slave機器不能連接，但是實際上master還運行著?
此時哨兵可能就會認為master宕機了，然后開啟選舉，將其他slave切換成了master，這個時候，集群里就會有兩個master，也就是所謂的腦裂。?
此時雖然某個slave被切換成了master，但是可能client還沒來得及切換到新的master，還繼續寫向舊master的數據可能也丟失了，因此舊master再次恢復的時候，會被作為一個slave掛到新的master上去，自己的數據會清空，重新從新的master復制數據

7 如何盡可能減少數據丟失

下面兩個配置可以減少異步復制和腦裂導致的數據丟失：

1 2	min-slaves-to-write?1 min-slaves-max-lag?10

　　

解釋：要求至少有1個slave，數據復制和同步的延遲不能超過10秒，如果說一旦所有的slave，數據復制和同步的延遲都超過了10秒鐘，那么這個時候，master就不會再接收任何請求了?
（1）減少異步復制的數據丟失?
有了min-slaves-max-lag這個配置，就可以確保說，一旦slave復制數據和ack延時太長，就認為可能master宕機后損失的數據太多了，那么就拒絕寫請求，這樣可以把master宕機時由于部分數據未同步到slave導致的數據丟失降低的可控范圍內?
（2）減少腦裂的數據丟失?
如果一個master出現了腦裂，跟其他slave丟了連接，那么上面兩個配置可以確保說，如果不能繼續給指定數量的slave發送數據，而且slave超過10秒沒有給自己ack消息，那么就直接拒絕客戶端的寫請求，這樣腦裂后的舊master就不會接受client的新數據，也就避免了數據丟失?
上面的配置就確保了，如果跟任何一個slave丟了連接，在10秒后發現沒有slave給自己ack，那么就拒絕新的寫請求。
因此在腦裂場景下，最多就丟失10秒的數據

8 哨兵集群的自動發現機制

哨兵互相之間的發現，是通過redis的pub/sub系統實現的，每個哨兵都會往sentinel:hello這個channel里發送一個消息，這時候所有其他哨兵都可以消費到這個消息，并感知到其他的哨兵的存在?
每隔兩秒鐘，每個哨兵都會往自己監控的某個master+slaves對應的sentinel:hello channel里發送一個消息，內容是自己的host、ip和runid還有對這個master的監控配置?
每個哨兵也會去監聽自己監控的每個master+slaves對應的sentinel:hello channel，然后去感知到同樣在監聽這個master+slaves的其他哨兵的存在?
每個哨兵還會跟其他哨兵交換對master的監控配置，互相進行監控配置的同步

9 slave配置的自動糾正

哨兵會負責自動糾正slave的一些配置，比如slave如果要成為潛在的master候選人，哨兵會確保slave在復制現有master的數據; 如果slave連接到了一個錯誤的master上，比如故障轉移之后，那么哨兵會確保它們連接到正確的master上

10 master選舉算法

如果一個master被認為odown了，而且majority哨兵都允許了主備切換，那么某個哨兵就會執行主備切換操作，此時首先要選舉一個slave來。?
選舉的時候會考慮slave的一些信息：?

跟master斷開連接的時長?

slave優先級?

復制offset?

run id?

如果一個slave跟master斷開連接已經超過了down-after-milliseconds的10倍，外加master宕機的時長，那么slave就被認為不適合選舉為master，計算公式如下：

1	(down-after-milliseconds *?10) + milliseconds_since_master_is_in_SDOWN_state

　　

接下來會對slave進行排序?
（1）按照slave優先級進行排序，slave priority越低，優先級就越高?
（2）如果slave priority相同，那么看replica offset，哪個slave復制了越多的數據，offset越靠后，優先級就越高?
（3）如果上面兩個條件都相同，那么選擇一個run id比較小的那個slave

11 configuration epoch

哨兵會對一套redis master+slave進行監控，有相應的監控的配置?
執行切換的那個哨兵，會從要切換到的新master（salve->master）那里得到一個configuration epoch，這就是一個version號，每次切換的version號都必須是唯一的?
如果第一個選舉出的哨兵切換失敗了，那么其他哨兵，會等待failover-timeout時間，然后接替繼續執行切換，此時會重新獲取一個新的configuration epoch，作為新的version號

12 configuraiton傳播

哨兵完成切換之后，會在自己本地更新生成最新的master配置，然后同步給其他的哨兵，就是通過之前說的pub/sub消息機制?
這里之前的version號就很重要了，因為各種消息都是通過一個channel去發布和監聽的，所以一個哨兵完成一次新的切換之后，新的master配置是跟著新的version號的?
其他的哨兵都是根據版本號的大小來更新自己的master配置的

總結

以上是生活随笔為你收集整理的redis哨兵相关详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。