Redis哨兵的配置和原理

原文做者：XuePeng77

哨兵

在一個典型的一主多從的Redis系統中，當主數據庫遇到異常中斷服務後，須要手動選擇一個從數據庫升級爲主數據庫，整個過程須要人工介入，難以自動化。

Redis2.8提供了哨兵2.0（2.6提供了1.0，可是問題較多），哨兵顧名思義就是監控Redis系統的運行情況。它的功能包括一下兩個：

• 監控主數據庫和從數據庫是否正常運行；
• 主數據庫出現故障時自動將從數據庫升級爲主數據庫；

哨兵是一個獨立的進行，在一個一主多從的Redis系統中，能夠使用多個哨兵監控整個Redis系統，哨兵之間也會互相監控。

配置

基於前面的一主兩從架構，爲他們加入哨兵。

能夠在三個redis節點的redis目錄下找到sentinel.conf文件，這個文件就是哨兵的配置文件，修改配置以下：

sentinel monitor mymaster 192.168.2.101 6379 3複製代碼

其中mymaster是要監控的主數據庫名字，能夠自定義；

接下來是主數據庫的ip和端口；

最後一個3是指哨兵最低經過票數；

若是你須要後臺啓動，則修改daemonize參數：

daemonize yes複製代碼

配置後若是有防火牆，不要忘記打開哨兵的端口，默認是26379。

最後，開啓哨兵：

redis-sentinel /yourpath/sentinel.conf複製代碼

作個測試，關閉主數據庫（192.168.2.101）後，等待30秒（默認30秒）：

• 哨兵將從數據庫中的一個節點升級成主數據庫（192.168.2.102）；
• 將另外一個從數據庫（192.168.2.103）的主數據庫（192.168.2.101）切換到新的主數據庫（192.168.2.102）；

隨後啓動剛纔關閉的主數據庫（192.168.2.101）

• 哨兵自動將其轉爲從數據庫；

原理

監控過程

哨兵啓動後，會與要監控的主數據庫創建兩條鏈接：

1. 一條用來用來訂閱__sentinel__:hello頻道以獲取其餘哨兵節點的信息；
2. 另外一條用來按期向主數據庫發送INFO等命令來獲取主數據庫自己的信息；

在和主數據庫創建鏈接後，哨兵會定時執行下面3個操做：

1. 每10秒哨兵會向主數據庫和從數據庫發送INFO命令；
2. 每2秒哨兵會向主數據庫和從數據庫的__sentinel__:hello頻道發送本身的信息；
3. 每1秒哨兵會向主數據庫和從數據庫和其餘哨兵發送PING命令；

第一個操做是發送INFO命令，目的是獲取主數據庫的信息，以及主數據庫的從數據庫的信息，從而實現新節點的自動發現，並對從數據庫也創建兩條鏈接。

第二個操做是訂閱__sentinel__:hello頻道，併發送哨兵自己的信息，與一樣監控該數據庫的其餘哨兵分享本身的信息，同時也能識別哨兵是不是新哨兵。哨兵與哨兵之間也會創建一個連接，用來發送PING命令；

第三個操做是發送PING命令，在發現了從數據庫和其餘哨兵後，要作的就是定時監控Redis服務是否中止，時間間隔與配置文件中的down-after-milliseconds有關，當這個值小於1秒時，哨兵會每隔該值的時間發送PING命令，當這個值大於1秒時，哨兵會每隔1秒發送一次PING命令。

配置方式是在sentinel.conf文件中加入：

sentinel down-after-milliseconds mymaster 600 # 600毫秒發送一個PING複製代碼

當超過down-after-milliseconds時，若是PING的數據庫未回覆，則哨兵認爲其主觀下線。主觀下線能夠理解爲當前的哨兵認爲該節點下線了。

若是該節點是主數據庫，則哨兵們會進一步判斷是否須要對其進行故障修復：

哨兵會發送SENTINEL is-master-down-by-addr命令詢問其餘哨兵，判斷他們是否也認爲該主數據庫下線，若是達到quorum參數，也就是咱們在配置哨兵時的命令：

sentinel monitor mymaster 192.168.2.101 6379 3複製代碼

的最後一個參數3，哨兵們會認爲這個主數據庫客觀下線，並選舉一個領頭哨兵對主從系統發起故障恢復。

領頭哨兵選舉

要進行故障恢復，則須要選舉出一個領頭哨兵，領頭哨兵的選擇算法是Raft算法，具體過程以下：

發現主數據庫客觀下線的哨兵節點（A節點）想每一個哨兵節點發送命令，要求對方選擇本身成爲領頭哨兵；

若是目標哨兵節點沒有選擇過其餘人，則會贊成將A設置成領頭哨兵；

若是A發現超過半數且超過quorum參數個哨兵節點贊成選擇本身，則A成功成爲領頭哨兵；

當有多個哨兵同時參選，則會出現沒有任何節點當選的可能，此時每一個參選節點將等待一個隨即時間從新發起競選，直到選舉成功。

故障恢復

選擇出領頭哨兵後，會把從數據庫中的一個挑選出來升級爲主數據庫：

1. 全部先線的從數據庫中，選擇優先級最高的，優先級能夠經過slave-priority來設置；
2. 若是有多個同樣優先級的從數據庫，則複製的命令偏移量越大，越優先（與down掉的主數據庫最接近）；
3. 若是還有多個備選，則選擇運行ID較小的（運行ID不會重複）；

選擇好節點後，領頭哨兵將想這個節點發送slaveof no one，升級他爲主數據庫。

而後想其餘從數據庫發送slaveof命令切換主數據庫。

最後更新內部的記錄，將已經中止服務的舊的主數據庫更新爲新的主數據庫的從數據庫，當其回覆後自動以從數據庫的身份加入到主從架構中。

哨兵部署

哨兵的推薦部署方案：

1. 爲每一個節點（不管是主數據庫仍是從數據庫）都部署一個哨兵；
2. 使每一個哨兵與其對應的節點的網絡環境相同或相近；

設置quorum的值爲N/2+1，這樣使得只有當大部分哨兵統一後纔會選擇領頭哨兵進行故障恢復；

推薦閱讀：

【備戰春招系列】關於kafka，BAT大廠都喜歡怎麼問？

【備戰春招系列】ZooKeeper靈魂28問，教你如何搞定面試官！

【備戰春招系列】最新Linux 面試真題45道

【備戰春招系列】歷年來關於MySQL高頻面試真題的梳理

【備戰春招系列】springBoot靈魂22問！

【備戰春招系列】50道微服務面試真題詳解

【備戰春招系列】27道MyBatis面試真題詳解

大廠resdis靈魂40問，教你如何搞定面試官

更多技術文章和麪試真題能夠關注微信公衆號：Java程序員彙集地。