建網(wǎng)站能在家里做嗎網(wǎng)站設(shè)計(jì)的流程
哨兵模式介紹
在深入理解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 的高可用性。