解析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。
一旦轉化為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其它相關文章！