一.哨兵機制基本解讀

主庫發(fā)生故障了，如何不間斷的服務？

哨兵模式：有效的解決主從庫自動切換的關鍵機制

在Redis中如果從庫發(fā)生故障了，客戶端可以繼續(xù)向主庫和其他從庫發(fā)消息，進行相關操作。但是如果主庫故障了，直接影響到從庫的同步操作（從庫沒有相應主庫進行相關數據復制操作了）和沒有實例來支持客戶端進行寫操作。

把從庫切換成主庫，需要涉及三個問題：

1. 主庫真的掛了嗎？
2. 應該選擇哪一個從庫來切換成主庫？
3. 怎么把新主庫的信息通知給從庫和客戶端呢？

1.哨兵機制的基本流程

哨兵機制，在主從庫實例運行的時候，就在運行。哨兵機制主要的行為就是監(jiān)控。

1.1哨兵監(jiān)控

哨兵進程在運行過程中會周期性的給所有主從庫發(fā)送PING命令，檢測他們是否還在線運行。如果從庫沒有在規(guī)定時間內響應哨兵的PING命令，哨兵就會把它標記為“下線狀態(tài)”。同樣，如果主庫沒有在規(guī)定時間內響應哨兵的PING命令，哨兵也會把主庫標記為“下線狀態(tài)”，然后開始自動切換主庫的流程。

1.2自動切換主庫流程

1. 這個流程首先執(zhí)行的是哨兵的第二個任務：選主。主庫掛了之后，哨兵需要從眾多從庫中，按照一定規(guī)則選擇一個從庫實例，把它作為更新的主庫。這一步完成后，集群里就會有新的主庫了。
2. 然后執(zhí)行的是最后一個任務：通知。在執(zhí)行任務通知時，哨兵會把新主庫的信息發(fā)送給其他所有從庫，讓他們執(zhí)行replicaof命令，和新主庫建立好連接，并且進行數據復制。同時，哨兵會把新主庫連接信息給客戶端，讓他把新的請求發(fā)送到新主庫上。

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

• 在監(jiān)控任務中，哨兵需要決策主庫是否處于下線狀態(tài)
• 在選主任務中，哨兵也要決定選取那個從庫實例作為新主庫。

如何判斷主庫是否下線？

2.主庫是否下線判斷

主庫是否下線判斷分為兩種“主觀下線”和”客觀下線“。

2.1.主觀下線

主觀下線：

• 哨兵機制會給主從庫發(fā)送PING命令，檢測他自己和主從庫的網絡連接情況，用來判斷實例的狀態(tài)。
• 如果哨兵發(fā)現主從庫的響應時間超時了，就會給主從庫標記為“主觀下線”。

誤判：

• 但是會出現一種情況，哨兵誤判了，主從庫并沒有故障，主庫也并沒有下線，哨兵誤判他下線了。誤判一般發(fā)生在：集群網絡壓力大，網絡擁塞，或者主庫本身壓力較大的情況下。
• 一旦哨兵判斷主庫下線了，就需要進行選主，主從庫同步等一系列操作，就會增加額外的計算和通信開銷。
• 所以需要減少誤判。
• 怎么減少誤判呢？
• 引入多幾個哨兵進行協商判斷，也就是哨兵集群。

哨兵集群：

• 通常由多個實例組成的集群模式進行部署。
• 引入多個哨兵實例進行判斷，避免單個哨兵因為網絡不好造成的誤判主庫下線的情況。
• 多個哨兵網絡同時不穩(wěn)定的概率小，同時誤判的概率也小了。

2.2客觀下線

在判斷主庫是否下線時，不能由一個哨兵說了算，要大多數哨兵，都判斷主庫已經“主觀下線”，主庫才會標記為”客觀下線“，這個說法表明主庫下線已經成為了客觀事實，判斷原理就是：少數服從多數。

客觀下線：當有N個集群時，當有N/2+1個集群已經判斷主庫“主觀下線”，才能最終判斷主庫“客觀下線”。減少誤判帶來的主從庫切換開銷。（有幾個實例來作出主庫“主觀下線”的判斷才可以，由Redis管理員自信設定）。

3.主從切換機制：主庫下線了就要進行主從切換了

如何選定新主庫？

一般來說，哨兵選擇新主庫的過程可以稱為“篩選+打分”。就是在多個實例從庫中，按照一定的篩選條件，把不符合條件的從庫去掉。然后在按照一定的規(guī)則，給剩下的從庫逐個打分，將得分最高的從庫選為新主庫。

3.1篩選條件

不僅僅要判斷從庫當前的狀態(tài)，還要判斷他之前的網絡連接狀態(tài)。如果之前從庫跟主庫斷聯次數超過了閾值，那么有有理由詳細這個從庫的網絡連接狀態(tài)不是很好，可以把它篩選掉。雖然現在他在運行，但是萬一過一會斷掉了，就需要重新選主，所以需要判斷她之前的狀態(tài)。

具體怎么判斷呢？

使用配置項down-after-milliseconds*10。其中，down-after-milliseconds是我們認定是從庫斷聯的最大時間。如果在down-after-milliseconds毫秒內，主從節(jié)點都沒有網絡連接上，那么就認為從庫斷聯了。如果斷聯時間超過了10次就認為，這個從庫的網絡轉態(tài)不是很好，不適合做主庫。

3.2打分規(guī)則

可以分別按照三個規(guī)則進行打分：從庫優(yōu)先級、從庫復制進度、以及從庫ID號

只需要在某一輪得分最高，那么他就是新主庫,選主過程到此結束，要是沒有出現得分最高的，那么久進行下一輪。

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

用戶可以通過slave-priority配置項，給不同的從庫設置不同優(yōu)先級。比如，你有兩個從庫,它們的內存大

小不一樣，你可以手動給內存大的實例設置一個高優(yōu)先級。在選主時，哨兵會給優(yōu)先級高的從庫打高分，如果有一個從庫優(yōu)先級最高，那么它就是新主庫了。如果從庫的優(yōu)先級都一樣，那么哨兵開始第二輪打分。

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

如果選擇和舊主庫同步最接近的從庫作為主庫，新主庫上邊就會有最新的數據。

如何判斷從庫和主庫的同步進度呢？（復制進度）

主從庫同步的時有個命令傳播的過程，在這個過程中，主庫會用master-repl-offset記錄，當前的最新寫操作在repl-backlog-buffer的中位置，而從庫會用slave-repl-offset記錄復制的進度。

所以我們需要找到master-repl-offset，slave-repl-offset最接近的從庫。得分就高，就會被選為新主庫。如果slave-repl-offset相同，就會進行下一輪的打分。

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

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

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

3.3主從切換總結

首先哨兵機制會根據在線狀態(tài)，網絡狀態(tài)，過濾篩選掉一部分不符合要求的從庫。然后按照優(yōu)先級，復制進度，ID大小對從庫進行打分，得分最高的選為新主庫。

4.哨兵機制總結

主從集群數據同步，保證了數據的可靠性。主庫發(fā)生故障時，自動的主從切換是服務不間斷的關鍵支撐。

Redis的哨兵機制自動完成了以下三大功能，從而實現了主從庫的自動切換，可以降低Redis集群的運維開銷：

• 監(jiān)控主庫運行狀態(tài),并判斷主庫是否客觀下線;
• 在主庫客觀下線后,選取新主庫;
• 選出新主庫后，通知從庫和客戶端。

為了降低誤判率，在實際應用時，哨兵機制通常來用多實例的方式進行部署，多個哨兵實例通過“少數服從多數”的原則，來判斷主庫是否客觀下線。一般來說，我們可以部署三個哨兵，如果有兩個哨兵認定主庫“主觀下線”，就可以開始切換過程。當然，如果你希望進一步提升判斷準確率，也可以再適當增加哨兵個數,比如說使用五個哨兵。

哨兵集群中有實例掛了,怎么辦,會影響主庫狀態(tài)判斷和選主嗎?

簡單說結論:存在故障節(jié)點時，只要集群中大多數節(jié)點狀態(tài)正常，集群依舊可以對外提供服務

哨兵集群多數實例達成共識，判斷出主庫“客觀下線”后，由哪個實例來執(zhí)行主從切換呢?

哨兵集群判斷出主庫“主觀下線”后，會選出一個“哨兵領導者”，之后整個過程由它來完成主從切換。

哨兵在操作主從切換的過程中，客戶端能否正常地進行請求操作?

如果客戶端使用了讀寫分離，那么讀請求可以在從庫上正常執(zhí)行，不會受到影響。但是由于此時主庫已經掛了，而且哨兵還沒有選出新的主庫，所以在這期間寫請求會失敗，失敗持續(xù)的時間=哨兵切換主從的時間+客戶端感知到新主庫的時間.

如果不想讓業(yè)務感知到異常，客戶端只能把寫失敗的請求先緩存起來或寫入消息隊列中間件中，等哨兵切換完主從后，再把這些寫請求發(fā)給新的主庫，但這種場景只適合對寫入請求返回值不敏感的業(yè)務，而且還需要業(yè)務層做適配，另外主從切換時間過長，也會導致客戶端或消息隊列中間件緩存寫請求過多，切換完成之后重放這些請求的時間變長。

哨兵檢測主庫多久沒有響應就提升從庫為新的主庫，這個時間是可以配置的(down-after-milliseconds參數)。配置的時間越短，哨兵越敏感，哨兵集群認為主庫在短時間內連不上就會發(fā)起主從切換，這種配置很可能因為網絡擁塞但主庫正常而發(fā)生不必要的切換，當然，當主庫真正故障時，因為切換得及時，對業(yè)務的影響最小。如果配置的時間比較長，哨兵越保守，這種情況可以減少哨兵誤判的概率，但是主庫故障發(fā)生時,業(yè)務寫失敗的時間也會比較久，緩存寫請求數據量越多。

二.哨兵掛了

如果有哨兵實例在運行時發(fā)生了故障，主從庫還能正常切換嗎?

實際上，一旦多個實例組成了哨兵集群，即使有哨兵實例出現故障掛掉了，其他哨兵還能繼續(xù)協作完成主庫切換的工作，包括判定主庫是不是處于下線狀態(tài)，選擇新主庫，以及通知從庫和客戶端。

如果你部署過哨兵集群的話就會知道，在配置哨兵的信息時，我們只需要用到下面的這個配置項，設置主的IP和端口，并沒有配置其他哨兵的連接信息。

sentinel monitor <master-name> <ip> <redis-port> <quorum>

哨兵既然不知道彼此的地址，怎么組成哨兵集群呢？

1.基于pub/sub機制的哨兵集群的組成

哨兵能被互相發(fā)現的原因：Redis提供的pub/sub機制（發(fā)布/訂閱機制）

1.1哨兵之間互相被發(fā)現過程

哨兵只要跟主庫建立起了連接，就可以在主庫上發(fā)布信息，發(fā)布自己的連接信息（ip和端口號）。同時也可以從主庫上訂閱信息，獲取其它哨兵發(fā)布的連接信息。當多個哨兵在主庫上進行了發(fā)布和訂閱后，他們就互相知道彼此的ip地址和端口號。

除了哨兵實例，我們自己編寫的應用程序也可以通過Redis進行消息發(fā)布和訂閱。

Redis如何區(qū)分不同的應用程序？

Redis通過頻道的方式。對消息進行歸類管理，區(qū)分不同的應用消息。頻道其實就是消息類型，當消息類型相同時，就屬于一個頻道。只有訂閱了同一個頻道的應用才能通過發(fā)布的消息進行信息交換。

在主從集群中，主庫存在“__sentinel__:hello”的頻道，不同哨兵通過實現他來相互發(fā)現，實現互相通信。

1.2哨兵消息互通說明

例如：在下圖中，哨兵1把自己的IP (17216.19.3) 和端口26579) 發(fā)布到“_sentinel_:hello”頻道上，哨兵2和3訂閱了該頻道。那么此時，哨兵2和3就可以從這個頻道直接獲取哨兵1的IP地址和端口號。

然后，哨兵2、3可以和哨兵1建立網絡連接。通過這個方式，哨兵2和3也可以建立網絡連接，這樣一來，哨兵集群就形成了。它們相互間可以通過網絡連接進行通信，比如說對主庫有沒有下線這件事兒進行判斷和協商

哨兵除了需要彼此建立連接形成集群外還需要和從庫建立連接。因為在哨兵監(jiān)控任務中，哨兵需要對主從庫進行心跳判斷，而且在主從庫切換完成后，還需要通知從庫，讓他們和新主庫進行同步。

哨兵如何跟從庫簡歷連接？如何知道從庫的ip地址和端口呢？

1.3哨兵與從庫建立連接：INFO命令

當哨兵給主庫發(fā)送INFO命令時，主庫接收命令后，會將從庫列表返回給哨兵。哨兵接收從庫列表連接信息后，會和每個從庫建立連接，并且在這個連接上持續(xù)的對從庫進行監(jiān)控。

通過pub/sub機制，哨兵之間建立哨兵集群，又通過發(fā)送INFO命令，獲取從庫連接信息 ，哨兵與從庫建立連接，進行監(jiān)控。主從庫切換后，客戶端需要知道新主庫的連接信息，才能像新主庫發(fā)送信息。因此哨兵還需要完成將新主庫信息告訴客戶端的任務。

在實際使用哨兵時，我們有時會遇到這樣的問題:如何在客戶端通過監(jiān)控了解哨兵進行主從切換的過程呢?比如說，主從切換進行到哪一步了? 這其實就是要求，客戶端能夠獲取到哨兵集群在監(jiān)控、選主、切換這個過程中發(fā)生的各種事件.

1.4哨兵與客戶端間的信息同步

基于pub/sub機制的客戶端事件的通知

從本質上說，哨兵就是一個運行在特定模式下的Redis實例，只不過它并不完成服務請求操作，只是完成監(jiān)控、選主和通知的任務。所以，每個哨兵實例也提供pub/sub機制，客戶端可以從哨兵訂閱消息。哨兵提供的消息訂閱頻道有很多，不同頻道包含了主從庫切換過程中的不同關鍵事件

常用事件：

知道了這些頻道之后，就可以讓客戶端從哨兵這里訂閱消息了。具體的操作步驟是，客戶端讀取哨兵的配置文件后，可以獲得哨兵的地址和端口，和哨兵建立網絡連接。然后，可以在客戶端執(zhí)行訂閱命令，來獲取不同的事件消息。

舉個例子，你可以執(zhí)行如下命令，來訂閱“所有實例進入客觀下線狀態(tài)的事件”：

subscribe +odown

訂閱所有頻道

PSUBSCRIBE  *

當哨兵把新主庫選擇出來后，客戶端就會看到下面的switch-master事件。這個事件表示主庫已經切換了，新主庫的IP地址和端口信息已經有了。這個時候，客戶端就可以用這里面的新主庫地址和端口進行通信了。

switch-master <master name> <oldip><oldport> <newport>

通過事件通知，客戶端不僅僅可以在主從切換后得到新主庫的連接信息，還可以監(jiān)控得到主從庫切換過程中發(fā)生的各個重要事件。這樣客戶端就可以知道主從切換到哪一步了，有助于了解切換速度。

總結：有了pub/sub機制,哨兵可以和從庫之間，哨兵與哨兵之間，哨兵與客戶端之間建立起連接。主庫下線判斷，選主依據哨兵集群的監(jiān)控、選主和通知三個任務基本上可以正常工作了。

主從故障后，集群存在多個實例，怎么確定由哪個哨兵來進行實際的主從切換呢？

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

其實由哪個哨兵進行主從切換的過程，其實跟選主一樣也是一個“投票仲裁”的過程。

2.1從哨兵選主，主要過程開始說起

任何一個實例只要自身判斷主庫“主觀下線”后，就會給其他實例發(fā)送is-master-down-by-addr命令。接著，其他實例會根據自己和主庫的連接情況，做出Y或N的響應，Y相當于贊成票，N相當于反對票。

一個哨兵獲得了仲裁所需的贊成票數后，就可以標記主庫為“客觀下線”。這個所需的贊成票數是通過哨兵配置文件中的 quorum 配置項設定的。例如，現在有 5 個哨兵，quorum 配置的是 3，那么，一個哨兵需要 3 張贊成票，就可以標記主庫為“客觀下線”了。這 3 張贊成票包括哨兵自己的一張贊成票和另外兩個哨兵的贊成票。

2.2哨兵選出Leader過程：Leader選舉

此時，這個哨兵就可以再給其他哨兵發(fā)送命令，表明希望由自己來執(zhí)行主從切換，并讓所有其他哨兵進行投票。這個投票過程稱為“Leader 選舉”。因為最終執(zhí)行主從切換的哨兵稱為 Leader，投票過程就是確定 Leader。

在投票過程中，任何一個想成為 Leader 的哨兵，要滿足兩個條件：第一，拿到半數以上的贊成票；第二，拿到的票數同時還需要大于等于哨兵配置文件中的 quorum 值。以 3 個哨兵為例，假設此時的 quorum 設置為 2，那么，任何一個想成為 Leader 的哨兵只要拿到 2 張贊成票，就可以了。

具體通過下圖講解：

在 T1 時刻，S1 判斷主庫為“客觀下線”，它想成為 Leader，就先給自己投一張贊成票，然后分別向 S2 和 S3 發(fā)送命令，表示要成為 Leader。

在 T2 時刻，S3 判斷主庫為“客觀下線”，它也想成為 Leader，所以也先給自己投一張贊成票，再分別向 S1 和 S2 發(fā)送命令，表示要成為 Leader。

在 T3 時刻，S1 收到了 S3 的 Leader 投票請求。因為 S1 已經給自己投了一票 Y，所以它不能再給其他哨兵投贊成票了，所以 S1 回復 N 表示不同意。同時，S2 收到了 T2 時 S3 發(fā)送的 Leader 投票請求。因為 S2 之前沒有投過票，它會給第一個向它發(fā)送投票請求的哨兵回復 Y，給后續(xù)再發(fā)送投票請求的哨兵回復 N，所以，在 T3 時，S2 回復 S3，同意 S3 成為 Leader。

在 T4 時刻，S2 才收到 T1 時 S1 發(fā)送的投票命令。因為 S2 已經在 T3 時同意了 S3 的投票請求，此時，S2 給 S1 回復 N，表示不同意 S1 成為 Leader。發(fā)生這種情況，是因為 S3 和 S2 之間的網絡傳輸正常，而 S1 和 S2 之間的網絡傳輸可能正好擁塞了，導致投票請求傳輸慢了。

最后，在 T5 時刻，S1 得到的票數是來自它自己的一票 Y 和來自 S2 的一票 N。而 S3 除了自己的贊成票 Y 以外，還收到了來自 S2 的一票 Y。此時，S3 不僅獲得了半數以上的 Leader 贊成票，也達到預設的 quorum 值（quorum 為 2），所以它最終成為了 Leader。接著，S3 會開始執(zhí)行選主操作，而且在選定新主庫后，會給其他從庫和客戶端通知新主庫的信息。

如果 S3 沒有拿到 2 票 Y，那么這輪投票就不會產生 Leader。哨兵集群會等待一段時間（也就是哨兵故障轉移超時時間的 2 倍），再重新選舉。這是因為，哨兵集群能夠進行成功投票，很大程度上依賴于選舉命令的正常網絡傳播。如果網絡壓力較大或有短時堵塞，就可能導致沒有一個哨兵能拿到半數以上的贊成票。所以，等到網絡擁塞好轉之后，再進行投票選舉，成功的概率就會增加。

需要注意的是，如果哨兵集群只有 2 個實例，此時，一個哨兵要想成為 Leader，必須獲得 2 票，而不是 1 票。所以，如果有個哨兵掛掉了，那么，此時的集群是無法進行主從庫切換的。因此，通常我們至少會配置 3 個哨兵實例。這一點很重要，你在實際應用時可不能忽略了。

哨兵不會同時投票給自己的原因？

要發(fā)生S1、S2和S3同時同自己投票的情況，這需要這三個哨兵基本同時判定了主庫客觀下線。但是，不同哨兵的網絡連接、系統壓力不完全一樣，接收到下線協商消息的時間也可能不同，所以，它們同時做出主庫客觀下線判定的概率較小，一般都有個先后關系。文章中的例子，就是S1、S3先判定，S2一直沒有判定。

哨兵對主從庫進行的在線狀態(tài)檢查等操作，是屬于一種時間事件，用一個定時器來完成，一般來說每100ms執(zhí)行一次這些事件。每個哨兵的定時器執(zhí)行周期都會加上一個小小的隨機時間偏移，目的是讓每個哨兵執(zhí)行上述操作的時間能稍微錯開些，也是為了避免它們都同時判定主庫下線，同時選舉Leader。

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

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

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

哨兵實例是不是越多越好？

• 并不是，我們也看到了，哨兵在判定“主觀下線”和選舉“哨兵領導者”時，都需要和其他節(jié)點進行通信，交換信息，哨兵實例越多，通信的次數也就越多，而且部署多個哨兵時，會分布在不同機器上，節(jié)點越多帶來的機器故障風險也會越大，這些問題都會影響到哨兵的通信和選舉，出問題時也就意味著選舉時間會變長，切換主從的時間變久。
• 哨兵實例越多，誤判率會越低，但是在判定主庫下線和選舉Leader時，實例需要拿到的贊成票數也越多，等待所有哨兵投完票的時間可能也會相應增加，主從庫切換的時間也會變長，客戶端容易堆積較多的請求操作，可能會導致客戶端請求溢出，從而造成請求丟失。如果業(yè)務層對Redis的操作有響應時間要求，就可能會因為新主庫一直沒有選定,新操作無法執(zhí)行而發(fā)生超時報警。
• 調大down-after-milliseconds后，可能會導致這樣的情況:主庫實際已經發(fā)生故障了，但是哨兵過了很長時間才判斷出來,這就會影響到Redis對業(yè)務的可用性。

調大down-after-milliseconds值，對減少誤判是不是有好處？

是有好處的，適當調大down-after-milliseconds值，當哨兵與主庫之間網絡存在短時波動時，可以降低誤判的概率。但是調大down-after-milliseconds值也意味著主從切換的時間會變長，對業(yè)務的影響時間越久，我們需要根據實際場景進行權衡，設置合理的閾值。

3.總結：哨兵關鍵機制（哨兵聯系主從客哨兵，Leader選主）

我們在解決一個系統問題的時候，會引入一個新機制，或者設計一層新功能，哨兵主要內容：為了實現主從切換，我們引入了哨兵；為了避免單個哨兵故障后無法進行主從切換，以及為了減少誤判率，又引入了哨兵集群；哨兵集群又需要有一些機制來支撐它的正常運行。

3.1哨兵集群的這些關鍵機制

• 基于 pub/sub 機制的哨兵集群組成過程；
• 基于 INFO 命令的從庫列表，這可以幫助哨兵和從庫建立連接；
• 基于哨兵自身的 pub/sub 功能，這實現了客戶端和哨兵之間的事件通知。

對于主從切換，當然不是哪個哨兵想執(zhí)行就可以執(zhí)行的，否則就亂套了。所以，這就需要哨兵集群在判斷了主庫“客觀下線”后，經過投票仲裁，選舉一個 Leader 出來，由它負責實際的主從切換，即由它來完成新主庫的選擇以及通知從庫與客戶端。

最后，我想再給你分享一個經驗：要保證所有哨兵實例的配置是一致的，尤其是主觀下線的判斷值 down-after-milliseconds。這個值在不同的哨兵實例上配置不一致，導致哨兵集群一直沒有對有故障的主庫形成共識，也就沒有及時切換主庫，最終的結果就是集群服務不穩(wěn)定。所以，你一定不要忽略這條看似簡單的經驗。

三.哨兵全部總結

1.哨兵怎么跟主庫連接

哨兵與主庫直接相關聯，手動設置，可以設置多個哨兵

2.哨兵怎么給從庫發(fā)消息

哨兵給主庫發(fā)送info命令，主庫返回從庫的slave集合，與從庫建立連接，把新主庫的信息發(fā)送給從庫

3.哨兵怎么跟客戶端聯系

client訂閱Sentinel的某一個頻道，該頻道里有誰是master的信息，讀取哨兵的配置文件，獲取ip地址和端口號，與哨兵建立連接，連接之后訂閱信息，獲取主庫信息，并與主庫建立連接

以上為個人經驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論