三分鐘帶你入門Redis 高可用架構(gòu)之哨兵
什么是哨兵?
哨兵(Sentinel)是 redis 的高可用性解決方案,前面我們講的主從復(fù)制它是高可用的基礎(chǔ),但是單純的主從復(fù)制需要人工介入才能完成故障轉(zhuǎn)移,哨兵可以解決這個問題,在主從復(fù)制情況下,當主節(jié)點發(fā)生故障時,哨兵可以自動的發(fā)現(xiàn)故障并且完成故障轉(zhuǎn)移,實現(xiàn)真正的 redis 高可用。在哨兵集群中,哨兵會監(jiān)視所有的 redis 服務(wù)器和其他 sentinel 節(jié)點狀態(tài),及時發(fā)現(xiàn)故障完成轉(zhuǎn)移,從而保證 redis 的高可用。
哨兵群集的搭建
哨兵本質(zhì)也是一個 redis 服務(wù),只是跟普通的 redis 服務(wù)提供了不一樣的功能。哨兵是一個分布式架構(gòu),因為你要保證 redis 高可用,首先需要保證自己高可用,所以如果我們需要搭建哨兵的話,最少需要部署三個實例,最好是奇數(shù)個,因為在后續(xù)的故障轉(zhuǎn)移中會涉及到投票。
哨兵的配置文件我們可以在 redis 的 GitHub 項目下下載,在項目下有一個叫做 sentinel.conf 的文件,可以使用它作為我們哨兵的配置模板,當然你也可以使用 redis.conf 配置文件,只需要添加哨兵相關(guān)配置就好了。
哨兵相關(guān)的配置項不多,主要有以下幾個配置項:
- // 端口號,默認是 redis 實例+20000,所以我們沿用這個規(guī)則就好了
- port 26379
- // 是否守護進程運行
- daemonize yes
- // 日志存放的位置,這個非常重要,通過日志可以查看故障轉(zhuǎn)移的過程
- logfile "26379.log"
- // 監(jiān)視一個名為 mymaster(自定義) 的 redis 主服務(wù)器, 這個主服務(wù)器的 IP 地址為 127.0.0.1 , 端口號為 6379 ,
- // 最后面的 2 代表著至少有兩個哨兵認為主服務(wù)器出現(xiàn)故障才會進行故障轉(zhuǎn)移,否則認定主服務(wù)未失效
- sentinel monitor mymaster 127.0.0.1 6379 2
- // 哨兵判斷服務(wù)器失效的響應(yīng)時間,超過這個時間未接收到服務(wù)器的回應(yīng),就認為該服務(wù)器失效了
- sentinel down-after-milliseconds mymaster 30000
- // 完成故障轉(zhuǎn)移之后,最多多少個從服務(wù)器可以同時發(fā)起數(shù)據(jù)復(fù)制,數(shù)字越小,說明完成全部從服務(wù)數(shù)據(jù)復(fù)制的時間越長
- // 數(shù)字越大,對主服務(wù)器的壓力就變大了
- sentinel parallel-syncs mymaster 1
- // 故障轉(zhuǎn)移超時時間
- sentinel failover-timeout mymaster 180000
對于每個 Sentinel 實例配置除了 port 和 logfile 不同之外,其他配置項都是一樣的。修改好配置后,我們可以使用 ./redis-sentinel sentinel.conf 命令來啟動哨兵,命令跟 redis 實例啟動差不多,因為哨兵也是 redis 實例,所以我們可以使用 ./redis-cli -p 26379 info sentinel 命令查看當前的哨兵信息,如下圖所示:
哨兵信息
問題:如何在只配置 master 服務(wù)器的情況下,發(fā)現(xiàn)從服務(wù)器和其他 Sentinel ?
從服務(wù)器的發(fā)現(xiàn),Sentinel 可以通過詢問主服務(wù)器來獲取從服務(wù)器的信息,對于發(fā)現(xiàn)其他 Sentinel 節(jié)點,則通過發(fā)布與訂閱功能實現(xiàn),通過向頻道 sentinel:hello 發(fā)送信息來實現(xiàn)的,主要有以下兩步:
1、每個 Sentinel 每 2 秒會通過發(fā)布與訂閱功能向所有的主服務(wù)和從服務(wù)器的 sentinel:hello 頻道發(fā)送一條信息, 信息中包含了 Sentinel 的 IP 地址、端口號和運行 ID (runid)
2、每個 Sentinel 都訂閱了被它監(jiān)視的所有主服務(wù)器和從服務(wù)器的 sentinel:hello 頻道, 查找之前未出現(xiàn)過的 sentinel (looking for unknown sentinels)。當一個 Sentinel 發(fā)現(xiàn)一個新的 Sentinel 時, 它會將新的 Sentinel 添加到一個列表中, 這個列表保存了 Sentinel 已知的, 監(jiān)視同一個主服務(wù)器的所有其他 Sentinel
哨兵故障轉(zhuǎn)移原理
故障轉(zhuǎn)移是哨兵的主要工作,這背后的實現(xiàn)邏輯也是非常的復(fù)雜,具體的實現(xiàn)邏輯還請查看相關(guān)書籍,我對哨兵的故障轉(zhuǎn)移總結(jié)了以下三點:
1、監(jiān)聽服務(wù)器
每個 Sentinel 節(jié)點每隔 1 秒對主節(jié)點、從節(jié)點、其他 Sentinel 節(jié)點發(fā)送 ping 命令做心跳檢測,來判斷服務(wù)器的狀態(tài)。
節(jié)點也會對 Sentinel 進行相應(yīng)的回復(fù),在這些回復(fù)中,以下三種回復(fù)是有效回復(fù):
- 返回 +PONG
- 返回 -LOADING
- 返回 -MASTERDOWN
如果節(jié)點在哨兵配置文件設(shè)置的 master-down-after-milliseconds 選項的值內(nèi),一直沒有哪怕一次有效回復(fù),那么 Sentinel 會把該服務(wù)器標記為下線狀態(tài),我們把這種下線稱為主觀下線,也就是說只有這個 sentinel 認為該服務(wù)器是下線狀態(tài)。
如果被主觀下線的服務(wù)器是主服務(wù)器時,sentinel 為了確認這個主服務(wù)器是否真的下線,該 Sentinel 會向其他的同樣監(jiān)聽主服務(wù)器的 Sentinel 進行詢問,看他們是否也認為主服務(wù)器進入下線狀態(tài),當有足夠多的 Sentinel 都認為主服務(wù)器下線時,該 Sentinel 會將主服務(wù)器判斷為客觀下線,這是真正的下線了,并且會對它進行故障轉(zhuǎn)移操作。
2、選舉 Sentinel 節(jié)點完成轉(zhuǎn)移任務(wù)
故障轉(zhuǎn)移并不是所有的 sentinel 共同完成,而是選舉出一臺 sentinel 節(jié)點作為領(lǐng)導(dǎo)者來完成這次故障轉(zhuǎn)移,所以當主服務(wù)器被標記為客觀下線時,sentinel 之間就會通過 Raft 算法選舉出一個領(lǐng)導(dǎo)者來完成故障轉(zhuǎn)移工作。redis 選舉領(lǐng)頭的 sentinel 的規(guī)則和方法大致如下:
- 所有在線的 sentinel 都有資格被選為領(lǐng)導(dǎo)者,也就是說每個 sentinel 都有成為領(lǐng)導(dǎo)者的機會
- 當 sentinel 標記主服務(wù)器為主觀下線時,會向其他 Sentinel 節(jié)點發(fā)送 sentinel is-master-down-by-addr 命令, 要求將自己設(shè)置為領(lǐng)導(dǎo)者
- 收到命令的 Sentinel 節(jié)點,采用先到先得的規(guī)則,如果沒有同意過其他 Sentinel 節(jié)點的 sentinel is-master-down-by-addr 命令,將同意該請求,否則拒絕
- 如果該 Sentinel 節(jié)點發(fā)現(xiàn)自己的票數(shù)已經(jīng)超過半數(shù),那么它將成為領(lǐng)導(dǎo)者
- 如果在規(guī)定時間內(nèi),沒有選舉出 sentinel 領(lǐng)導(dǎo)者,那么將在一段時間后再次選舉,知道選出 sentinel 領(lǐng)導(dǎo)者為止。
3、選舉新 master 服務(wù)器完成故障轉(zhuǎn)移
選舉出來的 sentinel 領(lǐng)導(dǎo)者將完成剩下的故障轉(zhuǎn)移工作,故障轉(zhuǎn)移主要有以下三步:
(1)挑選出新的主服務(wù)器
在已下線的主服務(wù)器的所有從服務(wù)器中,挑選出一個從服務(wù)器,并將其轉(zhuǎn)換為主服務(wù)器,選擇新的主服務(wù)器的規(guī)則如下:
- 在失效主服務(wù)器屬下的從服務(wù)器當中, 那些被標記為主觀下線、已斷線、或者最后一次回復(fù) PING 命令的時間大于五秒鐘的從服務(wù)器都會被淘汰
- 在失效主服務(wù)器屬下的從服務(wù)器當中, 那些與失效主服務(wù)器連接斷開的時長超過 down-after 選項指定的時長十倍的從服務(wù)器都會被淘汰
- 在經(jīng)歷了以上兩輪淘汰之后剩下來的從服務(wù)器中, 選出復(fù)制偏移量(replication offset)最大的那個從服務(wù)器作為新的主服務(wù)器;如果復(fù)制偏移量不可用, 或者從服務(wù)器的復(fù)制偏移量相同, 那么帶有最小運行 ID 的那個從服務(wù)器成為新的主服務(wù)器
對挑選出來的從服務(wù)器執(zhí)行 slaveof no one 命令,使其成為主節(jié)點。
(2)修改其他從服務(wù)器的復(fù)制目標
當新的主服務(wù)器出現(xiàn)后,sentinel 的領(lǐng)導(dǎo)者下一步需要做的就是,讓其他從服務(wù)器去復(fù)制新的主服務(wù)器,通過向其他從服務(wù)器發(fā)送 slaveof new_master port 命令來完成,復(fù)制規(guī)則和配置文件的 parallel-syncs 參數(shù)有關(guān)
(3)將舊的主服務(wù)器變成從服務(wù)器
故障轉(zhuǎn)移操作最后要做的就是將已下線的主服務(wù)器設(shè)置為新的主服務(wù)的從服務(wù)器,并保持對其關(guān)注,等它恢復(fù)后命令它去復(fù)制新的主節(jié)點。
以上就是我今天要分享的 redis 哨兵知識,希望看完之后你有所收獲。