一.哨兵機(jī)制基本解讀

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

哨兵模式：有效的解決主從庫(kù)自動(dòng)切換的關(guān)鍵機(jī)制

在Redis中如果從庫(kù)發(fā)生故障了，客戶端可以繼續(xù)向主庫(kù)和其他從庫(kù)發(fā)消息，進(jìn)行相關(guān)操作。但是如果主庫(kù)故障了，直接影響到從庫(kù)的同步操作（從庫(kù)沒(méi)有相應(yīng)主庫(kù)進(jìn)行相關(guān)數(shù)據(jù)復(fù)制操作了）和沒(méi)有實(shí)例來(lái)支持客戶端進(jìn)行寫(xiě)操作。

把從庫(kù)切換成主庫(kù)，需要涉及三個(gè)問(wèn)題：

1. 主庫(kù)真的掛了嗎？
2. 應(yīng)該選擇哪一個(gè)從庫(kù)來(lái)切換成主庫(kù)？
3. 怎么把新主庫(kù)的信息通知給從庫(kù)和客戶端呢？

1.哨兵機(jī)制的基本流程

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

1.1哨兵監(jiān)控

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

1.2自動(dòng)切換主庫(kù)流程

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

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

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

如何判斷主庫(kù)是否下線？

2.主庫(kù)是否下線判斷

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

2.1.主觀下線

主觀下線：

• 哨兵機(jī)制會(huì)給主從庫(kù)發(fā)送PING命令，檢測(cè)他自己和主從庫(kù)的網(wǎng)絡(luò)連接情況，用來(lái)判斷實(shí)例的狀態(tài)。
• 如果哨兵發(fā)現(xiàn)主從庫(kù)的響應(yīng)時(shí)間超時(shí)了，就會(huì)給主從庫(kù)標(biāo)記為“主觀下線”。

誤判：

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

哨兵集群：

• 通常由多個(gè)實(shí)例組成的集群模式進(jìn)行部署。
• 引入多個(gè)哨兵實(shí)例進(jìn)行判斷，避免單個(gè)哨兵因?yàn)榫W(wǎng)絡(luò)不好造成的誤判主庫(kù)下線的情況。
• 多個(gè)哨兵網(wǎng)絡(luò)同時(shí)不穩(wěn)定的概率小，同時(shí)誤判的概率也小了。

2.2客觀下線

在判斷主庫(kù)是否下線時(shí)，不能由一個(gè)哨兵說(shuō)了算，要大多數(shù)哨兵，都判斷主庫(kù)已經(jīng)“主觀下線”，主庫(kù)才會(huì)標(biāo)記為”客觀下線“，這個(gè)說(shuō)法表明主庫(kù)下線已經(jīng)成為了客觀事實(shí)，判斷原理就是：少數(shù)服從多數(shù)。

客觀下線：當(dāng)有N個(gè)集群時(shí)，當(dāng)有N/2+1個(gè)集群已經(jīng)判斷主庫(kù)“主觀下線”，才能最終判斷主庫(kù)“客觀下線”。減少誤判帶來(lái)的主從庫(kù)切換開(kāi)銷。（有幾個(gè)實(shí)例來(lái)作出主庫(kù)“主觀下線”的判斷才可以，由Redis管理員自信設(shè)定）。

3.主從切換機(jī)制：主庫(kù)下線了就要進(jìn)行主從切換了

如何選定新主庫(kù)？

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

3.1篩選條件

不僅僅要判斷從庫(kù)當(dāng)前的狀態(tài)，還要判斷他之前的網(wǎng)絡(luò)連接狀態(tài)。如果之前從庫(kù)跟主庫(kù)斷聯(lián)次數(shù)超過(guò)了閾值，那么有有理由詳細(xì)這個(gè)從庫(kù)的網(wǎng)絡(luò)連接狀態(tài)不是很好，可以把它篩選掉。雖然現(xiàn)在他在運(yùn)行，但是萬(wàn)一過(guò)一會(huì)斷掉了，就需要重新選主，所以需要判斷她之前的狀態(tài)。

具體怎么判斷呢？

使用配置項(xiàng)down-after-milliseconds*10。其中，down-after-milliseconds是我們認(rèn)定是從庫(kù)斷聯(lián)的最大時(shí)間。如果在down-after-milliseconds毫秒內(nèi)，主從節(jié)點(diǎn)都沒(méi)有網(wǎng)絡(luò)連接上，那么就認(rèn)為從庫(kù)斷聯(lián)了。如果斷聯(lián)時(shí)間超過(guò)了10次就認(rèn)為，這個(gè)從庫(kù)的網(wǎng)絡(luò)轉(zhuǎn)態(tài)不是很好，不適合做主庫(kù)。

3.2打分規(guī)則

可以分別按照三個(gè)規(guī)則進(jìn)行打分：從庫(kù)優(yōu)先級(jí)、從庫(kù)復(fù)制進(jìn)度、以及從庫(kù)ID號(hào)

只需要在某一輪得分最高，那么他就是新主庫(kù),選主過(guò)程到此結(jié)束，要是沒(méi)有出現(xiàn)得分最高的，那么久進(jìn)行下一輪。

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

用戶可以通過(guò)slave-priority配置項(xiàng)，給不同的從庫(kù)設(shè)置不同優(yōu)先級(jí)。比如，你有兩個(gè)從庫(kù),它們的內(nèi)存大

小不一樣，你可以手動(dòng)給內(nèi)存大的實(shí)例設(shè)置一個(gè)高優(yōu)先級(jí)。在選主時(shí)，哨兵會(huì)給優(yōu)先級(jí)高的從庫(kù)打高分，如果有一個(gè)從庫(kù)優(yōu)先級(jí)最高，那么它就是新主庫(kù)了。如果從庫(kù)的優(yōu)先級(jí)都一樣，那么哨兵開(kāi)始第二輪打分。

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

如果選擇和舊主庫(kù)同步最接近的從庫(kù)作為主庫(kù)，新主庫(kù)上邊就會(huì)有最新的數(shù)據(jù)。

如何判斷從庫(kù)和主庫(kù)的同步進(jìn)度呢？（復(fù)制進(jìn)度）

主從庫(kù)同步的時(shí)有個(gè)命令傳播的過(guò)程，在這個(gè)過(guò)程中，主庫(kù)會(huì)用master-repl-offset記錄，當(dāng)前的最新寫(xiě)操作在repl-backlog-buffer的中位置，而從庫(kù)會(huì)用slave-repl-offset記錄復(fù)制的進(jìn)度。

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

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

第三輪：ID號(hào)小的從庫(kù)得分高

每個(gè)實(shí)例都會(huì)有一個(gè)id，這個(gè)ID類似于從庫(kù)的編號(hào)。Redis選主時(shí)，有一個(gè)規(guī)定：在優(yōu)先級(jí)和復(fù)制進(jìn)度相同的情況下，ID越小的得分越高。

3.3主從切換總結(jié)

首先哨兵機(jī)制會(huì)根據(jù)在線狀態(tài)，網(wǎng)絡(luò)狀態(tài)，過(guò)濾篩選掉一部分不符合要求的從庫(kù)。然后按照優(yōu)先級(jí)，復(fù)制進(jìn)度，ID大小對(duì)從庫(kù)進(jìn)行打分，得分最高的選為新主庫(kù)。

4.哨兵機(jī)制總結(jié)

主從集群數(shù)據(jù)同步，保證了數(shù)據(jù)的可靠性。主庫(kù)發(fā)生故障時(shí)，自動(dòng)的主從切換是服務(wù)不間斷的關(guān)鍵支撐。

Redis的哨兵機(jī)制自動(dòng)完成了以下三大功能，從而實(shí)現(xiàn)了主從庫(kù)的自動(dòng)切換，可以降低Redis集群的運(yùn)維開(kāi)銷：

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

為了降低誤判率，在實(shí)際應(yīng)用時(shí)，哨兵機(jī)制通常來(lái)用多實(shí)例的方式進(jìn)行部署，多個(gè)哨兵實(shí)例通過(guò)“少數(shù)服從多數(shù)”的原則，來(lái)判斷主庫(kù)是否客觀下線。一般來(lái)說(shuō)，我們可以部署三個(gè)哨兵，如果有兩個(gè)哨兵認(rèn)定主庫(kù)“主觀下線”，就可以開(kāi)始切換過(guò)程。當(dāng)然，如果你希望進(jìn)一步提升判斷準(zhǔn)確率，也可以再適當(dāng)增加哨兵個(gè)數(shù),比如說(shuō)使用五個(gè)哨兵。

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

簡(jiǎn)單說(shuō)結(jié)論:存在故障節(jié)點(diǎn)時(shí)，只要集群中大多數(shù)節(jié)點(diǎn)狀態(tài)正常，集群依舊可以對(duì)外提供服務(wù)

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

哨兵集群判斷出主庫(kù)“主觀下線”后，會(huì)選出一個(gè)“哨兵領(lǐng)導(dǎo)者”，之后整個(gè)過(guò)程由它來(lái)完成主從切換。

哨兵在操作主從切換的過(guò)程中，客戶端能否正常地進(jìn)行請(qǐng)求操作?

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

如果不想讓業(yè)務(wù)感知到異常，客戶端只能把寫(xiě)失敗的請(qǐng)求先緩存起來(lái)或?qū)懭胂㈥?duì)列中間件中，等哨兵切換完主從后，再把這些寫(xiě)請(qǐng)求發(fā)給新的主庫(kù)，但這種場(chǎng)景只適合對(duì)寫(xiě)入請(qǐng)求返回值不敏感的業(yè)務(wù)，而且還需要業(yè)務(wù)層做適配，另外主從切換時(shí)間過(guò)長(zhǎng)，也會(huì)導(dǎo)致客戶端或消息隊(duì)列中間件緩存寫(xiě)請(qǐng)求過(guò)多，切換完成之后重放這些請(qǐng)求的時(shí)間變長(zhǎng)。

哨兵檢測(cè)主庫(kù)多久沒(méi)有響應(yīng)就提升從庫(kù)為新的主庫(kù)，這個(gè)時(shí)間是可以配置的(down-after-milliseconds參數(shù))。配置的時(shí)間越短，哨兵越敏感，哨兵集群認(rèn)為主庫(kù)在短時(shí)間內(nèi)連不上就會(huì)發(fā)起主從切換，這種配置很可能因?yàn)榫W(wǎng)絡(luò)擁塞但主庫(kù)正常而發(fā)生不必要的切換，當(dāng)然，當(dāng)主庫(kù)真正故障時(shí)，因?yàn)榍袚Q得及時(shí)，對(duì)業(yè)務(wù)的影響最小。如果配置的時(shí)間比較長(zhǎng)，哨兵越保守，這種情況可以減少哨兵誤判的概率，但是主庫(kù)故障發(fā)生時(shí),業(yè)務(wù)寫(xiě)失敗的時(shí)間也會(huì)比較久，緩存寫(xiě)請(qǐng)求數(shù)據(jù)量越多。

二.哨兵掛了

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

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

如果你部署過(guò)哨兵集群的話就會(huì)知道，在配置哨兵的信息時(shí)，我們只需要用到下面的這個(gè)配置項(xiàng)，設(shè)置主的IP和端口，并沒(méi)有配置其他哨兵的連接信息。

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

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

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

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

1.1哨兵之間互相被發(fā)現(xiàn)過(guò)程

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

除了哨兵實(shí)例，我們自己編寫(xiě)的應(yīng)用程序也可以通過(guò)Redis進(jìn)行消息發(fā)布和訂閱。

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

Redis通過(guò)頻道的方式。對(duì)消息進(jìn)行歸類管理，區(qū)分不同的應(yīng)用消息。頻道其實(shí)就是消息類型，當(dāng)消息類型相同時(shí)，就屬于一個(gè)頻道。只有訂閱了同一個(gè)頻道的應(yīng)用才能通過(guò)發(fā)布的消息進(jìn)行信息交換。

在主從集群中，主庫(kù)存在“__sentinel__:hello”的頻道，不同哨兵通過(guò)實(shí)現(xiàn)他來(lái)相互發(fā)現(xiàn)，實(shí)現(xiàn)互相通信。

1.2哨兵消息互通說(shuō)明

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

然后，哨兵2、3可以和哨兵1建立網(wǎng)絡(luò)連接。通過(guò)這個(gè)方式，哨兵2和3也可以建立網(wǎng)絡(luò)連接，這樣一來(lái)，哨兵集群就形成了。它們相互間可以通過(guò)網(wǎng)絡(luò)連接進(jìn)行通信，比如說(shuō)對(duì)主庫(kù)有沒(méi)有下線這件事兒進(jìn)行判斷和協(xié)商

哨兵除了需要彼此建立連接形成集群外還需要和從庫(kù)建立連接。因?yàn)樵谏诒O(jiān)控任務(wù)中，哨兵需要對(duì)主從庫(kù)進(jìn)行心跳判斷，而且在主從庫(kù)切換完成后，還需要通知從庫(kù)，讓他們和新主庫(kù)進(jìn)行同步。

哨兵如何跟從庫(kù)簡(jiǎn)歷連接？如何知道從庫(kù)的ip地址和端口呢？

1.3哨兵與從庫(kù)建立連接：INFO命令

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

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

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

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

基于pub/sub機(jī)制的客戶端事件的通知

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

常用事件：

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

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

subscribe +odown

訂閱所有頻道

PSUBSCRIBE  *

當(dāng)哨兵把新主庫(kù)選擇出來(lái)后，客戶端就會(huì)看到下面的switch-master事件。這個(gè)事件表示主庫(kù)已經(jīng)切換了，新主庫(kù)的IP地址和端口信息已經(jīng)有了。這個(gè)時(shí)候，客戶端就可以用這里面的新主庫(kù)地址和端口進(jìn)行通信了。

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

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

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

主從故障后，集群存在多個(gè)實(shí)例，怎么確定由哪個(gè)哨兵來(lái)進(jìn)行實(shí)際的主從切換呢？

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

其實(shí)由哪個(gè)哨兵進(jìn)行主從切換的過(guò)程，其實(shí)跟選主一樣也是一個(gè)“投票仲裁”的過(guò)程。

2.1從哨兵選主，主要過(guò)程開(kāi)始說(shuō)起

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

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

2.2哨兵選出Leader過(guò)程：Leader選舉

此時(shí)，這個(gè)哨兵就可以再給其他哨兵發(fā)送命令，表明希望由自己來(lái)執(zhí)行主從切換，并讓所有其他哨兵進(jìn)行投票。這個(gè)投票過(guò)程稱為“Leader 選舉”。因?yàn)樽罱K執(zhí)行主從切換的哨兵稱為 Leader，投票過(guò)程就是確定 Leader。

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

具體通過(guò)下圖講解：

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

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

在 T3 時(shí)刻，S1 收到了 S3 的 Leader 投票請(qǐng)求。因?yàn)?S1 已經(jīng)給自己投了一票 Y，所以它不能再給其他哨兵投贊成票了，所以 S1 回復(fù) N 表示不同意。同時(shí)，S2 收到了 T2 時(shí) S3 發(fā)送的 Leader 投票請(qǐng)求。因?yàn)?S2 之前沒(méi)有投過(guò)票，它會(huì)給第一個(gè)向它發(fā)送投票請(qǐng)求的哨兵回復(fù) Y，給后續(xù)再發(fā)送投票請(qǐng)求的哨兵回復(fù) N，所以，在 T3 時(shí)，S2 回復(fù) S3，同意 S3 成為 Leader。

在 T4 時(shí)刻，S2 才收到 T1 時(shí) S1 發(fā)送的投票命令。因?yàn)?S2 已經(jīng)在 T3 時(shí)同意了 S3 的投票請(qǐng)求，此時(shí)，S2 給 S1 回復(fù) N，表示不同意 S1 成為 Leader。發(fā)生這種情況，是因?yàn)?S3 和 S2 之間的網(wǎng)絡(luò)傳輸正常，而 S1 和 S2 之間的網(wǎng)絡(luò)傳輸可能正好擁塞了，導(dǎo)致投票請(qǐng)求傳輸慢了。

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

如果 S3 沒(méi)有拿到 2 票 Y，那么這輪投票就不會(huì)產(chǎn)生 Leader。哨兵集群會(huì)等待一段時(shí)間（也就是哨兵故障轉(zhuǎn)移超時(shí)時(shí)間的 2 倍），再重新選舉。這是因?yàn)?，哨兵集群能夠進(jìn)行成功投票，很大程度上依賴于選舉命令的正常網(wǎng)絡(luò)傳播。如果網(wǎng)絡(luò)壓力較大或有短時(shí)堵塞，就可能導(dǎo)致沒(méi)有一個(gè)哨兵能拿到半數(shù)以上的贊成票。所以，等到網(wǎng)絡(luò)擁塞好轉(zhuǎn)之后，再進(jìn)行投票選舉，成功的概率就會(huì)增加。

需要注意的是，如果哨兵集群只有 2 個(gè)實(shí)例，此時(shí)，一個(gè)哨兵要想成為 Leader，必須獲得 2 票，而不是 1 票。所以，如果有個(gè)哨兵掛掉了，那么，此時(shí)的集群是無(wú)法進(jìn)行主從庫(kù)切換的。因此，通常我們至少會(huì)配置 3 個(gè)哨兵實(shí)例。這一點(diǎn)很重要，你在實(shí)際應(yīng)用時(shí)可不能忽略了。

哨兵不會(huì)同時(shí)投票給自己的原因？

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

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

Redis 1主4從，5個(gè)哨兵，哨兵配置quorum為2，如果3個(gè)哨兵故障，當(dāng)主庫(kù)宕機(jī)時(shí)，哨兵能否判斷主庫(kù)“客觀下線”？能否自動(dòng)切換？

1、哨兵集群可以判定主庫(kù)“主觀下線”。由于quorum=2，所以當(dāng)一個(gè)哨兵判斷主庫(kù)“主觀下線”后，詢問(wèn)另外一個(gè)哨兵后也會(huì)得到同樣的結(jié)果，2個(gè)哨兵都判定“主觀下線”，達(dá)到了quorum的值，因此，哨兵集群可以判定主庫(kù)為“客觀下線”。

2、但哨兵不能完成主從切換。哨兵標(biāo)記主庫(kù)“客觀下線后”，在選舉“哨兵領(lǐng)導(dǎo)者”時(shí)，一個(gè)哨兵必須拿到超過(guò)多數(shù)的選票(5/2+1=3票)。但目前只有2個(gè)哨兵活著，無(wú)論怎么投票，一個(gè)哨兵最多只能拿到2票，永遠(yuǎn)無(wú)法達(dá)到多數(shù)選票的結(jié)果。

哨兵實(shí)例是不是越多越好？

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

調(diào)大down-after-milliseconds值，對(duì)減少誤判是不是有好處？

是有好處的，適當(dāng)調(diào)大down-after-milliseconds值，當(dāng)哨兵與主庫(kù)之間網(wǎng)絡(luò)存在短時(shí)波動(dòng)時(shí)，可以降低誤判的概率。但是調(diào)大down-after-milliseconds值也意味著主從切換的時(shí)間會(huì)變長(zhǎng)，對(duì)業(yè)務(wù)的影響時(shí)間越久，我們需要根據(jù)實(shí)際場(chǎng)景進(jìn)行權(quán)衡，設(shè)置合理的閾值。

3.總結(jié)：哨兵關(guān)鍵機(jī)制（哨兵聯(lián)系主從客哨兵，Leader選主）

我們?cè)诮鉀Q一個(gè)系統(tǒng)問(wèn)題的時(shí)候，會(huì)引入一個(gè)新機(jī)制，或者設(shè)計(jì)一層新功能，哨兵主要內(nèi)容：為了實(shí)現(xiàn)主從切換，我們引入了哨兵；為了避免單個(gè)哨兵故障后無(wú)法進(jìn)行主從切換，以及為了減少誤判率，又引入了哨兵集群；哨兵集群又需要有一些機(jī)制來(lái)支撐它的正常運(yùn)行。

3.1哨兵集群的這些關(guān)鍵機(jī)制

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

對(duì)于主從切換，當(dāng)然不是哪個(gè)哨兵想執(zhí)行就可以執(zhí)行的，否則就亂套了。所以，這就需要哨兵集群在判斷了主庫(kù)“客觀下線”后，經(jīng)過(guò)投票仲裁，選舉一個(gè) Leader 出來(lái)，由它負(fù)責(zé)實(shí)際的主從切換，即由它來(lái)完成新主庫(kù)的選擇以及通知從庫(kù)與客戶端。

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

三.哨兵全部總結(jié)

1.哨兵怎么跟主庫(kù)連接

哨兵與主庫(kù)直接相關(guān)聯(lián)，手動(dòng)設(shè)置，可以設(shè)置多個(gè)哨兵

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

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

3.哨兵怎么跟客戶端聯(lián)系

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

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。

最新評(píng)論