Redis哨兵原理，我忍你很久了！

❝

redis主從複製的作用中有這麼一句話“主從複製是高可用的基石”，那什麼是高可用呢！高可用就是減少系統不能提供的時間，也就是常聽到的以6個9為基準。實現高可用必不可少的就是哨兵和集群。本文主要介紹哨兵機制。

❞

#################### ###########前言###################❝######咔咔整理了一個路線圖，打造一份面試寶典，準備按照這樣的路線圖進行編寫文章，後期發現沒有補充到的知識點在進行添加。也期待各位夥伴一起來幫助補充一下。評論區見哦！###❞

在這裡插入圖片描述

##本文主要圍繞以下幾個方面介紹哨兵

• 哨兵介紹

##哨兵工作原理

• 本文實作環境

centos7.3 redis4.0

redis工作目錄 /usr/local/redis

在虛擬機器進行模擬操作# ####################一、什麼是哨兵################先簡單說幾句我們在設定主從複製時有一種情況就是主節點宕機了，誰來提供服務呢！######當主節點宕機後主從複製就沒有存在的意義了，資料為王的時代沒有了資料何談什麼高可用。#########這時候就橫空出世了一位老大哥名叫###哨兵###，老大哥說這個問題我來幫你們處理。###

既然主節點master作為老大不領你們玩了。我就從你們四個中間再挑選出來一位老大，然後你們跟著他玩。

等不帶你們玩的那個老大回來後他的身分就失效了，就不在是你們的老大了。他只能跟著我挑選出來的老大玩。

上邊這段對話過程就是我們配置哨兵的意義到底在哪，跟誰玩就是誰給誰數據，知道了哨兵的作用我們就在繼續。

「最後我們用專業術語來解釋什麼是哨兵。」

#哨兵，英文名sentinel,是一個分散式系統，用於對主從結構中的每一台伺服器進行監控，當主節點出現故障後透過投票機制來挑選新的主節點，並且將所有的從節點連接到新的主節點。

二、哨兵的作用

#上文中我們談到的對話過程就是哨兵的作用之一自動故障轉移。

談到作用肯定就是這個哨兵到底在工作中到底做了什麼事情。我們先用比較乾巴的概念來描述一下，然後在下文的工作原理會一一談到。

哨兵的三個功能監控、通知、自動轉移故障

• 監控

  • 監控誰？支持主從結構的工作一個是主節點一個是從節點，那肯定就是監控這兩個了。
  • 監控主節點和從節點是否正常運行
  • #偵測主節點是否存活，主節點和從節點運行情況
• 通知

  • 哨兵偵測的伺服器出現問題時，會向其他的哨兵發送通知，哨兵之間就相當於一個微信群，每個哨兵發現的問題都會發在這個群組。
• 自動故障轉移

  • #當偵測到主節點宕機後，斷開與當機主節點連接的所有從節點，在從節點中選取一個作為主節點，然後將其他的從節點連接到這個最新主節點的上。並且告知客戶端最新的伺服器位址。

這裡有一個注意點，哨兵也是redis伺服器，只是不對外提供任何服務。

配置哨兵時配置為單數。那為什麼配置哨兵伺服器的數量為單數呢？帶著這個疑問你會在下文看到你想要的答案。

二、如何設定哨兵

1. 準備工作

這一章我們就開始設定哨兵，前期工作準備。下圖就是咔咔的準備。開啟8個客戶端，三個哨兵、一個主節點、兩個從節點、一個主節點客戶端、一個從節點客戶端。

2. sentinel.conf設定解讀

#哨兵使用的設定檔是sentinel.conf#我們來對sentinel.conf配置資訊進行解讀但是大多數都是註釋，這裡咔咔給大家一個命令來過濾這些無用資訊cat sentinel.conf | grep -v '#' | grep -v '^$'

#

• port 26379 ：對外服務連接埠號碼
• dir /tmp：儲存哨兵的工作資訊
• sentinel monitor mymaster 127.0.0.1 6379 2：監控的是誰，名字可以自定義，後邊的2代表的是，如果有兩個哨兵判斷這個主節點掛了那這個主節點就掛了，通常設定為哨兵個數一半加一。
• sentinel down-after-milliseconds mymaster 30000：哨兵連接主節點多久沒有回應就代表掛了。後邊30000是毫秒，也就是30秒。
• sentinel parallel-syncs mymaster 1：這個設定項是指在故障轉移時，最多有多少個從節點對新的主節點進行同步。這個值越小完成故障轉移的時間就越長，這個值越大就代表越 多的從節點因為同步資料而不可用。
• sentinel failover-timeout mymaster 180000：在進行同步的過程中，多久完成算有效，系統預設值是3分鐘。

3. 開始設定

#使用指令cat sentinel.conf | grep -v '#' | grep -v '^$' > ./data/sentinel-26379.conf把sentinel.conf過濾後的資訊移到/usr/local/redis/conf下然後開啟sentinel-26379.conf修改訊息存放目錄然後快速的複製兩個哨兵設定文件，連接埠為26380和26381。 sed 's/26379/26381/g' sentinel-26379.conf > sentinel-26381.conf

在這裡插入圖片描述

測試主從複製處於正常工作狀態，啟動三台redis伺服器，連接埠分別為 6379、6380、6381查看主節點訊息，是有兩個台從節點在連接著，連接埠分別為6380、6381。

這裡有一個小小的點就是lag怎麼一個是1一個是0呢！ lag是延遲時間，我這裡是本地測試所以會出現0的情況，使用雲端伺服器是很少出現的。 lag的值為0和1都屬於正常。 測試主節點加入一個hash值，hset kaka name kaka分別從slave1和slave2取得kaka的值，偵測主從複製是否正常運作。

經過測試我們的主從結構是正常運作的。 啟動一個哨兵redis-sentinel 26379-sentinel.conf連接26379哨兵，主要是最後一行，監控的主節點名為mymaster，狀態正常，從節點有倆個，哨兵數量為1個在來查看一下26379的哨兵配置信息，這個時候已經改動了在啟動一個26380的哨兵，redis-sentinel 26380-sentinel .conf,這裡注意一下最後一行多了一條訊息，這個id就是我們26379設定檔新增的id然後我們來到哨兵26379的客戶端，同樣也是新增的26380哨兵的id這時候我們在查看一下26379哨兵的配置文件，第一次查看配置文件是沒有配置26380哨兵的，第二次查看時配置了26380哨兵後添加的信息。 最後我們需要把哨兵客戶端3啟動起來，連接埠號碼為26381。啟動起來之後，我們的設定資訊和服務端的資訊也會改動，增加哨兵26380有的訊息，哨兵26381也會有。

直到這裡我們對哨兵的配置就結束了，接下來我們把主節點master給宕掉等待30秒後我們來到26379哨兵的客戶端，這裡新增了一些信息，那麼這些資訊都做了什麼呢！讓我們細細道來。

這裡邊的資訊我們先需要知道幾個

• sdown ：這個訊息後是指三個哨兵裡邊有一個認為主節點宕機了
• odown：這個訊息是指其他兩個哨兵去連接了一下主節點，發現確實是主節點宕機了
• ##然後發起了一輪投票，這裡咔咔使用的是redis4.0，版本之間這塊訊息有點差異
• switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380：直到這裡是哨兵發起投票的結果，推選埠為6380的redis為主節點
• slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380：這裡連接埠為6381與6379和新的主節點6380做了一個連接
• sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380：最後一句是連接埠是6379的連接埠為6380：最後一句是連接埠沒有上線，於是給踢下線

當我們在重新把6379的redis伺服器上線後，就可以看到哨兵服務端回應了兩個句。一句是去除6379的下線。最後一句就是重連6379到新的主節點上。

這時候主節點就是6380了，在6380的redis客戶端設定值，偵測主從複製是否正常運作。

在新的主節點6380新增list類型

在6379和6381取得這個值，至此呢！我們的哨兵模式就配置完成了。

三、哨兵運作原理

#設定完哨兵後，就需要對其工作原理進行解析了，只有知道其工作流程，才能對哨兵有更好的理解。

本文解說原理沒有那麼乾巴！讓你可以把一篇技術文章當故事去看。

進入正題，哨兵作用是監控、通知、故障轉移。那麼工作原理也是圍繞著這三點來講的。

1. 監控工作流程

#在這裡插入圖片描述

1. 哨兵發送info指令，並且保存所有哨兵狀態，主節點和從節點的資訊
2. 主節點會記錄redis實例的訊息，主節點記錄的資訊跟哨兵記錄的資訊看起來是一樣的，實際上還是有點區別哈。
3. 哨兵會根據在主節點拿到的從節點訊息，給對應的從節點也發送info指令
4. 接著哨兵2來了，同樣的也會改主節點發送info指令，並且建立cmd連線
5. 這時候哨兵2也會保存跟哨兵1一樣的訊息，只不過是保存的哨兵訊息是2個。
6. 這時候為了每個哨兵的訊息都一致它們之間建立了一個發布訂閱。為了哨兵之間的資訊長期對稱它們之間也會互發ping命令。
7. 當再來一個哨兵3時，也會做同樣的事情，給主節點和從節點發送info。並且跟哨兵1和哨兵2建立連線。

2.通知工作流程

Sentinel會給予主從的所有節點發送命令取得其狀態，並且會把資訊發佈到哨兵的訂閱裡。

3. 故障轉移原則（本文重點）

#在這裡插入圖片描述

• 哨兵會一直給主節點發送publish sentinel ：hello，直到哨兵報出sdown，這個字這會是有不是有點熟悉了。沒錯就是我們上文中把主節點斷開後哨兵服務端所報出的訊息。哨兵報出主節點sdown後還沒完，哨兵還會往內網發布訊息說明這個主節點掛了。發送的指令是sentinel is-master-down-by-address-port
• #其餘的哨兵接收到指令後，主節點掛了嗎？讓我去看看到底掛沒掛。發送的訊息也是hello。其餘的哨兵也會發送他們收到的訊息並且發送指示sentinel is-master-down-by-address-port到自己的內網，確認一下第一個發送sentinel is- master-down-by-address-port的哨兵說你說的對，這個傢伙確實掛了。當所有人都認為主節點掛了後就會修改其狀態為odown。當一個哨兵認為主節點掛了標記的是sdown，當半數哨兵都認為掛了其標記的狀態是odown。這也就是配置哨兵為什麼要配置單數的原因。
• 對於一個哨兵認為主節點掛了稱為主觀下線，半數哨兵認為主節點掛了稱之為客官下線。
• 一旦被認為主節點客官下線後，哨兵就會進行下一步操作

❝

這時哨兵已經偵測到問題所在了，那麼到底是那個哨兵去負責推選新的主節點呢！不能是張三也去，李四也去，王五也去，這樣就亂套了、於是就需要在所有的哨兵裡選出領頭的，那麼是如何選的呢！請看下圖。

❞

這時候呢！五個sentinel就在一起開會了，所有的哨兵都在一個內網中，然後他們會做一件事情就是五個sentinel會同時發送指令sentinel is-master-down-by-address-port並且攜帶上自己競選次數和runid。 每個sentinel既是參選者也是投票者，每個sentinel都有一票，信封就代表自己的投票權。 當sentinel1和sentinel4同時把指令送到群組準備競選時，sentinel2這個時候就說我先接到誰的指示就把票投給誰。假如sentinel1發的早，那麼sentinel2的票就會投給sentinel1。 依照這樣的規則一直發起投票直到有一個sentinel的票數為總sentinel數量的一半之多。假設說是sentinel1的票數滿足總哨兵數量的一半之多後，sentinel1就會當選。這個時候就進行到了下一個階段。 在上邊哨兵已經選出了sentinel1為代表去所有的從節點找出一個作為主節點。這個挑選主節點不是隨便拿一個是有一定的規則的。

先把不在線的幹掉

響應慢的干掉，sentinel會給所有的redis發送訊息，響應速度慢的就會被幹掉與原主節點斷開時間最久的干掉，這裡由於演示不夠用了，所有新增了一個slave5，沒有任何意義哈！ 以上三個點都判斷結束後還有salve4和slave5，就會根據優先原則來進行篩選。

• 首先會根據優先級，如果優先權一樣在進行其他判斷
• 判斷offset偏移量，判斷資料同步性，假如說slave4的offset為90  slave5偏移量為100  那麼哨兵就會認為slave4的網路是不是有問題啊！於是就會選slave5為新的主節點。那如果說是slave4和slave5的offset相同呢！還有最後一個判斷
• 最後一步就是判斷runid了，也就是職場中的論資排輩了，也就說根據runid的創建時間來判斷，時間早的上位。

選出新的主節點後就要對所有的節點發送指令了。

四、總結

#關於哨兵的所有知識點就已經說完了，本文最重要的就是哨兵的工作原理了。我們在簡單的梳理一下其工作原理。

• 首先進行監控，並且所有的哨兵同步訊息

• 哨兵向訂閱裡邊發布訊息

• 故障轉移

  • 哨兵發現主節點下線
  • 哨兵開啟投票競選負責人
  • 由負責人推選新的主節點
  • 新的主節點斷開原主節點，並且其他的從節點連接新的主節點，原主節點上線後作為從節點連接。

以上就是喀喀爾對哨兵的理解，如果錯誤可以提出，咔咔及時改正。

❝

堅持學習、堅持寫博、堅持分享是咔咔從業以來一直所秉持的信念。希望在偌大互聯網中咔咔的文章能帶給你一絲絲幫助。我們下期再見。

❞

#推薦：《Redis教學》

以上是Redis哨兵原理，我忍你很久了！的詳細內容。更多資訊請關注PHP中文網其他相關文章！