上個篇章，我們搭建了docker的哨兵集群的代碼實現和部分功能節點的創建以及五條必須掌握的配置命令，本節篇章主要來講哨兵集群Sentinel的原理。

1、哨兵Sentinel的原理：

通過上個篇章的梳理講解哨兵Sentinel的處理機制，我們不難發現主要是分為三個步驟：

  • 檢測問題：主要是三個定時任務，這三個內部的執行任務可以保證Master主節點出現問題後馬上讓Sentinel節點知道。

首先了解下內部Sentinel節點會執行以下三個定時任務：

1、每10秒每個哨兵Sentinel對Master和Slave執行一次Info Replication：

Redis Sentinel 可以對Redis節點做失敗判斷和故障轉移，在Redis內部有三個定時任務作為基礎，來Info
Replication 發現從節點Slave來確認主從關係

2、每2秒每個哨兵Sentinel通過Master節點的channel交換信息（pub/sub）

這個定時任務如同發布訂閱，哨兵Sentinel節點會對主從關係進行判斷，通過_sentinel_:hello頻道進行交互
。了解主從關係可以幫助更好地實現自動化操作Redis.然後Sentinel會告知系統信息給其他哨兵Sentinel節點
，就像握手，協議達成一致，並且哨兵Sentinel之間能相互感應。

3、每1秒每個哨兵Sentinel對其他Sentinel和Redis執行ping

失敗判定的依據，對每個節點和其他Sentinel進行心跳檢測。

  • 發現問題：主要是了解主管上線和客觀下線，當有一台哨兵節點Sentinel發現問題時，它就會主觀上對它進行下線，當有多個哨兵Sentinel都發現有問題出現時就會讓它客觀下線。

這裡我們先回顧下上節課所見的必須掌握的五個配置的其中兩個：
sentinel monitor redis-master IP POST NUM
sentinel down-after-millseconds redis-master ms
哨兵Sentinel會ping每個節點，如果超過 ms 毫秒，依然沒有應答回復的話，做下線的判定
主觀下線：
每個哨兵Sentinel節點對Redis節點失敗的主觀記錄，這其中只是因為，該節點在 ms 毫秒內沒有接收到Redis
的回復就會發起主觀下線【主觀下線的依據是苛刻的，也就說證據不足不能單純的認為某一台哨兵Sentinel沒有
收到回復就判斷Redis故障】
客觀下線：
當有 NUM 個哨兵Sentinel節點都在 ms 毫秒內沒有收到Redis的回復就會判定Redis已故障，並開始執行後面
的步驟發起故障轉移。

  • 解決問題：主要是領導者選舉，如何在哨兵Sentinel內部多台節點做領導者選舉，選出一個領導者，並實現故障轉移。

1、每個主觀下線的哨兵Sentinel節點，會向其他的Sentinel節點發起命令，要求將自己設置為領導者。
2、收到命令的Sentinel節點，如果「沒有同意通過」其他節點發送命令，那麼就會同意請求，反之拒絕
3、如果主觀下線的哨兵Sentinel節點發現了自己的投票數超過半數同時也超過了sentinel monitor
redis-master IP POST NUM 中的 NUM 數就會成為領導者
4、開始進行故障轉移

講到這裡我們應該都已明白Sentinel的領導者的選舉過程，那如何從從節點Slave選舉為主節點的呢？

Redis的內部其實就是就有一個優先順序的配置的，在配置文件中 slave-priority，這個參數是 Salve 節點的優先順序配置。如果存在則返回，如果不存在則繼續。當上面這個優先順序不滿足的時候，Redis 還會選擇複製偏移量最大的 Slave節點，如果存在則返回，如果不存在則繼續。之所以選擇偏移量最大，這是因為偏移量越小，和 Master 的數據越不接近，現在 Master掛掉了，說明這個偏移量小的機器數據也可能存在問題，這就是為什麼要選偏移量最大的 Slave 的原因。如果發現偏移量都一樣，這個時候 Redis 會默認選擇 runid 最小的節點。

2、生成環境中的部署技巧：

  • Sentinel 節點不應該部署在一台物理「機器」上。

這裡特意強調物理機是因為一台物理機做成了若干虛擬機或者現今比較流行的容器，它們雖然有不同的 IP 地址，但實際上它們都是同一台物理機，同一台物理機意味著如果這台機器有什麼硬體故障，所有的虛擬機都會受到影響，為了實現 Sentinel 節點集合真正的高可用，請勿將 Sentinel 節點部署在同一台物理機器上。

  • 部署至少三個且奇數個的 Sentinel 節點。

3個以上是通過增加 Sentinel 節點的個數提高對於故障判定的準確性，因為領導者選舉需要至少一半加1個節點，奇數個節點可以在滿足該條件的基礎上節省一個節點。

3、哨兵節點詳解：

進入哨兵節點客戶端後執行SENTINEL masters命令「顯示被監控的所有master以及它們的狀態.」
127.0.0.1:26379> SENTINEL masters
1) 1) "name"
2) "mymaster" //被監控主節點的名稱
3) "ip"
4) "172.60.0.4" //被監控主節點的ip
5) "port"
6) "6379" //被監控主節點的埠號
7) "runid"
8) "8aaecf3f6a197932b28ed89d2d3936636814c5fe" //被監控主節點的runid[運行]
9) "flags"
10) "master"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
17) "last-ok-ping-reply"
18) "1017"
19) "last-ping-reply"
20) "1017"
21) "down-after-milliseconds"
22) "30000" //監控主節點不可達超時時間
23) "info-refresh"
24) "2704"
25) "role-reported"
26) "master"
27) "role-reported-time"
28) "386306494"
29) "config-epoch" //epochs的配置
30) "1"
31) "num-slaves"
32) "2" //發現從節點個數
33) "num-other-sentinels" //發現其他哨兵節點個數
34) "2"
35) "quorum"
36) "2" //需要同意主節點不可用的Sentinels的數量
37) "failover-timeout"
38) "180000" //延遲時間
39) "parallel-syncs" //複製轉移數量
40) "1"
執行SENTINEL slaves mymaster查看從節點的信息：【你會看到有兩個從節點的信息】
127.0.0.1:26379> SENTINEL slaves mymaster
1) 1) "name"
2) "172.60.0.3:6379"
3) "ip"
4) "172.60.0.3"
5) "port"
6) "6379"
7) "runid"
8) "e8510d9e9811dec10af1d88153db129284d2e264"
9) "flags"
10) "slave"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
17) "last-ok-ping-reply"
18) "981"
19) "last-ping-reply"
20) "981"
21) "down-after-milliseconds"
22) "30000"
23) "info-refresh"
24) "8170"
25) "role-reported"
26) "slave"
27) "role-reported-time"
28) "388149449"
29) "master-link-down-time"
30) "0"
31) "master-link-status"
32) "ok"
33) "master-host"
34) "172.60.0.4"
35) "master-port"
36) "6379"
37) "slave-priority"
38) "100"
39) "slave-repl-offset"
40) "76787185"
2) 1) "name"
2) "172.60.0.2:6379"
3) "ip"
4) "172.60.0.2"
5) "port"
6) "6379"
7) "runid"
8) "948b5d23e83648c586a5d3056c0b850a9c517887"
9) "flags"
10) "slave"
11) "link-pending-commands"
12) "0"
13) "link-refcount"
14) "1"
15) "last-ping-sent"
16) "0"
17) "last-ok-ping-reply"
18) "981"
19) "last-ping-reply"
20) "981"
21) "down-after-milliseconds"
22) "30000"
23) "info-refresh"
24) "8170"
25) "role-reported"
26) "slave"
27) "role-reported-time"
28) "387258992"
29) "master-link-down-time"
30) "0"
31) "master-link-status"
32) "ok"
33) "master-host"
34) "172.60.0.4"
35) "master-port"
36) "6379"
37) "slave-priority"
38) "100"
39) "slave-repl-offset"
40) "76787185"
執行SENTINEL get-master-addr-by-name mymaster 查看主節點的信息和埠號
127.0.0.1:26379> SENTINEL get-master-addr-by-name mymaster
1) "172.60.0.4"
2) "6379"
執行SENTINEL failover mymaster 強制切換主節點不需要得到其他Sentinel
127.0.0.1:26379> SENTINEL failover mymaster
OK
當我們再次執行查詢主節點信息時就會發現主節點已經切換了如下圖：

後面還有幾個命令這裡就不在一一實現了，有興趣的話自己修改配置文件執行命令運行看看結果。到這裡我們的哨兵集群的搭建和原理也就都講完了。普通的主從複製和哨兵集群我們講到這，下一篇章我們開始講項目實踐案例一共是兩個案例1：用php實現輪詢分流 2：高並發搶單。

今天的篇章就到這裡，覺得還不錯的話，請關注我的專欄和我的主頁，謝謝。

推薦閱讀：

相关文章