哨兵模式介紹

在深入理解Redis主從架構(gòu)中Redis 的主從架構(gòu)中，由于主從模式是讀寫分離的，如果主節(jié)點(diǎn)（master）掛了，那么將沒(méi)有主節(jié)點(diǎn)來(lái)服務(wù)客戶端的寫操作請(qǐng)求，也沒(méi)有主節(jié)點(diǎn)給從節(jié)點(diǎn)（slave）進(jìn)行數(shù)據(jù)同步了。

在實(shí)際生產(chǎn)環(huán)境中，服務(wù)器難免會(huì)遇到一些突發(fā)狀況：服務(wù)器宕機(jī)，停電，硬件損壞等等，一旦發(fā)生，后果不堪設(shè)想。 Redis 在 2.8 版本以后提供的哨兵（Sentinel）機(jī)制，它的作用是實(shí)現(xiàn)主從節(jié)點(diǎn)故障轉(zhuǎn)移。它會(huì)監(jiān)測(cè)主節(jié)點(diǎn)是否存活，如果發(fā)現(xiàn)主節(jié)點(diǎn)掛了，它就會(huì)選舉一個(gè)從節(jié)點(diǎn)切換為主節(jié)點(diǎn)，并且把新主節(jié)點(diǎn)的相關(guān)信息通知給從節(jié)點(diǎn)和客戶端。

?

哨兵的能力包含如下幾點(diǎn)：

• 監(jiān)控：?持續(xù)監(jiān)控 master 、slave 是否健康，是否處于預(yù)期工作狀態(tài)。

• 主從動(dòng)態(tài)切換：?當(dāng) Master 運(yùn)行故障，哨兵啟動(dòng)自動(dòng)故障恢復(fù)流程：從 slave 中選擇一臺(tái)作為新 master。

• 通知機(jī)制：?競(jìng)選出新的master之后，通知客戶端與新 master 建立連接；slave 從新的 master 中 replicaof，保障主從數(shù)據(jù)的一致性。

哨兵集群原理

監(jiān)控能力

哨模式啟用的時(shí)候，會(huì)啟動(dòng)Sentinel的進(jìn)程。sentinel進(jìn)程會(huì)向所有的master?和?slave?以及其他sentinel進(jìn)程 發(fā)送心跳包（1s一次），看看是否正常返回響應(yīng)。

• 如果slave 沒(méi)有在規(guī)定的時(shí)間內(nèi)響應(yīng)?sentinel?的?PING?命令 ，?sentinel?會(huì)認(rèn)為該實(shí)例已經(jīng)掛了，將它tag為：下線狀態(tài)；

• 同理，如果master 沒(méi)有在規(guī)定時(shí)間響應(yīng)?sentinel?的?PING?命令，也會(huì)被判定為 offline 狀態(tài)，只是會(huì)多做一步 自動(dòng)切換 master 的流程。

PING 命令的回復(fù)有兩種情況：

• 有效回復(fù)：返回 +PONG、-LOADING、-MASTERDOWN 任何一種；

• 無(wú)效回復(fù)：有效回復(fù)之外的回復(fù)，或者指定時(shí)間內(nèi)返回任何回復(fù)。

但是可能存在一些誤判的情況，比如說(shuō)網(wǎng)絡(luò)擁塞、master實(shí)例假死、請(qǐng)求延遲，導(dǎo)致實(shí)例在某個(gè)短暫時(shí)間段不可用，后續(xù)又快速恢復(fù)了。
如果這時(shí)候被我們主動(dòng)下線了，其實(shí)整個(gè)系統(tǒng)的可用性反而遭到了退化。而且 誤判之后的一系列操作，master競(jìng)選、消息通知，slave 與新 master 同步數(shù)據(jù)，都會(huì)消耗大量資源。所以，誤判要不得啊。
為了保證判斷的可靠性，我們對(duì)下線的標(biāo)識(shí)做了區(qū)分：一種是 主觀下線，一種是客觀下線。

• 主觀下線：?哨兵利用?PING?命令來(lái)監(jiān)測(cè)?master、?slave?實(shí)例節(jié)點(diǎn)的狀態(tài)。如果是無(wú)效回復(fù)，哨兵就把這個(gè)實(shí)例節(jié)點(diǎn)標(biāo)記為?主觀下線?。如果是slave，一般是有多從概念，直接下線即可，但如果是master，就需要小心了。需要多個(gè)sentinel進(jìn)投票裁決。哨兵機(jī)制采用多個(gè)實(shí)例組成sentinel集群模式進(jìn)行部署，即哨兵集群。多個(gè)哨兵實(shí)例一起來(lái)判斷，就可以避免單個(gè)哨兵因?yàn)樽陨砭W(wǎng)絡(luò)狀況不好，而誤判主庫(kù)下線的情況。

• 客觀下線：?master?是否要下線不是單個(gè)sentinel能夠決定的，上面說(shuō)了我們會(huì)有個(gè)sentinel集群，大家一起投票，超過(guò)一半的sentinel?都判斷了主觀下線，這時(shí)候我們就把?master?標(biāo)記為?客觀下線，認(rèn)為它是真的不行了。
  當(dāng) master 被判定為 客觀下線 后，就算正式?jīng)]有master了，當(dāng)務(wù)之急就是趕緊競(jìng)選出一個(gè)新的master。

• 總結(jié)：?主觀下線表示一個(gè)哨兵認(rèn)為某個(gè)節(jié)點(diǎn)不可用，客觀下線表示足夠多的哨兵對(duì)某個(gè)節(jié)點(diǎn)的主觀下線達(dá)成一致。只有在客觀下線時(shí)，哨兵才會(huì)認(rèn)定一個(gè)節(jié)點(diǎn)真正下線。

這里的「一定數(shù)量」是一個(gè)法定數(shù)量（Quorum），是由哨兵監(jiān)控配置決定的，解釋一下該配置：

#?sentinel?monitor?<master-name>?<master-host>?<master-port>?<quorum>
#?舉例如下：
sentinel?monitor?mymaster?127.0.0.1?6379?2

這條配置項(xiàng)用于告知哨兵需要監(jiān)聽(tīng)的主節(jié)點(diǎn)：

• sentinel monitor：代表監(jiān)控。

• mymaster：代表主節(jié)點(diǎn)的名稱，可以自定義。

• 127.0.0.1：代表監(jiān)控的主節(jié)點(diǎn) ip，6379 代表端口。

• 2：法定數(shù)量，代表只有兩個(gè)或兩個(gè)以上的哨兵認(rèn)為主節(jié)點(diǎn)不可用的時(shí)候，才會(huì)把 master 設(shè)置為客觀下線狀態(tài)，然后進(jìn)行 failover 操作。

客觀下線 的標(biāo)準(zhǔn)就是，當(dāng)有 N 個(gè)哨兵實(shí)例時(shí)，要有 N/2 + 1 個(gè)實(shí)例判斷 master 為 主觀下線 ，才能最終判定 master 為 客觀下線 ，其實(shí)就是過(guò)半機(jī)制。

主從動(dòng)態(tài)切換

當(dāng)master下線后，sentinel如何從多個(gè)slave中選舉出一個(gè)新的master？這就需要通過(guò)?篩選?+?評(píng)估?方式進(jìn)行選舉了。

篩選

• 過(guò)濾掉不健康的（下線或者斷線），沒(méi)有回復(fù)哨兵ping響應(yīng)的從節(jié)點(diǎn)。

• 過(guò)濾網(wǎng)路不好的節(jié)點(diǎn)：通過(guò)?down-after-milliseconds評(píng)估以往斷連情況，如果一定周期內(nèi)（如24h）從庫(kù)和主庫(kù)經(jīng)常斷連，而且超出了一定的閾值（如 10 次），則該slave不予考慮。

評(píng)估

篩選掉不健康的實(shí)例之后，我們就可以對(duì)于剩下健康的實(shí)例按順序進(jìn)行綜合評(píng)估了。

• slave 優(yōu)先級(jí)，通過(guò)?slave-priority?配置項(xiàng)（redis.conf），可以給不同的從庫(kù)設(shè)置不同優(yōu)先級(jí)，優(yōu)先級(jí)高的優(yōu)先成為master。

• 選擇數(shù)據(jù)偏移量差距最小的，即slave_repl_offset與?master_repl_offset進(jìn)度差距，其實(shí)就是比較 slave 與 原master 復(fù)制進(jìn)度差距。

• slave?runID，在優(yōu)先級(jí)和復(fù)制進(jìn)度都相同的情況下，選用runID最小的，runID越小說(shuō)明創(chuàng)建時(shí)間越早，優(yōu)先選為master。先來(lái)后到原則。

等這幾個(gè)條件都評(píng)估完，我們就會(huì)選擇出最適合slave，把他推舉為新的master。

信息通知

等推選出最新的master之后，后續(xù)所有的寫操作都會(huì)進(jìn)入這個(gè)master中。所以需要盡快通知到所有的slave，讓他們重新 replacaof 到 master上，重新建立runID和slave_repl_offset ，來(lái)保證數(shù)據(jù)的正常傳輸和主從一致性。

信息通知主要通過(guò)** Redis 的發(fā)布者/訂閱者機(jī)制來(lái)實(shí)現(xiàn)的。每個(gè)哨兵節(jié)點(diǎn)提供發(fā)布者/訂閱者機(jī)制，客戶端可以從哨兵訂閱消息。主從切換完成后，哨兵就會(huì)向?+switch-master?頻道發(fā)布新主節(jié)點(diǎn)的 IP 地址和端口的消息，這個(gè)時(shí)候客戶端就可以收到這條信息，然后用這里面的新主節(jié)點(diǎn)的 IP 地址和端口進(jìn)行通信了**。

總結(jié)

哨兵模式的核心還是主從模式的演變，只不過(guò)相對(duì)于主從模式在主節(jié)點(diǎn)宕機(jī)導(dǎo)致不可寫的情況下，多了探活，以及競(jìng)選機(jī)制：從所有的從節(jié)點(diǎn)競(jìng)選出新的主節(jié)點(diǎn)，然后自動(dòng)切換。Redis 哨兵模式通過(guò)監(jiān)控、協(xié)調(diào)和通知機(jī)制，使得 Redis 集群能夠在主節(jié)點(diǎn)故障時(shí)自動(dòng)完成切換，提高了 Redis 的高可用性。