前面我們基于實際案例搭建了緩存高可用方案（分布式緩存高可用方案，我們都是這么干的）同時提到了redis主從架構(gòu)下是如何保證高可用的，講到了它是通過redis sentinel的機制來實現(xiàn)的。
今天我們就來看看redis sentinel即哨兵機制的相關(guān)底層原理以及我們在生產(chǎn)中需要避的坑。
什么是redis sentinel
哨兵在redis集群架構(gòu)中是一個非常重要的組件，其主要功能有下面這些：
A，集群監(jiān)控，即時刻監(jiān)控著redis的master和slave進程是否是在正常工作。
B，消息通知，就是說當它發(fā)現(xiàn)有redis實例有故障的話，就會發(fā)送消息給管理員
C，故障自動轉(zhuǎn)移，如果redis master 節(jié)點宕機了的話，它就會將請求轉(zhuǎn)到slave 節(jié)點上，slave升為master。
D，充當配置中心，如果發(fā)生了故障轉(zhuǎn)移，它會通知將master的新地址寫在配置中心告訴客戶端。
sentinel 本身也是分布式部署的，是一個集群去運行的并且節(jié)點間相互協(xié)調(diào)工作，那它是怎么來監(jiān)控redis的呢？
（1），當發(fā)生故障轉(zhuǎn)移的時候，只有大部分哨兵節(jié)點同意才會判斷你這個master是真的宕機了，這里會涉及到前面講到的分布式選主，如果忘記了自行看下（面試是不是經(jīng)常被問到分布式系統(tǒng)核心問題，這一次沒人難倒你）
（2），如果哨兵部分節(jié)點掛了的話，整個哨兵集群依然能工作，這也是確保自身能高可用。
需要知道的哨兵核心點
1，哨兵集群至少要 3 個節(jié)點，來確保自己的健壯性。
2，redis主從 + sentinel的架構(gòu)，是不會保證數(shù)據(jù)的零丟失的，它是為了保證redis集群的高可用。
3，在部署redis主從 + sentinel 架構(gòu)之前，我們要在測試環(huán)境多測試，盡量模擬線上環(huán)境。
你可能會問，哨兵集群 2 個節(jié)點難道就不行嗎？好，如果咱們的哨兵集群只部署了兩個節(jié)點，那么 quorum=1,
如上圖，如果master宕機，sentinel 1 和 sentinel 2 只要有一個認為master宕機就會進行切換，同時sentinel 1 和sentinel 2 就會選出一個sentinel來進行故障轉(zhuǎn)移，這個時候就需要用到majority，即大多數(shù)哨兵都是運行的，2個哨兵的majority是2（3個的majority=2，4個的majority=2，5個的majority=3），也就是說現(xiàn)在這兩個哨兵節(jié)點都是正常運行的就可以進行故障轉(zhuǎn)移。
但是，現(xiàn)在master和sentinel1運行的整個機器如果宕機了的話，那么哨兵就只有一個了，此時就無法來通過majority來進行故障轉(zhuǎn)移了，所以，我們至少需要三臺哨兵實例。
3 節(jié)點sentinel架構(gòu)
如上圖所示，
A，假設(shè)master所在的機器不可用的話，那么哨兵還剩2個，sentinel 2 和sentinel3 就會認為master宕機，然后選舉一個來處理故障轉(zhuǎn)移
B，三個哨兵節(jié)點的majority為2，現(xiàn)在還有2個哨兵在工作著，就可以允許執(zhí)行故障轉(zhuǎn)移。
上面我們已經(jīng)知道了哨兵的核心機制以及它和redis主從架構(gòu)是如何配合使用來達到redis的高可用的，下面我們就來看看redis哨兵主備切換的數(shù)據(jù)丟失問題。
1，主從異步復(fù)制導(dǎo)致的數(shù)據(jù)丟失
redis master 和slave 數(shù)據(jù)復(fù)制是異步的，像前面說的MySQL差不多（數(shù)據(jù)庫讀寫分離方案，實現(xiàn)高性能數(shù)據(jù)庫集群），這樣就有可能會出現(xiàn)部分數(shù)據(jù)還沒有復(fù)制到slave中，master就掛掉了，那么這部分的數(shù)據(jù)就會丟失了。
2，腦裂導(dǎo)致的數(shù)據(jù)丟失
腦裂其實就是網(wǎng)絡(luò)分區(qū)導(dǎo)致的現(xiàn)象，比如，我們的master機器網(wǎng)絡(luò)突然不正常了發(fā)生了網(wǎng)絡(luò)分區(qū)，和其他的slave機器不能正常通信了，其實master并沒有掛還活著好好的呢，但是哨兵可不是吃閑飯的啊，它會認為master掛掉了啊，那么問題來了，client可能還在繼續(xù)寫master的呀，還沒來得及更新到新的master呢，那這部分數(shù)據(jù)就會丟失。
上面的兩個數(shù)據(jù)丟失的問題，那我們該怎么去解決呢？其實也很簡單，只需要在配置中加兩個配置就行了，如下:
我們不能只是去解決問題，我們要知道為什么這么做就可以解決問題，下面我們就來分析下，加上了這兩個配置是怎么解決我們數(shù)據(jù)丟失問題的。
核心思想就是，一旦所有的slave節(jié)點，在數(shù)據(jù)復(fù)制和同步時延遲了超過10秒的話，那么master它就不會再接客戶端的請求了，這樣就會有效減少大量數(shù)據(jù)丟失的發(fā)生。
如何減少異步復(fù)制數(shù)據(jù)的丟失
現(xiàn)在當我們的slave在數(shù)據(jù)復(fù)制的時候，發(fā)現(xiàn)返回的ACK時延太長達到了 min-slaves-max-lag 配置，這個時候就會認為如果master宕機就會導(dǎo)致大量數(shù)據(jù)丟失，所以就提前進行了預(yù)測，就不再去接收客戶端的任何請求了，來將丟失的數(shù)據(jù)降低在可控范圍內(nèi)。
減少腦裂數(shù)據(jù)的丟失
1，如果master出現(xiàn)了腦裂，和其他的slave失去了通信，不能繼續(xù)給指定數(shù)量的slave發(fā)送數(shù)據(jù)。
2，slave超過10秒沒有給自己返回ack消息。
3，master就會拒絕客戶端的寫請求
redis 哨兵底層核心原理深度解析
上面我們了解到了redis 哨兵的基本知識也解決了數(shù)據(jù)丟失的問題，那接下來我們來看看哨兵的幾個核心底層原理，幫助大家在探討這類問題的時候，也有話可說，也更不怕面試官問到哨兵機制。
1，sdown和odown轉(zhuǎn)換機制
A，sdown，即主觀宕機，如果一個哨兵它自己覺得master宕機了，就是主觀宕機
B，odown，即客觀宕機，如果quorum數(shù)量的哨兵都認為一個master宕機了，則為客觀宕機
哨兵在ping一個master的時候，如果超過了is-master-down-after-milliseconds指定的毫秒數(shù)之后，就是達到了sdown，就主觀認為master宕機了。
如果一個哨兵在指定時間內(nèi)，收到了quorum指定數(shù)量的其他哨兵也認為那個master是sdown了，那么就認為是odown了，客觀認為master宕機，就完成了sdown到odown的轉(zhuǎn)換。
2，哨兵集群如何實現(xiàn)自動發(fā)現(xiàn)
A，通過redis的pub/sub系統(tǒng)實現(xiàn)的，每個哨兵都會往__sentinel__:hello這個channel里發(fā)送一個消息。
B，其他哨兵可以消費到這個消息，且可以感知到其他哨兵的存在。
C，每隔兩秒鐘，每個哨兵都會向自己監(jiān)控的某個master+slaves對應(yīng)的__sentinel__:hello channel里發(fā)送一個消息（包括自己的host、ip和runid還有對這個master的監(jiān)控配置）。
D，每個哨兵也會去監(jiān)聽自己監(jiān)控的每個master+slaves對應(yīng)的__sentinel__:hello channel，然后去感知到同樣在監(jiān)聽這個master+slaves的其他哨兵的存在。
F，每個哨兵還會跟其他哨兵交換對master的監(jiān)控配置，互相進行監(jiān)控配置的同步。
3，slave配置如何自動糾正
slave配置的自動糾正，是由哨兵來負責(zé)的。例如，slave如果要成為潛在的master候選人，哨兵會確保slave復(fù)制現(xiàn)有的master數(shù)據(jù)；如果slave連接的是一個有問題的master，在故障轉(zhuǎn)移之后，哨兵會確保slave能連上新的沒問題的master上。
4，slave 到master 選舉算法
如果一個master被認為odown了，而且majority哨兵都允許了主備切換，那么某個哨兵就會執(zhí)行主備切換操作，此時首先要選舉一個slave來，主要通過下面幾個步驟：
需要考慮slave的下面一些信息
A，跟master斷開連接的時長
B，slave優(yōu)先級
C，復(fù)制offset
D，run id
如果一個slave跟master斷開連接已經(jīng)超過了down-after-milliseconds的10倍，再加上加master宕機的時長，那么slave就被認為不適合選舉為master。
(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state
接下來會對slave進行排序
A，按照slave優(yōu)先級進行排序，slave priority越低，優(yōu)先級就越高。,
B，如果slave priority相同，那么看replica offset，哪個slave復(fù)制了越多的數(shù)據(jù)，offset越靠后，優(yōu)先級就越高。
C，如果上面兩個條件都相同，那么選擇一個run id比較小的那個slave
5，quorum和majority 關(guān)系
每次一個哨兵要做主備切換的時候，首先需要quorum數(shù)量的哨兵認為odown，然后選舉出一個哨兵來做切換，這個哨兵還得得到majority哨兵的授權(quán)，才能正式執(zhí)行切換。
如果quorum < majority，比如5個哨兵，majority就是3，quorum設(shè)置為2，那么就3個哨兵授權(quán)就可以執(zhí)行切換
如果quorum >= majority，那么必須quorum數(shù)量的哨兵都授權(quán)，比如5個哨兵，quorum是5，那么必須5個哨兵都同意授權(quán)，才能執(zhí)行切換。
6、configuration epoch
哨兵會對一套redis master+slave進行監(jiān)控，有相應(yīng)的監(jiān)控的配置
執(zhí)行切換的那個哨兵，會從要切換到的新master（salve->master）那里得到一個configuration epoch，這就是一個version號，每次切換的version號都必須是唯一的。
如果第一個選舉出的哨兵切換失敗了，那么其他哨兵，會等待failover-timeout時間，然后接替繼續(xù)執(zhí)行切換，此時會重新獲取一個新的configuration epoch，作為新的version號
7、configuraiton傳播
哨兵完成切換之后，會在自己本地更新生成最新的master配置，然后同步給其他的哨兵，就是通過之前說的pub/sub消息機制
這里之前的version號就很重要了，因為各種消息都是通過一個channel去發(fā)布和監(jiān)聽的，所以一個哨兵完成一次新的切換之后，新的master配置是跟著新的version號的，其他的哨兵都是根據(jù)版本號的大小來更新自己的master配置的。
總結(jié)，今天我們學(xué)習(xí)了redis sentinel 機制的基本使用，同時在使用過程中對于可能出現(xiàn)的數(shù)據(jù)丟失進行相關(guān)避坑方案講解，最后將哨兵的幾個重要的底層知識進行了詳細的講解，希望幫助大家能更好的掌握redis的哨兵機制。
在公眾號【架構(gòu)師修煉】菜單中可自行獲取專屬架構(gòu)視頻資料，無套路分享包括不限于 java架構(gòu)、python系列、人工智能系列、架構(gòu)系列，以及最新面試、小程序、大前端均無私奉獻，你會感謝我的哈
下一篇預(yù)告：緩存穿透換題
往期精選
一致性哈希算法，在分布式開發(fā)中你必須會寫，來看完整代碼
消息中間件能干什么？RabbitMQ、Kafka、RocketMQ正確選型姿勢
數(shù)據(jù)庫分庫分表，手把手教你怎么去動態(tài)擴容索容
每天百萬交易的支付系統(tǒng)，生產(chǎn)環(huán)境該怎么設(shè)置JVM堆內(nèi)存大小
