導讀：Redis是被廣泛使用的基礎軟件之一。對于工程師和,架構師，運維人員來說，了解Redis的高可用方案和背后的原理，是必備的基礎知識。本文作者深入分析了Redis高可用的方方面面，并且做了有效總結，相信對廣大讀者可以起到很好的領路作用。

作者 codedump codedump.info 博主，多年從事互聯網服務器后臺開發工作。可訪問作者博客閱讀 codedump 更多文章。

Redis中為了實現高可用（High Availability，簡稱HA），采用了如下兩個方式：

• 主從復制數據。

• 采用哨兵監控數據節點的運行情況，一旦主節點出現問題由從節點頂上繼續進行服務。

主從復制

Redis中主從節點復制數據有全量復制和部分復制之分。

舊版本全量復制功能的實現

全量復制使用snyc命令來實現，其流程是：

• 從服務器向主服務器發送sync命令。

• 主服務器在收到sync命令之后，調用bgsave命令生成***的rdb文件，將這個文件同步給從服務器，這樣從服務器載入這個rdb文件之后，狀態就會和主服務器執行bgsave命令時候的一致。

• 主服務器將保存在命令緩沖區中的寫命令同步給從服務器，從服務器執行這些命令，這樣從服務器的狀態就跟主服務器當前狀態一致了。

舊版本全量復制功能，其***的問題是從服務器斷線重連時，即便在從服務器上已經有一部分數據了，也需要進行全量復制，這樣做的效率很低，于是新版本的Redis在這部分做了改進。

新版本全量復制功能的實現

新版本Redis使用psync命令來代替sync命令，該命令既可以實現完整全同步也可以實現部分同步。

復制偏移量

執行復制的雙方，主從服務器，分別會維護一個復制偏移量：

• 主服務器每次向從服務器同步了N字節數據之后，將修改自己的復制偏移量+N。

• 從服務器每次從主服務器同步了N字節數據之后，將修改自己的復制偏移量+N。

復制積壓緩沖區

主服務器內部維護了一個固定長度的先進先出隊列做為復制積壓緩沖區，其默認大小為1MB。

在主服務器進行命令傳播時，不僅會將寫命令同步到從服務器，還會將寫命令寫入復制積壓緩沖區。

服務器運行ID

每個Redis服務器，都有其運行ID，運行ID由服務器在啟動時自動生成，主服務器會將自己的運行ID發送給從服務器，而從服務器會將主服務器的運行ID保存起來。

從服務器Redis斷線重連之后進行同步時，就是根據運行ID來判斷同步的進度：

• 如果從服務器上面保存的主服務器運行ID與當前主服務器運行ID一致，則認為這一次斷線重連連接的是之前復制的主服務器，主服務器可以繼續嘗試部分同步操作。

• 否則，如果前后兩次主服務器運行ID不相同，則認為是完成全同步流程。

psync命令流程

有了前面的準備，下面開始分析psync命令的流程：

• 如果從服務器之前沒有復制過任何主服務器，或者之前執行過slaveof no one命令，那么從服務器就會向主服務器發送psync ? -1命令，請求主服務器進行數據的全量同步。

• 否則，如果前面從服務器已經同步過部分數據，那么從服務器向主服務器發送psync <runid> <offset>命令，其中runid是上一次主服務器的運行id，offset是當前從服務器的復制偏移量。

前面兩種情況主服務器收到psync命令之后，會出現以下三種可能：

• 主服務器返回+fullresync <runid> <offset>回復，表示主服務器要求與從服務器進行完整的數據全量同步操作。其中，runid是當前主服務器運行id，而offset是當前主服務器的復制偏移量。

• 如果主服務器應答+continue，那么表示主服務器與從服務器進行部分數據同步操作，將從服務器缺失的數據同步過來即可。

• 如果主服務器應答-err，那么表示主服務器版本低于2.8，識別不了psync命令，此時從服務器將向主服務器發送sync命令，執行完整的全量數據同步。

哨兵機制概述

Redis使用哨兵機制來實現高可用(HA)，其大概工作原理是：

• Redis使用一組哨兵（sentinel）節點來監控主從redis服務的可用性。

• 一旦發現Redis主節點失效，將選舉出一個哨兵節點作為***（leader）。

• 哨兵***再從剩余的從Redis節點中選出一個Redis節點作為新的主Redis節點對外服務。

以上將Redis節點分為兩類：

• 哨兵節點（sentinel）：負責監控節點的運行情況。

• 數據節點：即正常服務客戶端請求的Redis節點，有主從之分。

以上是大體的流程，這個流程需要解決以下幾個問題：

• 如何對Redis數據節點進行監控？

• 如何確定一個Redis數據節點失效？

• 如何選擇出一個哨兵***節點？

• 哨兵節點選擇新的主Redis節點的依據是什么？

以下來逐個回答這些問題。

三個監控任務

哨兵節點通過三個定時監控任務監控Redis數據節點的服務可用性。

info命令

每隔10秒，每個哨兵節點都會向主、從Redis數據節點發送info命令，獲取新的拓撲結構信息。

Redis拓撲結構信息包括了：

• 本節點角色：主或從。

• 主從節點的地址、端口信息。

這樣，哨兵節點就能從info命令中自動獲取到從節點信息，因此那些后續才加入的從節點信息不需要顯式配置就能自動感知。

向__sentinel__:hello頻道同步信息

每隔2秒，每個哨兵節點將會向Redis數據節點的__sentinel__:hello頻道同步自身得到的主節點信息以及當前哨兵節點的信息，由于其他哨兵節點也訂閱了這個頻道，因此實際上這個操作可以交換哨兵節點之間關于主節點以及哨兵節點的信息。

這一操作實際上完成了兩件事情： * 發現新的哨兵節點：如果有新的哨兵節點加入，此時保存下來這個新哨兵節點的信息，后續與該哨兵節點建立連接。 * 交換主節點的狀態信息，作為后續客觀判斷主節點下線的依據。

向數據節點做心跳探測

每隔1秒，每個哨兵節點向主、從數據節點以及其他sentinel節點發送ping命令做心跳探測，這個心跳探測是后續主觀判斷數據節點下線的依據。

主觀下線和客觀下線

主觀下線

上面三個監控任務中的第三個探測心跳任務，如果在配置的down-after-milliseconds之后沒有收到有效回復，那么就認為該數據節點“主觀下線（sdown）”。

為什么稱為“主觀下線”？因為在一個分布式系統中，有多個機器在一起聯動工作，網絡可能出現各種狀況，僅憑一個節點的判斷還不足以認為一個數據節點下線了，這就需要后面的“客觀下線”。

客觀下線

當一個哨兵節點認為主節點主觀下線時，該哨兵節點需要通過”sentinel is-master-down-by addr”命令向其他哨兵節點咨詢該主節點是否下線了，如果有超過半數的哨兵節點都回答了下線，此時認為主節點“客觀下線”。

選舉哨兵***

當主節點客觀下線時，需要選舉出一個哨兵節點做為哨兵***，以完成后續選出新的主節點的工作。

這個選舉的大體思路是：

• 每個哨兵節點通過向其他哨兵節點發送”sentinel is-master-down-by addr”命令來申請成為哨兵***。

• 而每個哨兵節點在收到一個”sentinel is-master-down-by addr”命令時，只允許給***個節點投票，其他節點的該命令都會被拒絕。

• 如果一個哨兵節點收到了半數以上的同意票，則成為哨兵***。

• 如果前面三步在一定時間內都沒有選出一個哨兵***，將重新開始下一次選舉。

可以看到，這個選舉***的流程很像raft中選舉leader的流程。

選出新的主節點

在剩下的Redis從節點中，按照以下順序來選擇新的主節點：

• 過濾掉“不健康”的數據節點：比如主觀下線、斷線的從節點、五秒內沒有回復過哨兵節點ping命令的節點、與主節點失聯的從節點。

• 選擇slave-priority（從節點優先級）***的從節點，如果存在則返回不存在則繼續后面的流程。

• 選擇復制偏移量***的從節點，這意味著這個從節點上面的數據最完整，如果存在則返回不存在則繼續后面的流程。

• 到了這里，所有剩余從節點的狀態都是一樣的，選擇runid最小的從節點。

提升新的主節點

選擇了新的主節點之后，還需要***的流程讓該節點成為新的主節點：

• 哨兵***向上一步選出的從節點發出“slaveof no one”命令，讓該節點成為主節點。

• 哨兵***向剩余的從節點發送命令，讓它們成為新主節點的從節點。

• 哨兵節點集合會將原來的主節點更新為從節點，當其恢復之后命令它去復制新的主節點的數據。

如果過程中哨兵***失效怎么辦？

原文地址：

https://www.codedump.info/post/20190409-redis-sentinel/

參考閱讀：

• 主流微服務注冊中心淺析和對比

• 一圖了解Google工具棧

• Facebook F4架構解讀：千億級圖片存儲Haystack的演進

• 被視為代替Kafka的消息隊列：Apache Pulsar設計簡介