Redis作為非常火熱的內存數據庫，其除了具有非常高的性能之外，還需要保證高可用，在故障發生時，盡可能地降低故障帶來的影響，Redis也提供了完善的故障恢復機制：哨兵。

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

部署模式

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

單節點部署：只有一個節點提供服務，讀寫均在此節點，此節點宕機則數據全部丟失，直接影響業務。

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

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

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

高可用做法

Redis原生提供master-slave數據復制，保證slave永遠與master數據保持一致。

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

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

哨兵介紹

哨兵是Redis高可用的解決方案，它是一個管理多個Redis實例的服務工具，可以實現對Redis實例的監控、通知、自動故障轉移。

在部署哨兵時，我們只需要在配置文件中配置需要管理的master節點，哨兵節點就可以根據配置，對Redis節點進行管理，實現高可用。

一般我們需要部署多個哨兵節點，這是因為在分布式場景下，要想確定某個機器的某個節點上否發生故障，只用一臺機器去檢測可能是不準確的，很有可能這兩臺機器的網絡發生了故障，而節點本身并沒有問題。

所以對于節點健康檢測的場景，一般都會采用多個節點同時去檢測，且多個節點分布在不同機器上，節點數量為奇數個，避免因為網絡分區導致哨兵決策錯誤。這樣多個哨兵節點互相交換檢測信息，最終決策才能確認某個節點上否真正發生了問題。

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

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

哨兵工作原理

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

• 狀態感知

• 心跳檢測

• 選舉哨兵領導者

• 選擇新的master

• 故障恢復

• 客戶端感知新master

下面對這些階段進行詳細的介紹。

狀態感知

哨兵啟動后只指定了master的地址，哨兵要想在master故障時進行故障恢復，就需要知道每個master對應的slave信息。每個master可能不止一個slave，因此哨兵需要知道整個集群中完整的的拓撲關系，如何拿到這些信息？

哨兵每隔10秒會向每個master節點發送info命令，info命令返回的信息中，包含了主從拓撲關系，其中包括每個slave的地址和端口號。有了這些信息后，哨兵就會記住這些節點的拓撲信息，在后續發生故障時，選擇合適的slave節點進行故障恢復。

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

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

• 哨兵節點可以發現其他哨兵的加入，進而方便多個哨兵節點通信，為后續共同協商提供基礎

• 與其他哨兵節點交換master的狀態信息，為后續判斷master是否故障提供依據

心跳檢測

在故障發生時，需要立即啟動故障恢復機制，那么如何保證及時性呢？

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

為什么叫做主觀下線？

因為當前哨兵節點探測對方沒有得到響應，很有可能這兩個機器之間的網絡發生了故障，而master節點本身沒有任何問題，此時就認為master故障是不正確的。

要想確認master節點是否真正發生故障，就需要多個哨兵節點共同確認才行。

每個哨兵節點通過向其他哨兵節點詢問此master的狀態，來共同確認此節點上否真正故障。

如果超過指定數量（可配置）的哨兵節點都認為此節點主觀下線，那么才會把這個節點標記為客觀下線。

選舉哨兵領導者

確認這個節點真正故障后，就需要進入到故障恢復階段。如何進行故障恢復，也需要經歷一系列流程。

首先需要選舉出一個哨兵領導者，由這個專門的哨兵領導者來進行故障恢復操作，不用多個哨兵都參與故障恢復。選舉哨兵領導者的過程，需要多個哨兵節點共同協商來選出。

這個選舉協商的過程，在分布式領域中叫做達成共識，協商的算法叫做共識算法。

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

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

哨兵選舉領導者的過程類似于Raft算法，它的算法足夠簡單易理解。

簡單來講流程如下：

• 每個哨兵都設置一個隨機超時時間，超時后向其他哨兵發送申請成為領導者的請求

• 其他哨兵只能對收到的第一個請求進行回復確認

• 首先達到多數確認選票的哨兵節點，成為領導者

• 如果在確認回復后，所有哨兵都無法達到多數選票的結果，那么進行重新選舉，直到選出領導者為止

選擇出哨兵領導者后，之后的故障恢復操作都由這個哨兵領導者進行操作。

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

選擇新的master

哨兵領導者針對發生故障的master節點，需要在它的slave節點中，選擇一個節點來代替其工作。

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

也就是說優先選擇slave-priority最小值的slave節點，如果所有slave此配置相同，那么選擇數據最完整的slave節點，如果數據也一樣，最后選擇runid較小的slave節點。

提升新的master

經過優先級選擇，選出了備選的master節點后，下一步就是要進行真正的主從切換了。

哨兵領導者給備選的master節點發送slaveof no one命令，讓該節點成為master。

之后，哨兵領導者會給故障節點的所有slave發送slaveof $newmaster命令，讓這些slave成為新master的從節點，開始從新的master上同步數據。

最后哨兵領導者把故障節點降級為slave，并寫入到自己的配置文件中，待這個故障節點恢復后，則自動成為新master節點的slave。

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

客戶端感知新master

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

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

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

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

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

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

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