我們了解到在主從庫集群模式下，如果從庫發(fā)生故障，客戶端可以繼續(xù)向主庫或其他從庫發(fā)送請求，執(zhí)行相應(yīng)的操作。然而，當主庫發(fā)生故障時，會直接影響從庫的同步，因為此時從庫失去了可用的主庫進行數(shù)據(jù)復制。

而且，如果客戶端發(fā)送的都是讀操作請求，那還可以由從庫繼續(xù)提供服務(wù)，這在純讀的業(yè)務(wù)場景下還能被接受。但是，一旦有寫操作請求了，按照主從庫模式下的讀寫分離要求，需要由主庫來完成寫操作。此時，也沒有實例可以來服務(wù)客戶端的寫操作請求了，如下圖所示：

圖片

主庫故障后，導致從庫無法提供寫操作的服務(wù)，這種情況是不可接受的。因此，在主庫發(fā)生故障時，我們需要啟動一個新的主庫，通常是將一個從庫升級為主庫并將其作為新的主庫。然而，這涉及到解決三個核心問題：

1. 如何確定主庫已經(jīng)宕機了？
2. 從眾多從庫中選擇哪一個作為新的主庫？
3. 如何通知從庫和客戶端關(guān)于新主庫的變化？

這正是哨兵機制的任務(wù)。在 Redis 主從集群中，哨兵機制是實現(xiàn)自動主從切換的關(guān)鍵，它成功地解決了上述三個問題，確保系統(tǒng)的可用性。接下來，我們將深入學習和了解哨兵機制的工作原理。

哨兵機制的基本流程

哨兵其實就是一個運行在特殊模式下的 Redis 進程，主從庫實例運行的同時，它也在運行。哨兵主要負責的就是三個任務(wù)：監(jiān)控、選主（選擇主庫）和通知。

我們先看監(jiān)控。監(jiān)控是指哨兵進程在運行時，周期性地給所有的主從庫發(fā)送 PING 命令，檢測它們是否仍然在線運行。如果從庫沒有在規(guī)定時間內(nèi)響應(yīng)哨兵的 PING 命令，哨兵就會把它標記為“下線狀態(tài)”；同樣，如果主庫也沒有在規(guī)定時間內(nèi)響應(yīng)哨兵的 PING 命令，哨兵就會判定主庫下線，然后開始自動切換主庫的流程。

這個流程首先是執(zhí)行哨兵的第二個任務(wù)，選主。主庫掛了以后，哨兵就需要從很多個從庫里，按照一定的規(guī)則選擇一個從庫實例，把它作為新的主庫。這一步完成后，現(xiàn)在的集群里就有了新主庫。

然后，哨兵會執(zhí)行最后一個任務(wù)：通知。在執(zhí)行通知任務(wù)時，哨兵會把新主庫的連接信息發(fā)給其他從庫，讓它們執(zhí)行 replicaof 命令，和新主庫建立連接，并進行數(shù)據(jù)復制。同時，哨兵會把新主庫的連接信息通知給客戶端，讓它們把請求操作發(fā)到新主庫上。

我畫了一張圖片，展示了這三個任務(wù)以及它們各自的目標。

哨兵機制的三項任務(wù)與目標

在這三個任務(wù)中，通知任務(wù)相對來說比較簡單，哨兵只需要把新主庫信息發(fā)給從庫和客戶端，讓它們和新主庫建立連接就行，并不涉及決策的邏輯。但是，在監(jiān)控和選主這兩個任務(wù)中，哨兵需要做出兩個決策：

在監(jiān)控任務(wù)中，哨兵需要判斷主庫是否處于下線狀態(tài)；

在選主任務(wù)中，哨兵也要決定選擇哪個從庫實例作為主庫。

接下來，我們就先說說如何判斷主庫的下線狀態(tài)。

你首先要知道的是，哨兵對主庫的下線判斷有“主觀下線”和“客觀下線”兩種。那么，為什么會存在兩種判斷呢？它們的區(qū)別和聯(lián)系是什么呢？

主觀下線和客觀下線

我先解釋下什么是“主觀下線”。

哨兵進程會使用 PING 命令檢測它自己和主、從庫的網(wǎng)絡(luò)連接情況，用來判斷實例的狀態(tài)。如果哨兵發(fā)現(xiàn)主庫或從庫對 PING 命令的響應(yīng)超時了，那么，哨兵就會先把它標記為“主觀下線”。

如果檢測的是從庫，那么，哨兵簡單地把它標記為“主觀下線”就行了，因為從庫的下線影響一般不太大，集群的對外服務(wù)不會間斷。

但是，如果檢測的是主庫，那么，哨兵還不能簡單地把它標記為“主觀下線”，開啟主從切換。因為很有可能存在這么一個情況：那就是哨兵誤判了，其實主庫并沒有故障。可是，一旦啟動了主從切換，后續(xù)的選主和通知操作都會帶來額外的計算和通信開銷。

為了避免這些不必要的開銷，我們要特別注意誤判的情況。

首先，我們要知道啥叫誤判。很簡單，就是主庫實際并沒有下線，但是哨兵誤以為它下線了。誤判一般會發(fā)生在集群網(wǎng)絡(luò)壓力較大、網(wǎng)絡(luò)擁塞，或者是主庫本身壓力較大的情況下。

一旦哨兵判斷主庫下線了，就會開始選擇新主庫，并讓從庫和新主庫進行數(shù)據(jù)同步，這個過程本身就會有開銷，例如，哨兵要花時間選出新主庫，從庫也需要花時間和新主庫同步。而在誤判的情況下，主庫本身根本就不需要進行切換的，所以這個過程的開銷是沒有價值的。正因為這樣，我們需要判斷是否有誤判，以及減少誤判。

那怎么減少誤判呢？在日常生活中，當我們要對一些重要的事情做判斷的時候，經(jīng)常會和家人或朋友一起商量一下，然后再做決定。

哨兵機制也是類似的，它通常會采用多實例組成的集群模式進行部署，這也被稱為哨兵集群。引入多個哨兵實例一起來判斷，就可以避免單個哨兵因為自身網(wǎng)絡(luò)狀況不好，而誤判主庫下線的情況。同時，多個哨兵的網(wǎng)絡(luò)同時不穩(wěn)定的概率較小，由它們一起做決策，誤判率也能降低。

這節(jié)課，你只需要先理解哨兵集群在減少誤判方面的作用，就行了。至于具體的運行機制，下節(jié)課我們再重點學習。

在判斷主庫是否下線時，不能由一個哨兵說了算，只有大多數(shù)的哨兵實例，都判斷主庫已經(jīng)“主觀下線”了，主庫才會被標記為“客觀下線”，這個叫法也是表明主庫下線成為一個客觀事實了。這個判斷原則就是：少數(shù)服從多數(shù)。同時，這會進一步觸發(fā)哨兵開始主從切換流程。

為了方便你理解，我再畫一張圖展示一下這里的邏輯。

如下圖所示，Redis 主從集群有一個主庫、三個從庫，還有三個哨兵實例。在圖片的左邊，哨兵 2 判斷主庫為“主觀下線”，但哨兵 1 和 3 卻判定主庫是上線狀態(tài)，此時，主庫仍然被判斷為處于上線狀態(tài)。在圖片的右邊，哨兵 1 和 2 都判斷主庫為“主觀下線”，此時，即使哨兵 3 仍然判斷主庫為上線狀態(tài)，主庫也被標記為“客觀下線”了。

客觀下線的判斷

簡單來說，“客觀下線”的標準就是，當有 N 個哨兵實例時，最好要有 N/2 + 1 個實例判斷主庫為“主觀下線”，才能最終判定主庫為“客觀下線”。這樣一來，就可以減少誤判的概率，也能避免誤判帶來的無謂的主從庫切換。（當然，有多少個實例做出“主觀下線”的判斷才可以，可以由 Redis 管理員自行設(shè)定）。

好了，到這里，你可以看到，借助于多個哨兵實例的共同判斷機制，我們就可以更準確地判斷出主庫是否處于下線狀態(tài)。如果主庫的確下線了，哨兵就要開始下一個決策過程了，即從許多從庫中，選出一個從庫來做新主庫。

如何選定新主庫？

一般來說，我把哨兵選擇新主庫的過程稱為“篩選 + 打分”。簡單來說，我們在多個從庫中，先按照一定的篩選條件，把不符合條件的從庫去掉。然后，我們再按照一定的規(guī)則，給剩下的從庫逐個打分，將得分最高的從庫選為新主庫，如下圖所示：

新主庫的選擇過程

在上述段落中，我們需要明晰兩個關(guān)鍵的“一定”?，F(xiàn)在，讓我們詳細討論這里的“一定”究竟指的是什么。

首先，讓我們來探討所選從庫的篩選條件。

通常情況下，我們必須確保所選的從庫仍然處于在線運行狀態(tài)。然而，在選擇新主庫時，僅僅考慮從庫的當前在線狀態(tài)是不夠的，因為正常在線并不代表它就是最佳的主庫選擇。

設(shè)想一下，如果在選主時，我們選中一個正常在線的從庫并開始使用它。不過，不久后，它的網(wǎng)絡(luò)連接發(fā)生故障，這將迫使我們重新選擇主庫。這顯然不符合我們的期望。

因此，在進行主庫選擇時，除了檢查從庫的當前在線狀態(tài)，還需要考慮它以前的網(wǎng)絡(luò)連接狀態(tài)。如果一個從庫經(jīng)常與主庫斷開連接，并且斷開連接的次數(shù)超出了特定的閾值，那么我們就有理由相信，這個從庫的網(wǎng)絡(luò)狀況并不太可靠，因此可以將其排除在主庫的選擇之外。

具體怎么判斷呢？你使用配置項 down-after-milliseconds * 10。其中，down-after-milliseconds 是我們認定主從庫斷連的最大連接超時時間。如果在 down-after-milliseconds 毫秒內(nèi)，主從節(jié)點都沒有通過網(wǎng)絡(luò)聯(lián)系上，我們就可以認為主從節(jié)點斷連了。如果發(fā)生斷連的次數(shù)超過了 10 次，就說明這個從庫的網(wǎng)絡(luò)狀況不好，不適合作為新主庫。

好了，這樣我們就過濾掉了不適合做主庫的從庫，完成了篩選工作。

接下來就要給剩余的從庫打分了。我們可以分別按照三個規(guī)則依次進行三輪打分，這三個規(guī)則分別是從庫優(yōu)先級、從庫復制進度以及從庫 ID 號。只要在某一輪中，有從庫得分最高，那么它就是主庫了，選主過程到此結(jié)束。如果沒有出現(xiàn)得分最高的從庫，那么就繼續(xù)進行下一輪。

第一輪：優(yōu)先級最高的從庫得分高。

用戶可以通過 slave-priority 配置項，給不同的從庫設(shè)置不同優(yōu)先級。比如，你有兩個從庫，它們的內(nèi)存大小不一樣，你可以手動給內(nèi)存大的實例設(shè)置一個高優(yōu)先級。在選主時，哨兵會給優(yōu)先級高的從庫打高分，如果有一個從庫優(yōu)先級最高，那么它就是新主庫了。如果從庫的優(yōu)先級都一樣，那么哨兵開始第二輪打分。

第二輪：和舊主庫同步程度最接近的從庫得分高。

這個規(guī)則的依據(jù)是，如果選擇和舊主庫同步最接近的那個從庫作為主庫，那么，這個新主庫上就有最新的數(shù)據(jù)。

如何判斷從庫和舊主庫間的同步進度呢？

上節(jié)課我向你介紹過，主從庫同步時有個命令傳播的過程。在這個過程中，主庫會用 master_repl_offset 記錄當前的最新寫操作在 repl_backlog_buffer 中的位置，而從庫會用 slave_repl_offset 這個值記錄當前的復制進度。

此時，我們想要找的從庫，它的 slave_repl_offset 需要最接近 master_repl_offset。如果在所有從庫中，有從庫的 slave_repl_offset 最接近 master_repl_offset，那么它的得分就最高，可以作為新主庫。

就像下圖所示，舊主庫的 master_repl_offset 是 1000，從庫 1、2 和 3 的 slave_repl_offset 分別是 950、990 和 900，那么，從庫 2 就應(yīng)該被選為新主庫。

基于復制進度的新主庫選主原則

當然，如果有兩個從庫的 slave_repl_offset 值大小是一樣的（例如，從庫 1 和從庫 2 的 slave_repl_offset 值都是 990），我們就需要給它們進行第三輪打分了。

第三輪：ID 號小的從庫得分高。

每個實例都會有一個 ID，這個 ID 就類似于這里的從庫的編號。目前，Redis 在選主庫時，有一個默認的規(guī)定：在優(yōu)先級和復制進度都相同的情況下，ID 號最小的從庫得分最高，會被選為新主庫。

到這里，新主庫就被選出來了，“選主”這個過程就完成了。

我們再回顧下這個流程。首先，哨兵會按照在線狀態(tài)、網(wǎng)絡(luò)狀態(tài)，篩選過濾掉一部分不符合要求的從庫，然后，依次按照優(yōu)先級、復制進度、ID 號大小再對剩余的從庫進行打分，只要有得分最高的從庫出現(xiàn)，就把它選為新主庫。

小結(jié)

我們已經(jīng)一起探討了哨兵機制，這是確保 Redis 提供持續(xù)服務(wù)的關(guān)鍵要素。具體來說，主從數(shù)據(jù)庫的數(shù)據(jù)同步是數(shù)據(jù)可靠性的基石。在主數(shù)據(jù)庫發(fā)生故障時，自動執(zhí)行的主從切換是服務(wù)不中斷的重要支持。

Redis 的哨兵機制自動執(zhí)行以下三項重要功能，實現(xiàn)了主從切換，從而降低了 Redis 集群的維護成本：

1. 監(jiān)測主庫運行狀態(tài)：監(jiān)測主庫的運行狀態(tài)，以確定主庫是否客觀下線，即無法提供有效服務(wù)。
2. 選擇新主庫：一旦主庫被客觀下線，哨兵機制會選擇一個新的主庫，以維護集群的可用性。
3. 通知從庫和客戶端：選定新主庫后，哨兵會通知相關(guān)從庫切換到新的主庫，以確保數(shù)據(jù)同步。同時，客戶端也會被重定向到新的主庫，以繼續(xù)訪問數(shù)據(jù)。

為了減少誤判，通常使用多個哨兵實例進行部署，它們依據(jù)“多數(shù)原則”來判斷主庫的客觀下線情況。通常情況下，三個哨兵實例足以支持，只需兩個哨兵認定主庫已客觀下線，切換過程將開始。當需要更高的判斷準確性時，可以考慮增加哨兵的數(shù)量，例如五個哨兵。

然而，通過多個哨兵實例來減少誤判可能引入新的挑戰(zhàn)：

• 哨兵實例故障處理：哨兵集群中如果有實例發(fā)生故障，可能會影響主庫狀態(tài)判斷和主從切換。因此，需要有效地管理哨兵集群的高可用性。
• 主從切換決策：在多數(shù)哨兵實例達成共識，認定主庫客觀下線后，需要決定哪個哨兵實例來執(zhí)行主從切換。這涉及一些機制，如選舉，以確保選出的新主庫是最合適的。

要理解并應(yīng)對這些挑戰(zhàn)，需要深入了解哨兵集群及其配置。這有助于確保 Redis 集群在面臨故障時仍然能夠提供穩(wěn)定的高可用性服務(wù)。在下一篇中，我們將深入探討哨兵集群的工作原理和相關(guān)問題。