這篇文章，我們來看Redis是如何實作故障自動恢復的，它的實作正是要基于之前所講的資料持久化和資料多副本而做的，
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演算法，它的演算法足夠簡單易理解，
簡單來講流程如下：
-
每個哨兵都設定一個隨機超時時間，超時后向其他哨兵發送申請成為領導者的請求
-
其他哨兵只能對收到的第一個請求進行回復確認
-
首先達到多數確認選票的哨兵節點，成為領導者
-
如果在確認回復后，所有哨兵都無法達到多數選票的結果，那么進行重新選舉，直到選出領導者為止
選擇出哨兵領導者后，之后的故障恢復操作都由這個哨兵領導者進行操作，
回復“電子書”，送你我精心整理的獨家學習資料！
選擇新的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時能更準確地使用它，
本人免費整理了Java高級資料，涵蓋了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高并發分布式等教程，一共30G，需要自己領取，
傳送門：https://shimo.im/docs/rQRKDPx6dPXqvYPq
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/163390.html
標籤：Java