Redis作為非?；馃岬膬?nèi)存數(shù)據(jù)庫，其除了具有非常高的性能之外，還需要保證高可用，在故障發(fā)生時，盡可能地降低故障帶來的影響，Redis也提供了完善的故障恢復(fù)機(jī)制：哨兵。

下面就來具體來看看Redis的故障恢復(fù)是如何做的，以及其中的原理。

部署模式

Redis在部署時，可以采用多種方式部署，每種部署方式對應(yīng)不同的可用級別。

單節(jié)點部署：只有一個節(jié)點提供服務(wù)，讀寫均在此節(jié)點，此節(jié)點宕機(jī)則數(shù)據(jù)全部丟失，直接影響業(yè)務(wù)。

master-slave方式部署：兩個節(jié)點組成master-slave模式，在master上寫入，slave上讀取，讀寫分離提高訪問性能，master宕機(jī)后，需要手動把slave提升為master，業(yè)務(wù)影響程度取決于手動提升master的延遲。

master-slave+哨兵方式部署：master-slave與上述相同，不同的是增加一組哨兵節(jié)點，用于實時檢查master的健康狀態(tài)，在master宕機(jī)后自動提升slave為新的master，最大程度降低不可用的時間，對業(yè)務(wù)影響時間較短。

從上面幾種部署模式可以看出，提高Redis可用性的關(guān)鍵是：多副本部署 + 自動故障恢復(fù)，而多副本正是依賴主從復(fù)制。

高可用做法

Redis原生提供master-slave數(shù)據(jù)復(fù)制，保證slave永遠(yuǎn)與master數(shù)據(jù)保持一致。

在master發(fā)生問題時，我們需要把slave提升為master，繼續(xù)提供服務(wù)。而這個提升新master的操作，如果是人工處理，必然無法保證及時性，所以Redis提供了哨兵節(jié)點，用來管理master-slave節(jié)點，并在master發(fā)生問題時，能夠自動進(jìn)行故障恢復(fù)操作。

整個故障恢復(fù)的工作，正是Redis哨兵自動完成的。

哨兵介紹

哨兵是Redis高可用的解決方案，它是一個管理多個Redis實例的服務(wù)工具，可以實現(xiàn)對Redis實例的監(jiān)控、通知、自動故障轉(zhuǎn)移。

在部署哨兵時，我們只需要在配置文件中配置需要管理的master節(jié)點，哨兵節(jié)點就可以根據(jù)配置，對Redis節(jié)點進(jìn)行管理，實現(xiàn)高可用。

一般我們需要部署多個哨兵節(jié)點，這是因為在分布式場景下，要想確定某個機(jī)器的某個節(jié)點上否發(fā)生故障，只用一臺機(jī)器去檢測可能是不準(zhǔn)確的，很有可能這兩臺機(jī)器的網(wǎng)絡(luò)發(fā)生了故障，而節(jié)點本身并沒有問題。

所以對于節(jié)點健康檢測的場景，一般都會采用多個節(jié)點同時去檢測，且多個節(jié)點分布在不同機(jī)器上，節(jié)點數(shù)量為奇數(shù)個，避免因為網(wǎng)絡(luò)分區(qū)導(dǎo)致哨兵決策錯誤。這樣多個哨兵節(jié)點互相交換檢測信息，最終決策才能確認(rèn)某個節(jié)點上否真正發(fā)生了問題。

哨兵節(jié)點部署并配置完成后，哨兵就會自動地對配置的master-slave進(jìn)行管理，在master發(fā)生故障時，及時地提升slave為新的master，保證可用性。

那么它的工作原理上怎樣的呢？

哨兵工作原理

哨兵的工作流程主要分為以下幾個階段：

• 狀態(tài)感知

• 心跳檢測

• 選舉哨兵領(lǐng)導(dǎo)者

• 選擇新的master

• 故障恢復(fù)

• 客戶端感知新master

下面對這些階段進(jìn)行詳細(xì)的介紹。

狀態(tài)感知

哨兵啟動后只指定了master的地址，哨兵要想在master故障時進(jìn)行故障恢復(fù)，就需要知道每個master對應(yīng)的slave信息。每個master可能不止一個slave，因此哨兵需要知道整個集群中完整的的拓?fù)潢P(guān)系，如何拿到這些信息？

哨兵每隔10秒會向每個master節(jié)點發(fā)送info命令，info命令返回的信息中，包含了主從拓?fù)潢P(guān)系，其中包括每個slave的地址和端口號。有了這些信息后，哨兵就會記住這些節(jié)點的拓?fù)湫畔?，在后續(xù)發(fā)生故障時，選擇合適的slave節(jié)點進(jìn)行故障恢復(fù)。

哨兵除了向master發(fā)送info之外，還會向每個master節(jié)點特殊的pubsub中發(fā)送master當(dāng)前的狀態(tài)信息和哨兵自身的信息，其他哨兵節(jié)點通過訂閱這個pubsub，就可以拿到每個哨兵發(fā)來的信息。

這么做的目的主要有2個：

• 哨兵節(jié)點可以發(fā)現(xiàn)其他哨兵的加入，進(jìn)而方便多個哨兵節(jié)點通信，為后續(xù)共同協(xié)商提供基礎(chǔ)

• 與其他哨兵節(jié)點交換master的狀態(tài)信息，為后續(xù)判斷master是否故障提供依據(jù)

心跳檢測

在故障發(fā)生時，需要立即啟動故障恢復(fù)機(jī)制，那么如何保證及時性呢？

每個哨兵節(jié)點每隔1秒向master、slave、其他哨兵節(jié)點發(fā)送ping命令，如果對方能在指定時間內(nèi)響應(yīng)，說明節(jié)點健康存活。如果未在規(guī)定時間內(nèi)（可配置）響應(yīng)，那么該哨兵節(jié)點認(rèn)為此節(jié)點主觀下線。

為什么叫做主觀下線？

因為當(dāng)前哨兵節(jié)點探測對方?jīng)]有得到響應(yīng)，很有可能這兩個機(jī)器之間的網(wǎng)絡(luò)發(fā)生了故障，而master節(jié)點本身沒有任何問題，此時就認(rèn)為master故障是不正確的。

要想確認(rèn)master節(jié)點是否真正發(fā)生故障，就需要多個哨兵節(jié)點共同確認(rèn)才行。

每個哨兵節(jié)點通過向其他哨兵節(jié)點詢問此master的狀態(tài)，來共同確認(rèn)此節(jié)點上否真正故障。

如果超過指定數(shù)量（可配置）的哨兵節(jié)點都認(rèn)為此節(jié)點主觀下線，那么才會把這個節(jié)點標(biāo)記為客觀下線。

選舉哨兵領(lǐng)導(dǎo)者

確認(rèn)這個節(jié)點真正故障后，就需要進(jìn)入到故障恢復(fù)階段。如何進(jìn)行故障恢復(fù)，也需要經(jīng)歷一系列流程。

首先需要選舉出一個哨兵領(lǐng)導(dǎo)者，由這個專門的哨兵領(lǐng)導(dǎo)者來進(jìn)行故障恢復(fù)操作，不用多個哨兵都參與故障恢復(fù)。選舉哨兵領(lǐng)導(dǎo)者的過程，需要多個哨兵節(jié)點共同協(xié)商來選出。

這個選舉協(xié)商的過程，在分布式領(lǐng)域中叫做達(dá)成共識，協(xié)商的算法叫做共識算法。

共識算法主要為了解決在分布式場景下，多個節(jié)點如何針對某一個場景達(dá)成一致的結(jié)果。

共識算法包括很多種，例如Paxos、Raft、Gossip算法等，感興趣的同學(xué)可以自行搜索相關(guān)資料，這里不再展開來講。

哨兵選舉領(lǐng)導(dǎo)者的過程類似于Raft算法，它的算法足夠簡單易理解。

簡單來講流程如下：

• 每個哨兵都設(shè)置一個隨機(jī)超時時間，超時后向其他哨兵發(fā)送申請成為領(lǐng)導(dǎo)者的請求

• 其他哨兵只能對收到的第一個請求進(jìn)行回復(fù)確認(rèn)

• 首先達(dá)到多數(shù)確認(rèn)選票的哨兵節(jié)點，成為領(lǐng)導(dǎo)者

• 如果在確認(rèn)回復(fù)后，所有哨兵都無法達(dá)到多數(shù)選票的結(jié)果，那么進(jìn)行重新選舉，直到選出領(lǐng)導(dǎo)者為止

選擇出哨兵領(lǐng)導(dǎo)者后，之后的故障恢復(fù)操作都由這個哨兵領(lǐng)導(dǎo)者進(jìn)行操作。

搜索Java知音公眾號，回復(fù)“后端面試”，送你一份Java面試題寶典.pdf

選擇新的master

哨兵領(lǐng)導(dǎo)者針對發(fā)生故障的master節(jié)點，需要在它的slave節(jié)點中，選擇一個節(jié)點來代替其工作。

這個選擇新master過程也是有優(yōu)先級的，在多個slave的場景下，優(yōu)先級按照：slave-priority配置 > 數(shù)據(jù)完整性 > runid較小者進(jìn)行選擇。

也就是說優(yōu)先選擇slave-priority最小值的slave節(jié)點，如果所有slave此配置相同，那么選擇數(shù)據(jù)最完整的slave節(jié)點，如果數(shù)據(jù)也一樣，最后選擇runid較小的slave節(jié)點。

提升新的master

經(jīng)過優(yōu)先級選擇，選出了備選的master節(jié)點后，下一步就是要進(jìn)行真正的主從切換了。

哨兵領(lǐng)導(dǎo)者給備選的master節(jié)點發(fā)送slaveof no one命令，讓該節(jié)點成為master。

之后，哨兵領(lǐng)導(dǎo)者會給故障節(jié)點的所有slave發(fā)送slaveof $newmaster命令，讓這些slave成為新master的從節(jié)點，開始從新的master上同步數(shù)據(jù)。

最后哨兵領(lǐng)導(dǎo)者把故障節(jié)點降級為slave，并寫入到自己的配置文件中，待這個故障節(jié)點恢復(fù)后，則自動成為新master節(jié)點的slave。

至此，整個故障切換完成。

客戶端感知新master

最后，客戶端如何拿到最新的master地址呢？

哨兵在故障切換完成之后，會向自身節(jié)點的指定pubsub中寫入一條信息，客戶端可以訂閱這個pubsub來感知master的變化通知。我們的客戶端也可以通過在哨兵節(jié)點主動查詢當(dāng)前最新的master，來拿到最新的master地址。

另外，哨兵還提供了“鉤子”機(jī)制，我們也可以在哨兵配置文件中配置一些腳本邏輯，在故障切換完成時，觸發(fā)“鉤子”邏輯，通知客戶端發(fā)生了切換，讓客戶端重新在哨兵上獲取最新的master地址。

一般來說，推薦采用第一種方式進(jìn)行處理，很多客戶端SDK中已經(jīng)集成好了從哨兵節(jié)點獲取最新master的方法，我們直接使用即可。

可見，為了保證Redis的高可用，哨兵節(jié)點要準(zhǔn)確無誤地判斷故障的發(fā)生，并且快速的選出新的節(jié)點來代替其提供服務(wù)，這中間的流程還是比較復(fù)雜的。

中間涉及到了分布式共識、分布式協(xié)商等知識，目的都是為了保證故障切換的準(zhǔn)確性。

我們有必要了解Redis高可用的工作原理，這樣我們在使用Redis時能更準(zhǔn)確地使用它。