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

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

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

• 哨兵介紹
• 哨兵配置
• 哨兵工做原理

本文實現環境

• centos7.3 redis4.0
• redis工做目錄 /usr/local/redis
• 在虛擬機進行模擬操做

1、什麼是哨兵

先簡單說幾句咱們在配置主從複製時有一種狀況就是主節點宕機了，誰來提供服務呢！

當主節點宕機後主從複製就沒有存在的意義了，數據爲王的時代沒有了數據何談什麼高可用。

這個時候就橫空出世了一位老大哥名叫 哨兵，老大哥說這個問題我來幫大家處理。

既然主節點master做爲老大不領大家玩了。我就從大家四個中間再挑選出來一位老大，而後大家跟着他玩。

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

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

最後咱們用專業術語來解釋一下什麼是哨兵。

哨兵，英文名sentinel,是一個分佈式系統，用於對主從結構中的每一臺服務器進行監控，當主節點出現故障後經過投票機制來挑選新的主節點，而且將全部的從節點鏈接到新的主節點上。

2、哨兵的做用

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

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

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

• 監控
  • 監控誰？支持主從結構的工做一個是主節點一個是從節點，那確定就是監控這倆個了。
  • 監控主節點和從節點是否正常運行
  • 檢測主節點是否存活，主節點和從節點運行狀況
• 通知
  • 哨兵檢測的服務器出現問題時，會向其餘的哨兵發送通知，哨兵之間就至關於一個微信羣，每一個哨兵發現的問題都會發在這個羣裏。
• 自動故障轉移
  • 當檢測到主節點宕機後，斷開與宕機主節點鏈接的全部從節點，在從節點中選取一個做爲主節點，而後將其餘的從節點鏈接到這個最新主節點的上。而且告知客戶端最新的服務器地址。

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

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

2、如何配置哨兵

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 '^$' > ./conf/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服務器，端口分別爲637九、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的仍是沒有上線，因而給踢下線

當咱們在從新把6379的redis服務器上線後，就能夠看到哨兵服務端響應了倆句。一句是去除6379的下線。最後一句就是重連6379到新的主節點上。

這個時候主節點就是6380了，在6380的redis客戶端設置值，檢測主從複製是否正常工做。

在新的主節點6380添加list類型

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

3、哨兵工做原理

配置完哨兵後，就須要對其工做原理進行解析了，只有知道其工做流程，才能對哨兵有更好的理解。

本文講解原理沒有那麼幹巴！讓你能夠把一篇技術文章當故事去看。

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

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的建立時間來判斷，時間早的上位。

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

4、總結

關於哨兵的全部知識點就已經說完了，本文最重要的就是哨兵的工做原理了。咱們在簡單的梳理一下其工做原理。

• 首先進行監控，而且全部的哨兵同步信息

• 哨兵向訂閱裏邊發佈信息

• 故障轉移

  • 哨兵發現主節點下線
  • 哨兵開啓投票競選負責人
  • 由負責人推選新的主節點
  • 新的主節點斷開原主節點，而且其餘的從節點鏈接新的主節點，原主節點上線後做爲從節點鏈接。

以上就是咔咔對哨兵的理解，若是錯誤能夠提出，咔咔及時改正。

5、咔咔我的簡介

咔咔，男，17年入行，從業已經有三年。從搬磚同樣的生活方式換成了如今有「單」而居的日子。固然這個單不是單身的單！雖然極盡苛刻的技術學習但也遠不及客戶千奇百怪的要求。進入了朝九晚六，雖然躲過了風吹日曬，可是仍然很享受那些熬得只剩下黑眼圈的日子。堅持學習、堅持寫博、堅持分享是咔咔從業以來一直所秉持的信念。但願在諾大互聯網的中咔咔的文章能帶給你一絲絲的幫助。