解析Redis中的哨兵模式,聊聊搭建和執行流程

2022-01-19 10:00:06
本篇文章帶大家深入瞭解一下Redis中的哨兵模式,介紹一下哨兵模式搭建步驟、執行流程,以及哨兵選舉,希望對大家有所幫助!

基本介紹

哨兵(sentinel)是Redis的高可用性(High Availability)的解決方案:

  • 由一個或多個sentinel範例組成sentinel叢集可以監視一個或多個主伺服器和多個從伺服器。【相關推薦:Redis視訊教學

  • 當主伺服器進入下線狀態時,sentinel可以將該主伺服器下的某一從伺服器升級為主伺服器繼續提供服務,從而保證redis的高可用性。

  • 圖解

1.png

哨兵模式搭建步驟

1、複製一份sentinel.conf檔案

cp sentinel.conf sentinel‐26379.conf
cp sentinel.conf sentinel‐26380.conf
cp sentinel.conf sentinel‐26381.conf

2、相關設定修改

#哨兵sentinel範例執行的埠預設26379
port 26379

#將`daemonize`由`no`改為`yes`
daemonize yes

#哨兵sentinel監控的redis主節點的 ip port
#master-name可以自己命名的主節點名字只能由字母A-z、數位0-9、這三個字元".-_"組成。#quorum當這些quorum個數sentinel哨兵認為master主節點失聯那麼這時客觀上認為主節點失聯了
#sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor master 127.0.0.1 6379 2

#當在Redis範例中開啟了requirepass foobared授權密碼這樣所有連線Redis範例的使用者端都要提供密碼
#設定哨兵sentinel連線主從的密碼注意必須為主從設定一樣的驗證密碼
#sentinel auth-pass <master-name> <password>

sentinel auth-pass master MySUPER--secret-0123passw0rd

#指定多少毫秒之後主節點沒有應答哨兵sentinel此時哨兵主觀上認為主節點下線預設30秒,改成3秒
#sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds master 3000

#這個設定項指定了在發生failover主備切換時最多可以有多少個slave同時對新的master進行同步,這個數位越小,完成failover所需的時間就越長,但是如果這個數位越大,就意味著越多的slave因為replication而不可用。可以通過將這個值設為1來保證每次只有一個slave處於不能處理命令請求的狀態。
#sentinel parallel-syncs <master-name> <numslaves>

sentinel parallel-syncs master 1

#故障轉移的超時時間failover-timeout可以用在以下這些方面:
#1.同一個sentinel對同一個master兩次failover之間的間隔時間。
#2.當一個slave從一個錯誤的master那裡同步資料開始計算時間。直到slave被糾正為向正確的master那裡同步資料時。
#3.當想要取消一個正在進行的failover所需要的時間。
#4.當進行failover時,設定所有slaves指向新的master所需的最大時間。不過,即使過了這個超時,slaves依然會被正確設定為指向master,但是就不按parallel-syncs所設定的規則來了#預設三分鐘
#sentinel failover-timeout <master-name> <milliseconds>
sentinelf ailover-timeout master1 80000
docker run -it --name redis-sentinel2639  -v /Users/yujiale/docker/redis/conf/sentinel6379.conf:/etc/redis/sentinel.conf -v /Users/yujiale/docker/redis/data26379:/data --network localNetwork --ip 172.172.0.16 -d redis:6.2.6 redis-sentinel /etc/redis/sentinel.conf

3、啟動sentinel哨兵範例

#啟動redis-master和redis-slaver

在redis-master目錄下  ./redis-server redis.conf
在redis-slaver1目錄下 ./redis-server redis.conf
在redis-slaver2目錄下 ./redis-server redis.conf

#啟動redis-sentinel

在redis-sentinel1目錄下 ./redis-sentinel sentinel.conf
在redis-sentinel2目錄下 ./redis-sentinel sentinel.conf
在redis-sentinel3目錄下 ./redis-sentinel sentinel.conf

4、檢視啟動狀態

2.png

執行流程

1、啟動並初始化Sentinel

Sentinel是一個特殊的Redis伺服器不會進行持久化

Sentinel範例啟動後每個Sentinel會建立2個連向主伺服器的網路連線

  • 命令連線:用於向主伺服器傳送命令,並接收響應

  • 訂閱連線:用於訂閱主伺服器的—sentinel—:hello頻道

3.png

2、獲取主Master資訊

Sentinel預設每10s一次,向被監控的主伺服器傳送info命令,獲取主伺服器和其下屬從伺服器的資訊。

4.png

3、獲取從salve資訊

當Sentinel發現主伺服器有新的從伺服器出現時,Sentinel還會向從伺服器建立命令連線和訂閱連線。

在命令連線建立之後,Sentinel還是預設10s一次,向從伺服器傳送info命令,並記錄從伺服器的資訊。

5.png

6.png

4、以訂閱的方式向主伺服器和從伺服器傳送訊息

預設情況下,Sentinel每2s一次,向所有被監視的主伺服器和從伺服器所訂閱的—sentinel—:hello頻道上傳送訊息,訊息中會攜帶Sentinel自身的資訊和主伺服器的資訊。

5、接收來自主伺服器和從伺服器的頻道資訊

當Sentinel與主伺服器或者從伺服器建立起訂閱連線之後,Sentinel就會通過訂閱連線,向伺服器傳送以下命令

subscribe—sentinel—:hello

Sentinel彼此之間只建立命令連線,而不建立訂閱連線,因為Sentinel通過訂閱主伺服器或從伺服器,就可以感知到新的Sentinel的加入,而一旦新Sentinel加入後,相互感知的Sentinel通過命令連線來通訊就可以了。

6、檢測主觀下線狀態

Sentinel每秒一次向所有與它建立了命令連線的範例(主伺服器、從伺服器和其他Sentinel)傳送PING命令範例在down-after-milliseconds毫秒內返回無效回覆(除了+PONG、-LOADING、-MASTERDOWN外)範例在down-after-milliseconds毫秒內無回覆(超時)Sentinel就會認為該範例主觀下線(SDown)

7、檢查客觀下線狀態

當一個Sentinel將一個主伺服器判斷為主觀下線後

Sentinel會向同時監控這個主伺服器的所有其他Sentinel傳送查詢命令

主機的

SENTINEL is-master-down-by-addr <ip> <port> <current_epoch> <runid>

其他Sentinel回覆

<down_state> <leader_runid> <leader_epoch>

判斷它們是否也認為主伺服器下線。如果達到Sentinel設定中的quorum數量的Sentinel範例都判斷主伺服器為主觀下線,則該主伺服器就會被判定為客觀下線(ODown)。

8、選舉Leader Sentinel

當一個主伺服器被判定為客觀下線後,監視這個主伺服器的所有Sentinel會通過選舉演演算法(raft),選出一個Leader Sentinel去執行failover(故障轉移)操作。

哨兵選舉

Raft

Raft協定是用來解決分散式系統一致性問題的協定。

Raft協定描述的節點共有三種狀態:Leader, Follower, Candidate。

term:Raft協定將時間切分為一個個的Term(任期),可以認為是一種「邏輯時間」。

選舉流程

Raft採用心跳機制觸發Leader選舉

  • 系統啟動後,全部節點初始化為Follower,term為0。

  • 節點如果收到了RequestVote或者AppendEntries,就會保持自己的Follower身份

  • 節點如果一段時間內沒收到AppendEntries訊息,在該節點的超時時間內還沒發現Leader,Follower就會轉換成Candidate,自己開始競選Leader。

    • 一旦轉化為Candidate,該節點立即開始下面幾件事情:

      • 增加自己的term。
      • 啟動一個新的定時器。
      • 給自己投一票。
      • 向所有其他節點傳送RequestVote,並等待其他節點的回覆。
  • 如果在計時器超時前,節點收到多數節點的同意投票,就轉換成Leader。同時向所有其他節點傳送AppendEntries,告知自己成為了Leader。

  • 每個節點在一個term內只能投一票,採取先到先得的策略,Candidate前面說到已經投給了自己,Follower會投給第一個收到RequestVote的節點。

  • Raft協定的定時器採取隨機超時時間,這是選舉Leader的關鍵。

  • 在同一個term內,先轉為Candidate的節點會先發起投票,從而獲得多數票。

Sentinel的leader選舉流程

  • 1、某Sentinel認定master客觀下線後,該Sentinel會先看看自己有沒有投過票,如果自己已經投過票給其他Sentinel了,在一定時間內自己就不會成為Leader。

  • 2、如果該Sentinel還沒投過票,那麼它就成為Candidate。

  • 3、Sentinel需要完成幾件事情:

    • 更新故障轉移狀態為start
    • 當前epoch加1,相當於進入一個新term,在Sentinel中epoch就是Raft協定中的term。
    • 向其他節點傳送is-master-down-by-addr命令請求投票。命令會帶上自己的epoch。
    • 給自己投一票(leader、leader_epoch)
  • 4、當其它哨兵收到此命令時,可以同意或者拒絕它成為領導者;(通過判斷epoch)

  • 5、Candidate會不斷的統計自己的票數,直到他發現認同他成為Leader的票數超過一半而且超過它設定的quorum,這時它就成為了Leader。

  • 6、其他Sentinel等待Leader從slave選出master後,檢測到新的master正常工作後,就會去掉客觀下線的標識。

故障轉移

當選舉出Leader Sentinel後,Leader Sentinel會對下線的主伺服器執行故障轉移操作

  • 1.它會將失效Master的其中一個Slave升級為新的Master,並讓失效Master的其他Slave改為複製新的Master;

  • 2.當用戶端試圖連線失效的Master時,叢集也會向用戶端返回新Master的地址,使得叢集可以使用現在的Master替換失效Master。

  • 3.Master和Slave伺服器切換後,Master的redis.conf、Slave的redis.conf和sentinel.conf的組態檔的內容都會發生相應的改變,即,Master主伺服器的redis.conf組態檔中會多一行replicaof的設定,sentinel.conf的監控目標會隨之調換。

主伺服器的選擇

  • 1.過濾掉主觀下線的節點
  • 2.選擇slave-priority最高的節點,如果由則返回沒有就繼續選擇
  • 3.選擇出複製偏移量最大的系節點,因為複製偏移量越大則資料複製的越完整,如果由就返回了,沒有就繼續
  • 4.選擇run_id最小的節點,因為run_id越小說明重新啟動次數越少

更多程式設計相關知識,請存取:!!

以上就是解析Redis中的哨兵模式,聊聊搭建和執行流程的詳細內容,更多請關注TW511.COM其它相關文章!