共計 3438 個字符，預計需要花費 9 分鐘才能閱讀完成。

今天丸趣 TV 小編給大家分享一下 Redis 高可用的兩種實現方案是什么的相關知識點，內容詳細，邏輯清晰，相信大部分人都還太了解這方面的知識，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來了解一下吧。

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”命令，讓該節點成為主節點。

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

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

以上就是“Redis 高可用的兩種實現方案是什么”這篇文章的所有內容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，丸趣 TV 小編每天都會為大家更新不同的知識，如果還想學習更多的知識，請關注丸趣 TV 行業資訊頻道。