首發(fā)博客地址

https://blog.zysicyj.top/

前面我們說過，redis采用了讀寫分離的方式實現(xiàn)高可靠。后面我們說了，為了防止主節(jié)點壓力過大，優(yōu)化成了主-從-從模式

思考一個問題，主節(jié)點此時掛了怎么辦

這里主從模式下涉及到的幾個問題：

1. 主庫真的掛了嗎？

2. 我們應當選擇哪個從庫作為主庫？

3. 怎樣讓其他從庫知道新的主庫信息呢？

4. 中斷的數(shù)據(jù)如何恢復？

哨兵機制就完美的解決了以上問題。

什么是哨兵機制？

Redis引入哨兵（Sentinel）機制的主要目的是為了增強其高可用性和自動故障恢復能力。在分布式系統(tǒng)中，特別是用作數(shù)據(jù)存儲的數(shù)據(jù)庫系統(tǒng)中，保障高可用性是至關重要的，以確保系統(tǒng)在面對節(jié)點故障等情況時能夠繼續(xù)提供服務。

以下是引入Redis哨兵機制的原因：

1. 「故障檢測和自動故障切換：」 哨兵允許您配置多個Redis節(jié)點，并監(jiān)視它們的運行狀況。如果主節(jié)點（Master）出現(xiàn)故障，哨兵可以自動檢測到并執(zhí)行故障切換，將一個可用的從節(jié)點（Slave）晉升為新的主節(jié)點，從而保證服務的可用性。

2. 「自動配置更新：」 當Redis節(jié)點的拓撲結構發(fā)生變化（比如添加或移除節(jié)點）時，哨兵能夠自動地通知客戶端和其他Redis節(jié)點進行配置更新，從而確保整個集群的正確配置。

3. 「監(jiān)控和報警：」 哨兵不僅監(jiān)視節(jié)點的健康狀態(tài)，還可以提供有關節(jié)點運行狀況的信息，例如主從復制是否正常、延遲情況等。這可以幫助管理員及時發(fā)現(xiàn)問題并采取措施。

4. 「無需人工干預的恢復：」 哨兵允許自動故障切換，這意味著當主節(jié)點出現(xiàn)問題時，系統(tǒng)可以自動將一個從節(jié)點提升為新的主節(jié)點，而無需管理員手動介入，從而縮短恢復時間。

Redis引入哨兵機制使得在分布式環(huán)境中更容易實現(xiàn)高可用性和故障恢復，而無需太多手動操作。哨兵機制可以確保Redis集群在節(jié)點故障時繼續(xù)提供穩(wěn)定的服務，對于那些對于高可用性要求較高的應用場景非常有用。

哨兵機制的基本流程

哨兵其實就是一個運行在特殊模式下的Redis進程，其隨著主從實例同時運行。

那么哨兵負責哪些活呢？主要是以下三點：

1. 監(jiān)控

2. 選主（選擇主庫）

3. 通知

監(jiān)控

Redis哨兵的監(jiān)控流程涉及多個步驟，用于實時監(jiān)控Redis集群中各個節(jié)點的狀態(tài)并采取必要的措施來確保集群的可用性和穩(wěn)定性。

1. 「節(jié)點發(fā)現(xiàn)和配置：」 哨兵通過配置文件指定要監(jiān)控的主節(jié)點和從節(jié)點。啟動哨兵后，它會連接到指定的節(jié)點，并獲取有關其他節(jié)點的信息，形成一個初始的監(jiān)控拓撲。

2. 「心跳檢測：」 哨兵會定期向監(jiān)控的節(jié)點發(fā)送PING命令來檢測節(jié)點是否存活。這些節(jié)點可以是主節(jié)點、從節(jié)點或其他哨兵節(jié)點。如果哨兵在一定時間內沒有收到響應，它會認為節(jié)點不可用。

3. 「節(jié)點狀態(tài)變更：」 當哨兵連續(xù)多次無法連接到一個節(jié)點時，它會將該節(jié)點標記為主觀下線。當多個哨兵都將節(jié)點標記為主觀下線時，這個節(jié)點會被認為是客觀下線。

4. 「故障判斷和選舉：」 當主節(jié)點被標記為客觀下線時，哨兵會執(zhí)行故障判斷。它會從剩余的健康主節(jié)點中選舉一個作為新的主節(jié)點，并將該信息廣播給其他哨兵和客戶端。故障判斷的邏輯考慮了多個因素，包括優(yōu)先級、最近一次復制偏移量等。

5. 「自動故障切換：」 如果主節(jié)點被標記為客觀下線，哨兵會通知從節(jié)點晉升為新的主節(jié)點。同時，哨兵會更新其他從節(jié)點的配置，使其復制新的主節(jié)點。這確保了即使主節(jié)點發(fā)生故障，集群仍然可以繼續(xù)提供服務。

6. 「監(jiān)控從節(jié)點：」 哨兵還會監(jiān)控從節(jié)點的狀態(tài)，包括從節(jié)點是否與主節(jié)點保持同步，以及從節(jié)點的復制延遲情況。如果從節(jié)點無法同步或者復制延遲過高，哨兵會將其標記為不健康。

7. 「節(jié)點恢復：」 如果一個節(jié)點從客觀下線狀態(tài)恢復，哨兵會將其標記為健康，并將其重新納入集群中。從節(jié)點恢復后，它會重新同步主節(jié)點的數(shù)據(jù)。

8. 「配置更新：」 如果集群的拓撲發(fā)生變化，例如添加或移除節(jié)點，哨兵會自動更新配置，以便客戶端能夠正確連接到集群。

9. 「事件通知：」 哨兵通過發(fā)布訂閱機制向訂閱者（通常是客戶端）發(fā)送有關集群狀態(tài)變化的消息。這使得應用程序能夠根據(jù)實時的集群狀態(tài)做出相應的決策。

10. 「持續(xù)監(jiān)控：」 哨兵會持續(xù)地監(jiān)控集群中的節(jié)點，定期執(zhí)行心跳檢測、狀態(tài)更新和故障判斷，以確保集群的穩(wěn)定運行。

主觀下線與客觀下線

在Redis的哨兵監(jiān)控機制中，有兩個關鍵概念：主觀下線（Subjective Down）和客觀下線（Objective Down）。這些概念幫助哨兵判斷節(jié)點的可用性和故障狀態(tài)。

1. 「主觀下線（Subjective Down）：」 主觀下線是指單個哨兵節(jié)點認為一個特定的Redis節(jié)點（主節(jié)點、從節(jié)點或其他哨兵）不可用。主觀下線是一種主觀的判斷，是基于單個哨兵節(jié)點的觀察結果得出的。當一個哨兵無法連接到某個Redis節(jié)點，它會將該節(jié)點標記為主觀下線。多個哨兵節(jié)點可能會對同一個節(jié)點發(fā)出主觀下線標記。

2. 「客觀下線（Objective Down）：」 客觀下線是指在整個哨兵集合中達成一致，認為某個特定的Redis節(jié)點不可用?？陀^下線是一種更客觀的判斷，需要多個哨兵節(jié)點共同達成一致。當多個哨兵節(jié)點都主觀下線同一個Redis節(jié)點時，這個節(jié)點會被認為是客觀下線。

舉例說明：

• 假設有三個哨兵節(jié)點：Sentinel A、Sentinel B 和 Sentinel C，以及一個主節(jié)點 Master 和一個從節(jié)點 Slave。如果 Sentinel A 無法連接到 Master 節(jié)點，它會將 Master 標記為主觀下線。同樣地，如果 Sentinel B 也無法連接到 Master 節(jié)點，它也會將 Master 標記為主觀下線。但這還不足以讓 Master 被認為是客觀下線。

• 當 Sentinel A 和 Sentinel B 都主觀下線了 Master 節(jié)點，并且他們相互通信時發(fā)現(xiàn)了這個情況，他們就會在達成一致意見后將 Master 節(jié)點標記為客觀下線。這時，整個哨兵集合達成一致，認為 Master 節(jié)點已下線。

客觀下線是一個更嚴格的判斷，需要多個哨兵節(jié)點一致認為某個節(jié)點不可用，才會觸發(fā)后續(xù)的故障判斷和自動故障切換等動作。這種機制確保了在一個哨兵節(jié)點認為某節(jié)點下線時，不會立即觸發(fā)故障切換，以避免誤判造成不必要的切換。只有多個哨兵節(jié)點一致認為節(jié)點下線，才會觸發(fā)后續(xù)的故障處理流程。

如何選定新主庫

在Redis Sentinel模式中，當主節(jié)點（Master）發(fā)生故障導致下線后，哨兵會通過選舉過程選擇一個新的主節(jié)點（Master）來取代原來的主節(jié)點。選定新主庫的過程如下：

1. 「主觀下線和客觀下線判斷：」 當哨兵節(jié)點主觀下線（單個哨兵認為不可用）一個主節(jié)點時，如果多數(shù)哨兵都主觀下線了同一個主節(jié)點，那么這個主節(jié)點會被標記為客觀下線（多數(shù)派共識）。

2. 「選舉新主節(jié)點：」 當一個主節(jié)點被標記為客觀下線后，哨兵節(jié)點會開始選舉一個新的主節(jié)點。選舉過程如下：

• 哨兵會在所有沒有下線的從節(jié)點（Slaves）中選擇一個作為新主節(jié)點。「哨兵會選擇一個延遲最小、復制偏移量最大的從節(jié)點作為新主節(jié)點」。這確保了新主節(jié)點是最接近原主節(jié)點的從節(jié)點。

• 如果沒有合適的從節(jié)點，哨兵會選擇一個具備最高優(yōu)先級的從節(jié)點，將其升級為主節(jié)點。如果優(yōu)先級相同，那么哨兵會選擇一個復制偏移量最大的從節(jié)點。

3. 「故障轉移和切換：」 一旦新主節(jié)點被選定，哨兵會發(fā)起故障轉移操作。舊主節(jié)點會變成新主節(jié)點的一個從節(jié)點。其他從節(jié)點會重新配置，指向新的主節(jié)點。這個過程會保證盡量不丟失數(shù)據(jù)，并且保證整個集群的高可用性。

選定新主庫的過程是一個由哨兵節(jié)點協(xié)同工作的流程，確保了在主節(jié)點故障的情況下，盡可能地選擇一個合適的從節(jié)點作為新的主節(jié)點，實現(xiàn)集群的高可用性和數(shù)據(jù)完整性。

如何配置哨兵

1. 「哨兵配置文件：」 在Redis 6.x版本中，哨兵的配置文件名稱默認為redis-sentinel.conf。

2. 「配置變化：」 Redis 6.x版本引入了一些新的哨兵配置選項，以適應新的功能和改進。以下是一些常見的配置選項：

   sentinel monitor mymaster 127.0.0.1 6379 2 ? # 監(jiān)控名為 "mymaster" 的主節(jié)點，2表示至少需要2個哨兵同意主觀下線才會執(zhí)行故障轉移 sentinel down-after-milliseconds mymaster 5000 ? # 主觀下線判定為5秒無響應 sentinel parallel-syncs mymaster 1 ? # 執(zhí)行故障轉移時同時同步的從節(jié)點數(shù)量 sentinel failover-timeout mymaster 10000 ? # 故障轉移超時時間為10秒 sentinel auth-pass mymaster mypassword ? # 主節(jié)點的訪問密碼

3. 「啟動哨兵節(jié)點：」 在Redis 6.x版本中，啟動哨兵節(jié)點的命令為：

   redis-server?/path/to/redis-sentinel.conf?--sentinel


4. 「查看哨兵狀態(tài)：」 使用以下命令查看Redis 6.x版本哨兵節(jié)點的狀態(tài)：

   redis-cli?-p?26379
sentinel?master?mymaster???#?查看主節(jié)點的信息
sentinel?slaves?mymaster???#?查看從節(jié)點的信息
sentinel?sentinels?mymaster???#?查看其他哨兵節(jié)點的信息


哨兵是如何互相發(fā)現(xiàn)的？

我們查看配置可以看到，我們并沒有配置從節(jié)點的哨兵，我們只配置了主節(jié)點地址。

那么哨兵之間是如何互相發(fā)現(xiàn)通信的呢？

在Redis Sentinel（哨兵）集群中，哨兵節(jié)點之間通過發(fā)布訂閱機制來互相發(fā)現(xiàn)和通信。這種方式使得哨兵節(jié)點能夠監(jiān)控主節(jié)點和從節(jié)點的狀態(tài)，并進行故障檢測和故障轉移。

以下是哨兵集群如何通過發(fā)布訂閱機制互相發(fā)現(xiàn)的工作流程：

1. 「初始連接：」 在啟動時，每個哨兵節(jié)點會嘗試連接到指定的主節(jié)點。這些哨兵節(jié)點通過配置文件中的sentinel monitor命令指定要監(jiān)控的主節(jié)點信息。

2. 「Sentinel命令發(fā)布：」 當一個哨兵節(jié)點成功連接到主節(jié)點后，它會開始定期向主節(jié)點發(fā)送PING命令，以確保主節(jié)點處于活躍狀態(tài)。如果哨兵節(jié)點檢測到主節(jié)點不可用，它會將一個+switch-master命令發(fā)布到頻道中，通知其他哨兵節(jié)點。

3. 「發(fā)布訂閱機制：」 Redis的發(fā)布訂閱機制允許一個節(jié)點（發(fā)布者）向一個或多個節(jié)點（訂閱者）廣播消息。在哨兵集群中，每個哨兵節(jié)點都訂閱了一個名為__sentinel__:hello的頻道，用于接收其他哨兵節(jié)點發(fā)送的信息。

1. 「發(fā)現(xiàn)其他哨兵節(jié)點：」 當一個哨兵節(jié)點成功連接到主節(jié)點后，它會向__sentinel__:hello頻道發(fā)布一個"Hello"消息，其中包含它自己的信息（如IP地址和端口號）。其他哨兵節(jié)點通過訂閱這個頻道，可以獲取所有其他哨兵節(jié)點的信息。

2. 「收集哨兵信息：」 每個哨兵節(jié)點通過訂閱__sentinel__:hello頻道，收集到其他哨兵節(jié)點的信息。這使得每個哨兵節(jié)點都知道了集群中其他哨兵節(jié)點的存在。

3. 「故障檢測和轉移：」 當一個哨兵節(jié)點檢測到主節(jié)點不可用時，它會通過發(fā)布+switch-master命令來通知其他哨兵節(jié)點。這個命令包含了新的主節(jié)點信息，以及在執(zhí)行故障轉移時需要的其他信息。其他哨兵節(jié)點收到這個命令后，會進行判斷并可能發(fā)起故障轉移。

通過以上機制，哨兵節(jié)點可以相互發(fā)現(xiàn)和通信，共同監(jiān)控主節(jié)點和從節(jié)點的狀態(tài)，并在主節(jié)點下線時協(xié)同執(zhí)行故障轉移操作。這種發(fā)布訂閱機制確保了哨兵集群中節(jié)點之間的實時信息傳遞和協(xié)作。

由哪個哨兵執(zhí)行主從切換？

客觀下線具體判斷流程

1. 「故障檢測：」 哨兵節(jié)點定期向集群中的所有主節(jié)點和從節(jié)點發(fā)送PING命令來檢測節(jié)點的可用性。如果一個哨兵節(jié)點連續(xù)一定次數(shù)沒有收到節(jié)點的回復，就會將該節(jié)點標記為可能進入客觀下線狀態(tài)。

2. 「Quorum判斷：」 在判斷一個節(jié)點是否客觀下線時，需要考慮Quorum的概念。Quorum是指一個最小的投票數(shù)，當達到或超過這個投票數(shù)時，哨兵認為節(jié)點可能進入客觀下線狀態(tài)。Quorum的值通常設置為哨兵節(jié)點數(shù)量的一半加一。

3. 「投票過程：」 當哨兵節(jié)點開始懷疑某個節(jié)點可能客觀下線時，它會向其他哨兵節(jié)點發(fā)送一個SENTINEL is-master-down-by-addr命令，詢問其他哨兵節(jié)點是否也認為該節(jié)點客觀下線。其他哨兵節(jié)點會對此做出回應，根據(jù)回應的數(shù)量來判斷是否達到Quorum。

4. 「達到Quorum：」 如果收到的回應數(shù)量達到或超過Quorum，那么哨兵節(jié)點就會認為該節(jié)點進入客觀下線狀態(tài)。這表示集群中有足夠多的哨兵都認為該節(jié)點可能下線，進而觸發(fā)后續(xù)的主從切換流程。

5. 「執(zhí)行后續(xù)操作：」 一旦一個節(jié)點被認為客觀下線，哨兵節(jié)點將開始執(zhí)行故障轉移操作，選擇新的主節(jié)點并開始同步數(shù)據(jù)。這將最終導致一個新的主節(jié)點被選出，從而實現(xiàn)高可用性。

選舉Leader流程

Redis Sentinel（哨兵）是用于監(jiān)控和管理Redis主從復制以及自動故障切換的工具。當主節(jié)點失效時，哨兵會協(xié)調選擇一個從節(jié)點作為新的主節(jié)點，這涉及到選舉Leader的過程。詳細流程如下：

1. 「監(jiān)控主節(jié)點：」 哨兵持續(xù)監(jiān)控Redis主節(jié)點的狀態(tài)，包括主節(jié)點是否在線，主從復制是否正常，以及哨兵和其他節(jié)點的通信情況。

2. 「檢測主節(jié)點失效：」 當哨兵檢測到主節(jié)點失效（例如，無法響應PING命令），它會將主節(jié)點標記為“主觀下線”。

3. 「廣播主觀下線狀態(tài)：」 一旦主觀下線狀態(tài)被確認，哨兵會廣播該信息給其他哨兵和節(jié)點，告知主節(jié)點已經(jīng)“主觀下線”。

4. 「投票：」 當其他哨兵收到關于主觀下線狀態(tài)的廣播時，它們會進行投票來決定是否需要進行領導者選舉。

5. 「選舉Leader：」 如果多個哨兵都認為主節(jié)點失效，它們將進入領導者選舉過程。選舉過程使用了Raft算法的變體。

6. 「提議投票：」 在選舉過程中，哨兵會提議自己作為領導者，然后請求其他哨兵投票支持。

7. 「投票表決：」 哨兵在收到提議后會表決是否支持該提議。通常，哨兵會投票給具有最高配置版本號的提議者。

8. 「Quorum判斷：」 在選舉過程中，哨兵需要收集足夠數(shù)量的投票，達到Quorum（大多數(shù)）的支持才能選舉成功。

9. 「選出新領導者：」 如果某個哨兵獲得足夠多的投票，超過了Quorum，那么它將被選為新的領導者。

10. 「通知其他節(jié)點：」 新選出的Leader會向其他哨兵和節(jié)點廣播其成為領導者的消息，確保集群中的所有節(jié)點都知道領導者的變更。

11. 「故障切換：」 一旦新的Leader選舉完成，哨兵會協(xié)調進行故障切換，將一個從節(jié)點提升為新的主節(jié)點，使整個集群繼續(xù)正常運行。

12. 「恢復正常狀態(tài)：」 一旦故障切換完成，新的主節(jié)點將開始處理客戶端請求，集群會恢復到正常運行狀態(tài)。

需要注意的是，Redis Sentinel的選舉Leader過程受到Paxos算法和Raft算法等分布式一致性算法的影響，以保證在主節(jié)點失效時能夠選擇合適的節(jié)點作為新的主節(jié)點，從而保持數(shù)據(jù)的一致性和高可用性。

TIP

1. 如果哨兵集群只有 2 個實例，此時，一個哨兵要想成為 Leader，必須獲得 2 票，而不是 1 票。所以，如果有個哨兵掛掉了，那么，此時的集群是無法進行主從庫切換的。因此，通常我們至少會配置 3 個哨兵實例。

2. 要保證所有哨兵實例的配置是一致的，尤其是主觀下線的判斷值 down-after-milliseconds。