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

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

圖片

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

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

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

哨兵機制的基本流程

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

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

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

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

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

哨兵機制的三項任務與目標

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

在監控任務中，哨兵需要判斷主庫是否處于下線狀態；

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

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

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

主觀下線和客觀下線

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

哨兵進程會使用 PING 命令檢測它自己和主、從庫的網絡連接情況，用來判斷實例的狀態。如果哨兵發現主庫或從庫對 PING 命令的響應超時了，那么，哨兵就會先把它標記為“主觀下線”。

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

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

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

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

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

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

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

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

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

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

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

客觀下線的判斷

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

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

如何選定新主庫？

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

新主庫的選擇過程

在上述段落中，我們需要明晰兩個關鍵的“一定”。現在，讓我們詳細討論這里的“一定”究竟指的是什么。

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

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

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

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

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

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

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

第一輪：優先級最高的從庫得分高。

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

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

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

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

上節課我向你介紹過，主從庫同步時有個命令傳播的過程。在這個過程中，主庫會用 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 就應該被選為新主庫。

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

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

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

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

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

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

小結

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

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

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

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

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

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

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