Redis中的哨兵模式有什么用

這篇文章將為大家詳細講解有關Redis中的哨兵模式有什么用，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

基本介紹

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

• 由一個或多個sentinel實例組成sentinel集群可以監視一個或多個主服務器和多個從服務器。【相關推薦：Redis視頻教程】

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

• 圖解

哨兵模式搭建步驟

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、查看啟動狀態

執行流程

1、啟動并初始化Sentinel

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

Sentinel實例啟動后每個Sentinel會創建2個連向主服務器的網絡連接

• 命令連接：用于向主服務器發送命令，并接收響應

• 訂閱連接：用于訂閱主服務器的—sentinel—:hello頻道

2、獲取主Master信息

Sentinel默認每10s一次，向被監控的主服務器發送info命令，獲取主服務器和其下屬從服務器的信息。

3、獲取從salve信息

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

在命令連接建立之后，Sentinel還是默認10s一次，向從服務器發送info命令，并記錄從服務器的信息。

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。

• 增加自己的term。

• 啟動一個新的定時器。

• 給自己投一票。

• 向所有其他節點發送RequestVote，并等待其他節點的回復。

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

• 如果在計時器超時前，節點收到多數節點的同意投票，就轉換成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中的哨兵模式有什么用”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。