死磕 NoSQL 數據庫系列（九）：Redis sentinel 哨兵集群原理、部署及數據恢復

點關注公眾號，回復“1024”獲取2TB學習資源！

前面我們介紹了：Redis 的持久化、主從復制與數據恢復。今天我將詳細的為大家介紹 Redis sentinel( Redis 哨兵集群原理、功能、部署及數據恢復等)相關知識，希望大家能夠從中收獲多多！如有幫助，請點在看、轉發支持一波！！！

在上文主從復制的基礎上，如果主節點出現故障該怎么辦呢？在 Redis 主從集群中，哨兵機制是實現主從庫自動切換的關鍵機制，它有效地解決了主從復制模式下故障轉移的問題。

Redis Sentinel，即 Redis 哨兵，在 Redis 2.8 版本開始引入。哨兵的核心功能是主節點的自動故障轉移。

下圖是一個典型的哨兵集群監控的邏輯圖：哨兵實現了什么功能呢？

下面是Redis官方文檔的描述：監控（Monitoring）：哨兵會不斷地檢查主節點和從節點是否運作正常。自動故障轉移（Automatic failover）：當主節點不能正常工作時，哨兵會開始自動故障轉移操作，它會將失效主節點的其中一個從節點升級為新的主節點，并讓其他從節點改為復制新的主節點。配置提供者（Configuration provider）：客戶端在初始化時，通過連接哨兵來獲得當前Redis服務的主節點地址。通知（Notification）：哨兵可以將故障轉移的結果發送給客戶端。

其中，監控和自動故障轉移功能，使得哨兵可以及時發現主節點故障并完成轉移；而配置提供者和通知功能，則需要在與客戶端的交互中才能體現。哨兵集群的組建

上圖中哨兵集群是如何組件的呢？哨兵實例之間可以相互發現，要歸功于 Redis 提供的 pub/sub 機制，也就是發布/訂閱機制。

在主從集群中，主庫上有一個名為的頻道，不同哨兵就是通過它來相互發現，實現互相通信的。在下圖中，哨兵 1 把自己的 IP（172.16.19.3）和端口（26579）發布到頻道上，哨兵 2 和 3 訂閱了該頻道。那么此時，哨兵 2 和 3 就可以從這個頻道直接獲取哨兵 1 的 IP 地址和端口號。然后，哨兵 2、3 可以和哨兵 1 建立網絡連接。通過這個方式，哨兵 2 和 3 也可以建立網絡連接，這樣一來，哨兵集群就形成了。它們相互間可以通過網絡連接進行通信，比如說對主庫有沒有下線這件事兒進行判斷和協商。更多關于 Redis 學習的文章，請參閱：NoSQL 數據庫系列之 Redis ，本系列持續更新中。

哨兵監控什么呢？怎么監控呢？

這是由哨兵向主庫發送 INFO 命令來完成的。就像下圖所示，哨兵 2 給主庫發送 INFO 命令，主庫接受到這個命令后，就會把從庫列表返回給哨兵。接著，哨兵就可以根據從庫列表中的連接信息，和每個從庫建立連接，并在這個連接上持續地對從庫進行監控。哨兵 1 和 3 可以通過相同的方法和從庫建立連接。主庫下線的判定

哨兵如何判斷主庫已經下線了呢？

首先要理解兩個概念：主觀下線和客觀下線主觀下線：任何一個哨兵都是可以監控探測，并作出Redis節點下線的判斷；客觀下線：有哨兵集群共同決定Redis節點是否下線；

當某個哨兵（如下圖中的哨兵2）判斷主庫“主觀下線”后，就會給其他哨兵發送 命令。接著，其他哨兵會根據自己和主庫的連接情況，做出 Y 或 N 的響應，Y 相當于贊成票，N 相當于反對票。如果贊成票數（這里是2）是大于等于哨兵配置文件中的 配置項（比如這里如果是quorum=2）, 則可以判定主庫客觀下線了。

判斷完主庫下線后，由哪個哨兵節點來執行主從切換呢？這里就需要哨兵集群的選舉機制了。為什么必然會出現選舉/共識機制？

為了避免哨兵的單點情況發生，所以需要一個哨兵的分布式集群。作為分布式集群，必然涉及共識問題（即選舉問題）；同時故障的轉移和通知都只需要一個主的哨兵節點就可以了。哨兵的選舉機制是什么樣的？

哨兵的選舉機制其實很簡單，就是一個Raft選舉算法：選舉的票數大于等于num(sentinels)/2+1時，將成為領導者，如果沒有超過，繼續選舉任何一個想成為 Leader 的哨兵，要滿足兩個條件：第一，拿到半數以上的贊成票；第二，拿到的票數同時還需要大于等于哨兵配置文件中的 quorum 值。

以 3 個哨兵為例，假設此時的 quorum 設置為 2，那么，任何一個想成為 Leader 的哨兵只要拿到 2 張贊成票，就可以了。更進一步理解

這里很多人會搞混 判定客觀下線 和 是否能夠主從切換（用到選舉機制） 兩個概念，我們再看一個例子。

Redis 1主4從，5個哨兵，哨兵配置quorum為2，如果3個哨兵故障，當主庫宕機時，哨兵能否判斷主庫“客觀下線”？能否自動切換？

經過實際測試：

1、哨兵集群可以判定主庫“主觀下線”。由于quorum=2，所以當一個哨兵判斷主庫“主觀下線”后，詢問另外一個哨兵后也會得到同樣的結果，2個哨兵都判定“主觀下線”，達到了quorum的值，因此，哨兵集群可以判定主庫為“客觀下線”。

2、但哨兵不能完成主從切換。哨兵標記主庫“客觀下線后”，在選舉“哨兵領導者”時，一個哨兵必須拿到超過多數的選票(5/2+1=3票)。但目前只有2個哨兵活著，無論怎么投票，一個哨兵最多只能拿到2票，永遠無法達到選票的結果。新主庫的選出

主庫既然判定客觀下線了，那么如何從剩余的從庫中選擇一個新的主庫呢？過濾掉不健康的（下線或斷線），沒有回復過哨兵ping響應的從節點選擇從節點優先級最高（redis.conf）的選擇復制偏移量最大，只復制最完整的從節點更多關于 Redis 學習的文章，請參閱：NoSQL 數據庫系列之 Redis ，本系列持續更新中。

新的主庫選擇出來后，就可以開始進行故障的轉移了。

假設根據我們一開始的圖：（我們假設：判斷主庫客觀下線了，同時選出是哨兵leader）故障轉移流程如下將slave-1脫離原從節點（PS: 5.0 中應該是)，升級主節點，將從節點slave-2指向新的主節點通知客戶端主節點已更換將原主節點（oldMaster）變成從節點，指向新的主節點

轉移之后環境準備

配置哨兵集群步驟：1.在所有節點搭建redis2.配置主從復制，一主兩從3.在所有節點配置sentinel，啟動sentinel后，配置文件會自動增加在所有機器上部署redis

192.168.81.210配置

192.168.81.220配置

由于redis-1已經部署好了一套redis，我們可以直接復制過來使用

192.168.81.230配置

由于redis-1已經部署好了一套redis，我們可以直接復制過來使用

三臺redis部署完成

配置redis主從

要在兩臺slave上同步主庫配置

部署哨兵進程sentinel

配置文件解釋

三臺redis服務器都要按如下配置，已經將配置文件中的bind寫成了系統變量，在配合cat寫入到文件，因此直接執行如下命令即可

配置完記得查看下配置文件bind一列是否是各自主機的ip地址啟動哨兵觀察配置文件的變化

三臺機器都這么操作啟動哨兵

觀察哨兵啟動前后配置文件的變化啟動前啟動后

每臺哨兵主機都自動增加了一個myid的配置，這個就是當主庫掛掉后，哨兵選舉的依據，判斷誰的myid大誰就當選為主庫。

每臺哨兵主機還自動增加了sentinel known-sentinel這個配置，這個配置每個哨兵會記錄集群中其他節點的id號，這樣就能夠實現信息共享，即使應用在詢問哨兵進程誰是主庫，這時由于每個哨兵進程都有其他節點的信息，因此就能里面告訴應用誰是主庫。模擬主庫故障驗證應用是否可用

配置完哨兵后，每個節點上都有集群的信息共享，當主庫掛掉后，哨兵進程確認主庫下線了，哨兵根據各自的id大小選舉新的主庫，接替主庫的工作，保證應用程序不受影響，當主庫修復好后，在通過提權的方式先同步目前主庫的數據，在讓自身成為主庫。

主庫掛掉其他節點配置文件的變化

主庫掛掉后，其他兩個節點選舉出master后，配置文件也會填寫為新master的地址。至此，一個 Redis 哨兵集群架構說部署完成了。更多關于 Redis 學習的文章，請參閱：NoSQL 數據庫系列之 Redis ，本系列持續更新中。

當主庫修復后重新上線首先通過哨兵知道誰是當前的主庫，然后就會去找主庫同步數據，并且會自動修改配置文件，當數據同步后，想恢復的主庫重新成為主庫則需要把主庫的權重調高，然后重新選舉，這時原來的主庫就能成為新的主庫，調整完再將主庫的權重值調成默認的。實現思路1.將故障的主庫重新恢復2.查看當前的主從狀態，驗證由于主庫宕機，與從庫產生的數據是否同步3.調整權重值4.重新選舉，使原來的主庫變成新的主庫5.恢復的主庫重新成為新的主庫后，要把調整的權重值全部變成默認值

主庫可以重新加入哨兵集群的前提：剩余的兩個節點必須有一個是master，且這兩個節點配置文件已經指定了新的master地址恢復損壞的主庫

查看恢復的主庫redis-1配置文件

可以看到已經自動修改為當前庫的地址查看恢復的主庫redis-1的主從關系

配置恢復的主庫的權重值，使其重新選舉為主庫

哨兵的選舉首先是查看誰的權重優先級比較高的當選為主庫權重優先級一致，就比較id，id大的當選

根據日志的輸出，可以明顯的看出調整了redis-1的權重優先級為150，比其他兩個節點的高，因此redis-1就變成了主庫。查看節點的主從復制關系。

主庫沒有同步的庫，其他兩個節點都同步redis-1的主庫。

將權重值調整為默認值

將權重值調整為默認值，方便下次選舉時作為判斷條件。

參考文章：https://www.pdai.tech/md/db/nosql-redis/db-redis-x-sentinel.html https://jiangxl.blog.csdn.net/article/details/120703648 https://jiangxl.blog.csdn.net/article/details/120703831

邀你加入技術交流群，2023 我們一起卷！

推薦閱讀 點擊標題可跳轉

CPU 100% 都打爆了，你卻連哪里出的問題都不知道

第一批因AI失業的人已出現！有公司直接裁掉一半

適合個人用戶使用的 6 款最佳虛擬化軟件！

中國電科（CETC）成都員工大罵領導截圖火遍全網

幾款讓人難以置信的軟件！純國產，真實用

Docker 認錯了！！！

Redis 主從復制及數據恢復實踐

PS：因為公眾號平臺更改了推送規則，如果不想錯過內容，記得讀完點一下“在看”，加個“星標”，這樣每次新文章推送才會第一時間出現在你的訂閱列表里。點“在看”支持我們吧!

南京兆柏數據恢復中心