Redis如何實現(xiàn)故障自動恢復？
這篇文章，我們來看Redis是如何實現(xiàn)故障自動恢復的，它的實現(xiàn)正是要基于之前所講的數(shù)據(jù)持久化和數(shù)據(jù)多副本而做的。
Redis作為非常火熱的內存數(shù)據(jù)庫，其除了具有非常高的性能之外，還需要保證高可用，在故障發(fā)生時，盡可能地降低故障帶來的影響，Redis也提供了完善的故障恢復機制：哨兵。
下面就來具體來看看Redis的故障恢復是如何做的，以及其中的原理。
部署模式
Redis在部署時，可以采用多種方式部署，每種部署方式對應不同的可用級別。
單節(jié)點部署：只有一個節(jié)點提供服務，讀寫均在此節(jié)點，此節(jié)點宕機則數(shù)據(jù)全部丟失，直接影響業(yè)務
master-slave方式部署：兩個節(jié)點組成master-slave模式，在master上寫入，slave上讀取，讀寫分離提高訪問性能，master宕機后，需要手動把slave提升為master，業(yè)務影響程度取決于手動提升master的延遲
master-slave+哨兵方式部署：master-slave與上述相同，不同的是增加一組哨兵節(jié)點，用于實時檢查master的健康狀態(tài)，在master宕機后自動提升slave為新的master，最大程度降低不可用的時間，對業(yè)務影響時間較短
從上面幾種部署模式可以看出，提高Redis可用性的關鍵是：多副本部署 + 自動故障恢復，而多副本正是依賴主從復制。
高可用做法
Redis原生提供master-slave數(shù)據(jù)復制，保證slave永遠與master數(shù)據(jù)保持一致。
在master發(fā)生問題時，我們需要把slave提升為master，繼續(xù)提供服務。而這個提升新master的操作，如果是人工處理，必然無法保證及時性，所以Redis提供了哨兵節(jié)點，用來管理master-slave節(jié)點，并在master發(fā)生問題時，能夠自動進行故障恢復操作。
整個故障恢復的工作，正是Redis哨兵自動完成的。
哨兵介紹
哨兵是Redis高可用的解決方案，它是一個管理多個Redis實例的服務工具，可以實現(xiàn)對Redis實例的監(jiān)控、通知、自動故障轉移。
在部署哨兵時，我們只需要在配置文件中配置需要管理的master節(jié)點，哨兵節(jié)點就可以根據(jù)配置，對Redis節(jié)點進行管理，實現(xiàn)高可用。
一般我們需要部署多個哨兵節(jié)點，這是因為在分布式場景下，要想確定某個機器的某個節(jié)點上否發(fā)生故障，只用一臺機器去檢測可能是不準確的，很有可能這兩臺機器的網(wǎng)絡發(fā)生了故障，而節(jié)點本身并沒有問題。
所以對于節(jié)點健康檢測的場景，一般都會采用多個節(jié)點同時去檢測，且多個節(jié)點分布在不同機器上，節(jié)點數(shù)量為奇數(shù)個，避免因為網(wǎng)絡分區(qū)導致哨兵決策錯誤。這樣多個哨兵節(jié)點互相交換檢測信息，最終決策才能確認某個節(jié)點上否真正發(fā)生了問題。
哨兵節(jié)點部署并配置完成后，哨兵就會自動地對配置的master-slave進行管理，在master發(fā)生故障時，及時地提升slave為新的master，保證可用性。關于Spring Boot的集成實戰(zhàn)請點擊這里進行參考。
那么它的工作原理上怎樣的呢？
哨兵工作原理
哨兵的工作流程主要分為以下幾個階段：
狀態(tài)感知
心跳檢測
選舉哨兵領導者
選擇新的master
故障恢復
客戶端感知新master
下面對這些階段進行詳細的介紹。
狀態(tài)感知
哨兵啟動后只指定了master的地址，哨兵要想在master故障時進行故障恢復，就需要知道每個master對應的slave信息。Redis集群的搭建請點擊這里進行參考。關注公眾號Java技術棧可以獲取更多Redis系列教程。
每個master可能不止一個slave，因此哨兵需要知道整個集群中完整的的拓撲關系，如何拿到這些信息？
哨兵每隔10秒會向每個master節(jié)點發(fā)送info命令，info命令返回的信息中，包含了主從拓撲關系，其中包括每個slave的地址和端口號。有了這些信息后，哨兵就會記住這些節(jié)點的拓撲信息，在后續(xù)發(fā)生故障時，選擇合適的slave節(jié)點進行故障恢復。
哨兵除了向master發(fā)送info之外，還會向每個master節(jié)點特殊的pubsub中發(fā)送master當前的狀態(tài)信息和哨兵自身的信息，其他哨兵節(jié)點通過訂閱這個pubsub，就可以拿到每個哨兵發(fā)來的信息。
這么做的目的主要有2個：
哨兵節(jié)點可以發(fā)現(xiàn)其他哨兵的加入，進而方便多個哨兵節(jié)點通信，為后續(xù)共同協(xié)商提供基礎
與其他哨兵節(jié)點交換master的狀態(tài)信息，為后續(xù)判斷master是否故障提供依據(jù)
心跳檢測
在故障發(fā)生時，需要立即啟動故障恢復機制，那么如何保證及時性呢？
每個哨兵節(jié)點每隔1秒向master、slave、其他哨兵節(jié)點發(fā)送ping命令，如果對方能在指定時間內響應，說明節(jié)點健康存活。如果未在規(guī)定時間內（可配置）響應，那么該哨兵節(jié)點認為此節(jié)點主觀下線。
為什么叫做主觀下線？
因為當前哨兵節(jié)點探測對方?jīng)]有得到響應，很有可能這兩個機器之間的網(wǎng)絡發(fā)生了故障，而master節(jié)點本身沒有任何問題，此時就認為master故障是不正確的。
要想確認master節(jié)點是否真正發(fā)生故障，就需要多個哨兵節(jié)點共同確認才行。
每個哨兵節(jié)點通過向其他哨兵節(jié)點詢問此master的狀態(tài)，來共同確認此節(jié)點上否真正故障。
如果超過指定數(shù)量（可配置）的哨兵節(jié)點都認為此節(jié)點主觀下線，那么才會把這個節(jié)點標記為客觀下線。
選舉哨兵領導者
確認這個節(jié)點真正故障后，就需要進入到故障恢復階段。如何進行故障恢復，也需要經(jīng)歷一系列流程。
首先需要選舉出一個哨兵領導者，由這個專門的哨兵領導者來進行故障恢復操作，不用多個哨兵都參與故障恢復。選舉哨兵領導者的過程，需要多個哨兵節(jié)點共同協(xié)商來選出。
這個選舉協(xié)商的過程，在分布式領域中叫做達成共識，協(xié)商的算法叫做共識算法。
共識算法主要為了解決在分布式場景下，多個節(jié)點如何針對某一個場景達成一致的結果。
共識算法包括很多種，例如Paxos、Raft、Gossip算法等，感興趣的同學可以自行搜索相關資料，這里不再展開來講。
哨兵選舉領導者的過程類似于Raft算法，它的算法足夠簡單易理解。
簡單來講流程如下：
每個哨兵都設置一個隨機超時時間，超時后向其他哨兵發(fā)送申請成為領導者的請求
其他哨兵只能對收到的第一個請求進行回復確認
首先達到多數(shù)確認選票的哨兵節(jié)點，成為領導者
如果在確認回復后，所有哨兵都無法達到多數(shù)選票的結果，那么進行重新選舉，直到選出領導者為止
選擇出哨兵領導者后，之后的故障恢復操作都由這個哨兵領導者進行操作。
選擇新的master
哨兵領導者針對發(fā)生故障的master節(jié)點，需要在它的slave節(jié)點中，選擇一個節(jié)點來代替其工作。
這個選擇新master過程也是有優(yōu)先級的，在多個slave的場景下，優(yōu)先級按照：slave-priority配置 > 數(shù)據(jù)完整性 > runid較小者進行選擇。
也就是說優(yōu)先選擇slave-priority最小值的slave節(jié)點，如果所有slave此配置相同，那么選擇數(shù)據(jù)最完整的slave節(jié)點，如果數(shù)據(jù)也一樣，最后選擇runid較小的slave節(jié)點。
提升新的master
經(jīng)過優(yōu)先級選擇，選出了備選的master節(jié)點后，下一步就是要進行真正的主從切換了。
哨兵領導者給備選的master節(jié)點發(fā)送slaveof no one命令，讓該節(jié)點成為master。
之后，哨兵領導者會給故障節(jié)點的所有slave發(fā)送slaveof $newmaster命令，讓這些slave成為新master的從節(jié)點，開始從新的master上同步數(shù)據(jù)。
最后哨兵領導者把故障節(jié)點降級為slave，并寫入到自己的配置文件中，待這個故障節(jié)點恢復后，則自動成為新master節(jié)點的slave。
至此，整個故障切換完成。
客戶端感知新master
最后，客戶端如何拿到最新的master地址呢？
哨兵在故障切換完成之后，會向自身節(jié)點的指定pubsub中寫入一條信息，客戶端可以訂閱這個pubsub來感知master的變化通知。我們的客戶端也可以通過在哨兵節(jié)點主動查詢當前最新的master，來拿到最新的master地址。
另外，哨兵還提供了“鉤子”機制，我們也可以在哨兵配置文件中配置一些腳本邏輯，在故障切換完成時，觸發(fā)“鉤子”邏輯，通知客戶端發(fā)生了切換，讓客戶端重新在哨兵上獲取最新的master地址。
一般來說，推薦采用第一種方式進行處理，很多客戶端SDK中已經(jīng)集成好了從哨兵節(jié)點獲取最新master的方法，我們直接使用即可。
總結
可見，為了保證Redis的高可用，哨兵節(jié)點要準確無誤地判斷故障的發(fā)生，并且快速的選出新的節(jié)點來代替其提供服務，這中間的流程還是比較復雜的。
中間涉及到了分布式共識、分布式協(xié)商等知識，目的都是為了保證故障切換的準確性。
我們有必要了解Redis高可用的工作原理，這樣我們在使用Redis時能更準確地使用它。
作者：Kaito
鏈接：kaito-kidd.com/2020/07/02/redis-sentinel/
推薦閱讀