Redis系列——哨兵掛了，redis 還能正常工做嗎？

​

 前言

redis 主掛掉了，怎麼將請求轉移到從上去，若是從是多個，從是怎麼進行選舉的呢？

那麼就要看咱們今天的主角了，redis哨兵，redis哨兵可以幫助咱們自動的完成選主和故障轉移操做，此次仍是會多畫圖，來加深你們都這個過程的記憶和理解。

redis哨兵都幹了什麼

redis哨兵是一個運行的特殊的redis進程，他主要有三個使命：

• 監控
• 選主
• 通知

監控的是什麼

哨兵主要是監聽主庫和從庫是否存活，怎麼進行監控？ 哨兵會按期的給從庫發送PING命令，若是從庫沒有在設定的時間內回覆哨兵，那麼就會認爲從庫下線了。哨兵也會按期的給主庫發送PING命令進行通訊，若是主庫也沒有在設定的時間內回覆哨兵，那麼就會認爲主庫也「下線了」。【注意我這裏只是爲了說明下監控的方式，真正判斷的主庫下線不是這樣的】。

看圖說話：

​

能夠看到圖中redis-2 slave 是灰色，表示已經down掉了，此時並無正常返回給哨兵響應，因此被標記爲下線狀態了。

主庫的監控

這裏爲何要單獨來講下主庫的監控呢？由於主庫監控，不能說哨兵沒有收到PING的響應，那麼就認爲主庫就下線了，由於主庫的選舉是一個很複雜的過程，會有耗時和通訊的開銷，因此咱們不能簡單認爲哨兵沒有收到PING的響應，那麼就直接判斷主庫下線了，而後就進行選舉，若是是從庫能夠的，由於從庫下線了，對於主從集羣來講，影響不會很大。

在主庫壓力比較大，或者網絡阻塞了，出現抖動了，這個是並無在設定的時間內回覆給哨兵響應，那麼此時武斷的認爲主庫"下線了"，此時就出現了誤判，明明不須要進行選主，不須要進行通知，此時白白浪費的資源、同時帶來了開銷。

看圖說話：

在網絡暢通的狀況下，哨兵發了一個PING給主庫

​

此時網絡阻塞，變成了紅色，PONG，沒有在設定的時間內返回

​

網絡恢復順暢，哨兵重試，在設定的時間內返回響應

​

經過上面三幅圖，其實就能夠看出，網絡阻塞的狀況下，會出現誤判的狀況。

那麼reids是怎麼判斷主庫下線的呢？其實redis採用哨兵集羣的方式，讓哨兵集羣中的每一個哨兵都和主庫進行通訊，若是多數都沒有在設定的時間內響應給哨兵，由於多個哨兵都出現網絡不穩定的狀況機率就大大下降了，那麼此時這個主庫就認爲是下線了。下面咱們來細細的說下這個過程，同時引入哨兵集羣也解決了哨兵單點的問題。

主庫的下線判斷

這個過程分爲主觀下線和客觀下線。

主觀下線：指的是一個哨兵在設定的時間內，沒有收到主庫的響應，那麼此時是這個哨兵主觀的認爲主庫下線了，並不能認爲真正的下線。

客觀下線：指的是，當多數哨兵在設定的時間內，都沒有收到主庫的響應，那麼此時就能夠認爲主庫真的下線，稱爲客觀事實了。

繼續看圖說話：

下圖中只有哨兵B，沒有在設定的時間內，收到響應，判斷爲主觀下線了，可是其餘哨兵A和哨兵C都能在設定的時間內收到響應，因此仍是線上狀態，少數服從多數，此時結論仍是上線狀態。

​

下圖中哨兵B和哨兵C，都沒有在設定的時間內收到響應，即便哨兵A收到正常的響應，那麼此時已經構成多數狀況下的主觀下線，此時就能夠判斷爲客觀下線了。

​

選主

上面的我相信你們已經很清楚，redis的怎麼判斷主庫的下線了，那麼此時redis須要從剩下的全部的從庫中再次選舉出一個新的主庫，來接收後面來的寫請求。

reids哨兵會對從庫們進行打分，誰的分數高，那麼它就是新的master了，下面來詳細說選主的過程。

哨兵在進行打分以前，先會在從庫進行篩選，把不合格的從庫篩選掉，留下優秀的種子選手來進行參賽打分。

那麼篩選的依據是什麼呢？

哨兵會把標記爲下線的從庫和主從之間網絡不暢的從庫篩選掉，看下圖你就明白了：

​

在主從模式下，若是主從之間網絡斷開的次數和超時時間超過down-after-milliseconds 的設置，那麼就會認爲該從庫網絡不健康了，不穩定了。

接下來就會從剩下的優秀從庫內進行打分，打分最高者爲新的Master，

打分會從三個層級進行打分，記住只會比較一個層級的分數，只要在當前的層級分數最高就能夠了，若是分數相同，再比下一個層級，以此類推。

第一輪：比較從庫的優先級

你能夠手動設置從庫的優先級，經過slave-priority進行設置，數字越小，級別越高。若是這個層次，有優先級級別最高的出現，那麼就選此從庫作爲Master，選舉就結束了，若是優先級相同，那麼進入下一輪打分。 看圖：

​

第二輪：與主庫的同步進度越接近

確定是從庫的數據越新，那麼選擇它做爲新的Master，才最有意義了。那怎麼才能知道哪一個從庫纔是最新的呢？

從庫會記錄本身同步主庫的進度，這個參數爲slave_repl_offset, 是累加的，也就是這個值越大，那麼它們誰同步的數據就是最新的，得分就是最高的，選舉就結束了，若是複製進度相同，那麼還須要進入下一輪，比較ID。 看圖：

​

第三輪：ID號越小，得分越高

比較本身的ID【redis在啓動的時候，會給本身分配一個ID】，ID越小，本身得分就越高。

​

最多經歷三輪打分，主庫就會被從新選出，那麼哨兵就會通知其餘從庫執行replicaof 指向新的主庫，進行主從切換，這裏有一個細節，須要注意，不知道你沒有想到，就是由哪一個哨兵來執行主從切換呢？

哨兵選舉Leader

其實由哪一個哨兵來進行發號施令，進行主從切換，這個哨兵是須要進行選舉的其實由哪一個哨兵來進行發號施令，進行主從切換，這個哨兵是須要進行選舉的。

本篇前面說過，判斷主庫是否下線是須要進行主觀下線和客觀下線兩個過程，本身先標記爲主觀下線，當多數都標記爲主觀下線的時候，那麼就認爲客觀下線了，那麼這個多數應該是多少呢，實際上是經過quorum配置項配置的，若是咱們有三個哨兵，quorum 配置爲2 ，那麼除了本身判斷主觀下線，還須要一個哨兵也須要判斷爲主觀下線，那麼此時纔會進入客觀下線了，這個判斷的過程，其實就是一個投票的過程，包括本身給本身投一票，還包括向其餘實例發送is-master-down-by-addr 命令，詢問其餘實例，本身判斷的這個主庫是否是下下了，若是獲得對方的響應，那麼本身的票數就累加，哨兵投過票了，就不會給其餘哨兵再次投票了。

這裏具體看圖：

​

這個圖只是簡單的爲了說明，哨兵B和哨兵C都發現了redis Master 爲主觀下線了，可是哨兵B 優先給其餘哨兵發了is-master-down-by-addr命令，並獲得了哨兵C的回覆，那麼加上本身給本身的投票，那麼就是得票數爲2 ，大於等於 quorum的配置值 2，此時主庫標記爲客觀下線.

若是哨兵B 要想成爲Leader，那麼還要同時知足獲得的票數大於等於哨兵（n/2 + 1）數量才能夠成爲leader，這裏因爲咱們有三個哨兵，票數過半的話，也就是大於等於2，因此此時哨兵B能夠成爲Leader了。

因此稱爲leader要知足的條件爲：

• 獲得的票數要達到配置的quorum閥值。
• 得到哨兵半數以上的票數。

通知

哨兵B Leader 能夠主持主從切換了,通知其餘從庫執行replicaof 到新的Master，主從切換完成以後，還會通知鏈接redis 的客戶端，告訴它們新的Master的地址和端口。

這裏在說下是怎麼通知redis 客戶端 Master要換新的ip和端口了呢？

其實redis客戶端能夠定於哨兵的主從切換事件，當完成主從切換後，哨兵就發送這個事件的結果，那麼訂閱了這個事件的redis客戶端都會收到通知，此時redis客戶端就能夠更新到新的Master的地址了。

若是出現網絡斷開或者抖動，沒有收到訂閱事件的通知，那麼其實還能夠調用哨兵提供的接口，進行從新拉取。

通知模型：

​

總結

今天主要是熟悉哨兵的工做原理和過程，下面來作下總結：

哨兵都幹了什麼？

監控、選主、通知。

監控：

監控主從節點是否下線，從節點能夠簡單認爲沒有收到響應就直接下線，由於從節點下線通常不會影響到集羣的使用。

主節點的下線，分爲主觀下線和客觀下線，只有在多數都認爲是主觀下線了，才認爲是客觀下線了。

選主：

首先進行篩選，把標記爲下線的從庫，網絡不穩定的從庫曬出掉。
接下來進行打分，主要會分三個階段：分別從 從庫的優先級、複製進度、ID大小來進行打分。

通知：

通知其餘從庫執行replicaof 到新的Master，主從切換完成以後，還會通知鏈接redis 的客戶端，告訴它們新的Master的地址和端口。

哨兵選舉過程：

哨兵投票機制：

a：哨兵實例只有在本身斷定主庫下線時，纔會給本身投票，而其餘的哨兵實例會把票投給第一個來要票的請求，其後的都拒絕。
b：若是出現多個哨兵同時發現主庫下線並給本身投票，致使投票選舉失敗，就會觸發新一輪投票，直至成功。

哨兵成爲Leader的必要條件：

a：得到半數以上的票數。
b：獲得的票數要達到配置的quorum閥值。

注意的點

在master關掉 到 主從切換完成，通知完客戶端，這個期間，全部的寫請求是不能處理的，由於master已經掛掉了，若是採用的是讀寫分離，全部的讀請求就是能夠正常處理的，讀請求會被分到從庫上去。若是此時想讓業務感知不到異常，能夠採起相應的降級策略，可讓寫請求先寫入到mq中，等待恢復以後，再寫入到新的master就能夠了。

這裏在強調一下哨兵進行主從切換的前提條件，必需要選擇出哨兵Leader，由Leader進行通知從進行主從切換和通知客戶端更換新的Master的地址和端口。

在這裏舉個例子，若是有5個哨兵，quorum 配置爲2，那麼要想成爲Leader，那麼得到票數必需要達到2 才能判斷一個主庫爲客觀下線，同時得到票數也要大於等於(n/2) + 1 的票數，也就是得到3以上才能夠。若是此時有3個哨兵故障了，即便你得到了2票，能判斷爲客觀下線，那麼因爲沒有過半的哨兵數量，也是沒法選舉出Leader ，也就沒法進行下面的過程了，此時集羣就玩完了。

問題

這裏給你們留一個問題，咱們知道能夠經過下面命令進行哨兵集羣的搭建：

sentinel monitor <master-name> <ip> <redis-port> <quorum>

這裏只是設置了 ip 和端口，以及quorum值，那麼整個集羣之間是怎麼創建通訊，進而能後續的選舉leader作準備，同時它又是怎麼得到從庫的ip和端口列表，進而來作後續的從庫的監控。

兩個問題：

• 集羣怎麼創建通訊的？
• 集羣怎麼獲取的從庫列表？

 

 一直想整理出一份完美的面試寶典，可是時間上一直騰不開，這套一千多道面試題寶典，結合今年金三銀四各類大廠面試題，以及 GitHub 上 star 數超 30K+ 的文檔整理出來的，我上傳之後，毫無心外的短短半個小時點贊量就達到了 13k，說實話仍是有點難以想象的。

一千道互聯網 Java 工程師面試題

內容涵蓋：Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、Redis、MySQL、Spring、SpringBoot、SpringCloud、RabbitMQ、Kafka、Linux等技術棧（485頁）

​

《Java核心知識點合集（283頁）》

內容涵蓋：Java基礎、JVM、高併發、多線程、分佈式、設計模式、Spring全家桶、Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、MongoDB、Redis、MySQL、RabbitMQ、Kafka、Linux、Netty、Tomcat、數據庫、雲計算等

​

《Java中高級核心知識點合集（524頁）》

​

《Java高級架構知識點整理》

​

​ ​

 因爲篇幅限制，詳解資料太全面，細節內容太多，因此只把部分知識點截圖出來粗略的介紹，每一個小節點裏面都有更細化的內容!

須要的小夥伴，能夠一鍵三連，下方獲取免費領取方式！

​

 

 

​