1.redis哨兵模式的前言：

一年一度的問題來了，為啥子要用redis的哨兵模式的呢？
簡單粗暴的理解下子，順帶開個玩笑，沒有理解好，還望不要見笑；

其實redis的哨兵模式，個人理解：只是說法搞大上一點，說的不高級點，和皇帝登基道理差不多【皇帝老頭掛了，太子登基，其中有幾個機制就是謀權篡位了，1太子覺得皇帝老頭要掛了，這就是sdown，總共有三個太子，一致認為皇帝老頭子掛了就轉成了odown，達成三個太子選舉，三個太子需要有其中的一個太子登基成為皇帝老頭】

2.redis哨兵架構的相關基礎知識

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

1.集群監控，負責監控redis master和slave進程是否能正常工作；
2.消息通知，如果某個redis實例有故障，那么哨兵負責發送消息作為報警通知給管理員 ；
3.故障轉移，如果master node掛掉了，會自動轉移到slave node上 ；
4.配置中心，如果故障轉移發生了，通知client客戶端新的master地址；

redis哨兵的一些好處和功能：

· 哨兵本身也是分布式的，作為一個哨兵集群去運行，互相協同工作； · 故障轉移時，判斷一個master
node是宕機了，需要大部分的哨兵都同意才行，涉及到了分布式選舉的問題 ； ·
即使部分哨兵節點掛掉了，哨兵集群還是能正常工作的，因為如果一個作為高可用機制重要組成部分的故障轉移系統本身是單點的，那就很坑爹了 ； ·
目前采用的是sentinel 2版本，對已1來說，重寫了很多代碼，主要是讓故障轉移的機制和算法變得更加健壯和簡單

哨兵的核心知識點：
1.為什么搭建redis哨兵集群至少要三個節點呢？why？

· 哨兵集群必須要部署2個以上節點 quorum【選舉人數】= 1；
· master宕機，s1和s2只要有一個哨兵認為master宕機就可以還能切換，同時這個時候，需要majority，也就是大多數哨兵都是運行的，2個哨兵的majority就是2,2個哨兵都是運行著的，就可以允許執行故障轉移；
· 【但是如果整個M1和S1運行的機器宕機了，那么哨兵只有1個了，此時就沒有majority來允許執行故障轉移，雖然另外一臺機器還有一個R1，但是故障轉移不會執行，結合下圖順帶看一下哨兵的金典3個節點集群】

【經典的3節點哨兵集群】

2.redis哨兵上線前必須要通過大力的測試【redis哨兵模式是不會保證數據的零丟失的只能保證高可用】：

2.1 哨兵至少需要3個實例，來保證自己的健壯性【首先必須要保證redis哨兵的健壯性，要不然高可用還有啥意思】
2.2 哨兵 + redis主從的部署架構，是不會保證數據的零丟失的，只能保證redis集群的高可用性
2.3 對于哨兵+redis主從這種復雜的部署架構，盡量在測試環境和生產環境，都進行充足的測試和演練。【盡可能的能把線上的數據丟上去實際測試】

redis哨兵主從切換的數據丟失問題【壓軸出場】

上圖先：異步復制可能產生的數據丟失問題

為啥異步復制的時候，也就是master node將數據異步復制給slave node分支的時候可能會產生數據丟失？？？圖看完結合完文字解析一波，恍然大悟，呦西！

異步復制導致的數據丟失
因為master復制數據到slave的復制是異步的，所有可能有部分數據還沒有復制到slave，master就宕機了，此時這些部分數據就丟失了。

那么問題來了？怎么辦？雖然這種情況只是有可能會發生，但是真的發生了，還丟失了不少的數據，MySQL裸奔，MySQL怕是會吃不消?咋辦？？？

異步復制丟失數據的解決方案

為了更好的不然MySQL裸奔，當然得想想有沒有衣服穿，冷一點沒有關系；首先俺們知道，道高一尺魔高一丈，先把conf配置文件翻一翻，下面：

在redis的conf下面設置這兩個參數：
min-slaves-to-write 1
min-slaves-max-lag 10
先來一波參數說明：
min-slaves-max-lag這個配置，就可以確保說，一旦salve復制數據ack延時，就會認為可能maste noder宕機后損失的數據太多了，那么master就會暫時拒絕寫的請求，這樣可以將master node 宕機時由于部分數據未同步到slave導致的數據丟失降低到課控制的范圍內【這個文字可能看的會有點繞，有點虛頭巴腦不務實的感覺，上圖->異步復制數據的解決方案】

很簡單：要求至少有一個slave node，數據復制和同步的延遲不能超過10秒鐘如果說一旦所有的slave node，數據復制和同步的延遲都超過了10秒鐘，那么這個時候，master node這個分支就不會再接收任何請求了。

【這里的時候，俺也有點小疑惑點，那這不是完犢子了，為啥只保證一個，要是這個時候恰好master出現宕機，正好有選舉提升master選到了另外一個master上面去了，這不是很尷尬？那不還是數據丟失了？】—這個別急，上下文要對應，這個要解釋在下文中； =留個伏筆=

腦裂導致的數據丟失問題

上圖：腦裂是什么？什么情況下會出現這種問題？【集群腦裂導致的數據丟失問題圖】

這個基本上見圖如解決問題：【腦裂清晰的解釋】

腦裂，也就是說，某個master所在機器突然脫離了正常的網絡，跟其他slave機器不能連接，但是實際在master還運行著，此時哨兵可能就會認為master宕機了，然后開始進行選舉，將其他的slave切換成了master，這個時候，集群了就會有兩個master，也就是所謂的腦裂；
此時雖然摸個slave被切換成了master，但是可能client客戶端還沒來得及切換到新的master，還在繼續向舊的master寫的數據，就可能丟失了，因此就的master再次恢復的時候，會被作為一個slave掛到新的master上去，自己的數據會清空，重新從新的master復制數據；

直接上解決方案圖：

首先還是conf文件下的兩個參數拿出來先：

這里就不過多的做參數說明了，上面有類似的舉例
min-slaves-to-write 1
min-slaves-max-lag 10

文本解析：

減少腦裂的數據丟失問題：如果一個master出現了腦裂，跟其他的slave丟了連接，那么上面兩個配置可以確保說，如果不能繼續給指定數量的slave發送數據，而且slave超過10秒沒有給自己ack消息，這個ack說的就是slave node給master node的響應反饋，那么就直接拒絕客戶端的寫請求【這樣腦裂后的舊master就不會接受client客戶端的新數據，也就避免了數據丟失】
以上的配置就確保了，如果跟任何一個slave丟了連接，在10秒后發現沒有slave給自己ack，那么就拒絕新的寫請求，因此在腦裂的場景下，最多也就丟失10秒中的數據；

凡事沒有絕對，但是一定有對應的解決辦法，繼續深入一波；

redis哨兵的4個核心底層原理，包含slave選舉的算法

1.sdown轉odown的機制，在文章的前言就解釋的很透徹，但是講的停白話的，專業寫來講，也是差不多的原理，掛個圖，立馬領悟，啥時候看，啥時候爽；【sdown轉odown機制】

2.哨兵和slave集群的自動發現機制
上圖后解釋：【哨兵和slave集群的自動發現機制】

啥意思呢？努力看完這枯燥點的專業話

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

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

每個哨兵也會去監聽自己監控的每個master+slaves對應的_sentinel_:hello channel,然后去感知到同樣在監聽這個master+slaves的其他哨兵的存在；

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

3.slave配置的自動糾正

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

4.伏筆 前面留下的伏筆就是核心底層原理的第4點，其實也很簡單；
如果一個master被認為odown了，而且majority哨兵都允許了主備切換，那么某個哨兵就會執行貯備切換操作，此時就要首選選舉一個slave來作為master；

此時會考慮slave node分支的一些信息：

1.跟master斷開的連接時長【這不，首選就是這個，當然只用保證一個slave node分支沒有和master復制數據超過10秒即可】
如果一個slave跟master斷開連接已經超過了down-after-milliseconds的10倍，外加master宕機的時長，那么slave就被認為不適合選舉為maser

2.slave優先級
按照slave優先級進行排序，slave priority越低，優先級就越高

3.復制offset
如果slave priority相同，那么看replica offset，哪個slave復制了越多的數據，offset越靠后，優先級就越高

4.run id
如果上面兩個條件都相同，那么選擇一個run id比較小的哪個slave作為master即可

到達了文章的最后，節點就是一份圖，關說不練假把式，整起來
【在項目中以經典的3節點方式部署哨兵集群】

聲明：轉發請備出處！謝謝！所有的原圖可以找我申領，redis的生產環境的部署，集群的搭建，哨兵模式，主從分離，redis如何支撐海量數據，幾十萬的QPS，master node和slave node的主從分離痛點等等，包括小到linux上面的靜態IP配置，網段，全部畫圖筆記，可以無條件分享，謝謝大家。
【歡迎大家的留言和補充指出，希望能在評論區多多交流，分享避免線上環境中的各種踩坑】

總結

以上是生活随笔為你收集整理的REDIS哨兵【Sentinel】模式+哨兵的核心知识点+redis哨兵主从切换的数据丢失问题+上一章铺垫的【异步复制数据丢失问题】+【集群脑裂】的全部內容，希望文章能夠幫你解決所遇到的問題。

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