Redis哨兵原理，我忍你很久了！
- 咔咔原創
- 2020-08-28 17:22:161705瀏覽
❝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：最後一句是連接埠沒有上線，於是給踢下線
這時候主節點就是6380了，在6380的redis客戶端設定值，偵測主從複製是否正常運作。 
在6379和6381取得這個值，至此呢！我們的哨兵模式就配置完成了。 
三、哨兵運作原理
#設定完哨兵後，就需要對其工作原理進行解析了，只有知道其工作流程，才能對哨兵有更好的理解。 本文解說原理沒有那麼乾巴！讓你可以把一篇技術文章當故事去看。進入正題，哨兵作用是監控、通知、故障轉移。那麼工作原理也是圍繞著這三點來講的。
1. 監控工作流程
哨兵發送info指令，並且保存所有哨兵狀態，主節點和從節點的資訊 主節點會記錄redis實例的訊息，主節點記錄的資訊跟哨兵記錄的資訊看起來是一樣的，實際上還是有點區別哈。 哨兵會根據在主節點拿到的從節點訊息，給對應的從節點也發送info指令 接著哨兵2來了，同樣的也會改主節點發送info指令，並且建立cmd連線 這時候哨兵2也會保存跟哨兵1一樣的訊息，只不過是保存的哨兵訊息是2個。 這時候為了每個哨兵的訊息都一致它們之間建立了一個發布訂閱。為了哨兵之間的資訊長期對稱它們之間也會互發ping命令。 當再來一個哨兵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中文網其他相關文章！