1、哨兵簡介

master宕機場景的處理：

問題：

怎么確認master確實宕機了？（中間斷網(wǎng)1s就認為人掛了不合適）
怎么找一個slave來暫替master？
舊的master恢復(fù)以后怎么處理？

哨兵(sentinel) 是一個分布式系統(tǒng)，用于對主從結(jié)構(gòu)中的每臺服務(wù)器進行監(jiān)控，當出現(xiàn)故障時通過投票機制選擇新的master并將所有slave連接到新的master

哨兵的三點作用：

• 監(jiān)控
  不斷的檢查master和slave是否正常運行。
• 通知
  當被監(jiān)控的服務(wù)器出現(xiàn)問題時，向其他（哨兵間，客戶端）發(fā)送通知
• 自動故障轉(zhuǎn)移
  斷開master與slave連接，選取一個slave作為master，將其他slave連接到新的master，并告知客戶端新的服務(wù)器地址

注：

• 哨兵也是一臺redis服務(wù)器，只是不提供數(shù)據(jù)服務(wù)
• 通常哨兵配置數(shù)量為單數(shù)，3、5、7……

2、啟用哨兵模式

2.1 哨兵配置

查看哨兵的配置文件，過濾注釋與空行：

具體配置參數(shù)整理：

使用sed編輯文件，并重定向。生成三個哨兵的配置文件（用三個不同端口模擬三個哨兵）

哨兵啟動指令：

redis-sentinel sentinel-端口號.conf先啟動master、再slave、最后啟動哨兵

2.2 哨兵模擬搭建實驗

以本機的6379位master、6380、6381為slave，26379、26380、26381為三個sentinel，模擬實驗：

①啟動master和slave后，啟動26379sentinel：

②連接哨兵的客戶端，驗證其確實不能進行set等指令：

③啟動哨兵26380

注意此時哨兵26379的配置文件會相應(yīng)的發(fā)生變化：

④模擬master宕機，CTRL+C掉6379的server端

⑤6379重新連接服務(wù)端以后，查看哨兵控制臺日志：取消了6379的s_down標記，但并未恢復(fù)其master的身份

3、哨兵工作原理

哨兵在進行主從切換過程中經(jīng)歷三個階段：

• 監(jiān)控
• 通知
• 故障轉(zhuǎn)移

3.1 監(jiān)控階段

sentinel會向master和slave要信息，各個sentinel之間有專門通路進行信息交換，如此便形成了一個網(wǎng)絡(luò)：

3.2 通知階段

就像一個小的朋友圈，sentinel之間互相進行信息的傳播，保持信息的對等：

3.3 故障轉(zhuǎn)移階段

①哨兵1持續(xù)發(fā)消息給master均無反應(yīng)，標記master為S_DOWN，也叫主觀下線

②哨兵1標記后，并將這個消息帶回sentinel的圈子里，告訴其余哨兵，可能master掛了，于是其余哨兵開始發(fā)送消息給master驗證消息是否屬實

③驗證結(jié)果確實如此，只要半數(shù)以上哨兵認為掛了，則標記變?yōu)镺_DOWN（這也是哨兵數(shù)量要求奇數(shù)的原因），這時，O_DOWN就是客觀下線了

④既然確認master掛了，那就要去處理，哪個哨兵去處理呢，每個哨兵發(fā)送掛的IP、掛的端口、自己曾經(jīng)競選的次數(shù)、自己的runID，以便選個領(lǐng)頭的哨兵

最后由競選出來的1號哨兵去處理：

⑤ 從slave中挑選備選master，首先淘汰掉：

• 不在線的
• 響應(yīng)慢的
• 與原master斷開時間久的

對于剩下的備選，則考慮優(yōu)先級、offset、runid等等

⑥向新選出的master發(fā)送slaveof no one，斷開原主從連接，并向其他slave發(fā)送slaveof 新masterIP端口

至此，故障轉(zhuǎn)移完成?。?/p>

到此這篇關(guān)于Redis哨兵模式的實現(xiàn)的文章就介紹到這了,更多相關(guān)Redis哨兵模式內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論