redis系列（6）：哨兵機制

1，爲何要講哨兵機制？

A，咱們學習了 redis 的主從複製，但若是說主節點出現問題不能提供服務， 須要人工從新把從節點設爲主節點，還要通知咱們的應用程序更新了主節點的地址，這 種處理方式不是科學的，耗時費事

B，同時主節點的寫能力是單機的，能力能限

C，並且主節點是單機的，存儲能力也有限

其中 2，3 的問題在後面 redis 集羣課會講，第 1 個問題咱們用哨兵機制來解決

2,主從故障如何故障轉移(不知足高可用)：

A，主節點(master)故障，從節點 slave-1 端執行 slaveof no one 後變成新主節點

B，其它的節點成爲新主節點的從節點，並重新節點複製數據

3，哨兵機制(sentinel)的高可用：

A，原理：當主節點出現故障時，由 redis sentinel 自動完成故障發現和轉移，並 通知應用方，實現高可用性。

 

其實整個過程只須要一個哨兵節點來完成，首先使用 Raft 算法（感興趣的同窗能夠查一下， 其實就是個選舉算法）實現選舉機制，選出一個哨兵節點來完成轉移和通知

哨兵有三個定時監控任務完成對各節點的發現和監控：

任務 1，每一個哨兵節點每 10 秒會向主節點和從節點發送 info 命令獲取最拓撲結構圖，哨 兵配置時只要配置對主節點的監控便可，經過向主節點發送 info，獲取從節點的信息，並當 有新的從節點加入時能夠立刻感知到

 

任務 2，每一個哨兵節點每隔 2 秒會向 redis 數據節點的指定頻道上發送該哨兵節點對於主 節點的判斷以及當前哨兵節點的信息，同時每一個哨兵節點也會訂閱該頻道，來了解其它哨兵 節點的信息及對主節點的判斷，其實就是經過消息 publish 和 subscribe 來完成

任務 3，每隔 1 秒每一個哨兵會向主節點、從節點及其他哨兵節點發送一次 ping 命令作一次 心跳檢測，這個也是哨兵用來判斷節點是否正常的重要依據

主觀下線和客觀下線：

主觀下線：剛我知道知道哨兵節點每隔 1 秒對主節點和從節點、其它哨兵節點發送 ping 作心跳檢測，當這些心跳檢測時間超過 down-after-milliseconds 時，哨兵節點則認爲該節點 錯誤或下線，這叫主觀下線；這可能會存在錯誤的判斷。

 

客觀下線：當主觀下線的節點是主節點時，此時該哨兵 3 節點會經過指令 sentinel is-masterdown-by-addr 尋求其它哨兵節點對主節點的判斷，當超過 quorum（法定人數）個 數，此時哨兵節點則認爲該主節點確實有問題，這樣就客觀下線了，大部分哨兵節點都贊成 下線操做，也就說是客觀下線

 

領導者哨兵選舉流程：

a,每一個在線的哨兵節點均可以成爲領導者，當它確認（好比哨兵 3）主節點下線時，會 向其它哨兵發 is-master-down-by-addr 命令，徵求判斷並要求將本身設置爲領導者，由領導 者處理故障轉移；

b,當其它哨兵收到此命令時，能夠贊成或者拒絕它成爲領導者；

c,若是哨兵 3 發現本身在選舉的票數大於等於 num(sentinels)/2+1 時，將成爲領導者， 若是沒有超過，繼續選舉…………

4，故障轉移機制

A，由 Sentinel 節點按期監控發現主節點是否出現了故障 sentinel 會向 master 發送心跳 PING 來確認 master 是否存活，若是 master 在「必定 時間範圍」內不迴應 PONG 或者是回覆了一個錯誤消息，那麼這個 sentinel 會主觀地(單 方面地)認爲這個 master

B，當主節點出現故障，此時 3 個 Sentinel 節點共同選舉了 Sentinel3 節點爲領導， 負載處理主節點的故障轉移,

C，由 Sentinel3 領導者節點執行故障轉移，過程和主從複製同樣，可是自動執行

D，故障轉移後的 redis sentinel 的拓撲結構圖

5，哨兵機制－故障轉移詳細流程

A，過濾掉不健康的（下線或斷線），沒有回覆過哨兵 ping 響應的從節點

B，選擇 slave-priority 從節點優先級最高（redis.conf）

C，選擇複製偏移量最大，指複製最完整的從節點

5，如何安裝和部署 Reids Sentinel? 咱們以 3 個 Sentinel 節點、2 個從節點、1 個主節點爲例進行安裝部署

 

 

1，前提：先搭好一主兩從 redis 的主從複製，和以前複製搭建同樣，搭建方式以下：

A 主節點 6379 節點（/usr/local/bin/conf/redis6379.conf）： 修改 requirepass 12345678，註釋掉#bind 127.0.0.1

B 從節點 redis6380.conf 和 redis6381.conf: 修改 requirepass 12345678 ,註釋掉#bind 127.0.0.1, 加上 masterauth 12345678 ,加上 slaveof 127.0.0.1 6379

注意：當主從起來後，主節點可讀寫，從節點只可讀不可寫

2，redis sentinel 哨兵機制核心配置(也是 3 個節點)：

/usr/local/bin/conf/sentinel_26379.conf

/usr/local/bin/conf/sentinel_26380.conf

/usr/local/bin/conf/sentinel_26381.conf

將三個文件的端口改爲: 26379 26380 26381

而後：sentinel monitor mymaster 190.168.1.111 6379 2 //監聽主節點 6379

sentinel auth-pass mymaster 12345678

//鏈接主節點時的密碼 三個配置除端口外，其它同樣。

3，哨兵其它的配置：只要修改每一個 sentinel.conf 的這段配置便可：

sentinel monitor mymaster 192.168.1.10 6379 2

//監控主節點的 IP 地址端口，sentinel 監控的 master 的名字叫作 mymaster

2 表明，當集羣中有 2 個 sentinel 認爲 master 死了時，才能真正認爲該 master 已經不可用了

sentinel auth-pass mymaster 12345678 //sentinel 連主節點的密碼

sentinel config-epoch mymaster 2 //故障轉移時最多能夠有 2 從節點同時對新 主節點進行數據同步

sentinel leader-epoch mymaster 2 sentinel failover-timeout mymasterA 180000 //故障轉移超時時間 180s，

a,若是轉移超時失敗，下次轉移時時間爲以前的 2 倍；

b,從節點變主節點時，從節點執行 slaveof no one 命令一直失敗的話， 當時間超過 180S 時，則故障轉移失敗

c,從節點複製新主節點時間超過 180S 轉移失敗

sentinel down-after-milliseconds mymasterA 300000//sentinel 節點按期向主節點 ping 命令，當超過了 300S 時間後沒有回覆，可能就認定爲此主節點出現故障了…… sentinel parallel-syncs mymasterA 1 //故障轉移後，1 表明每一個從節點按順序排隊一個一個復 制主節點數據，若是爲 3，指 3 個從節點同時併發複製主節點數據，不會影響阻塞，但存在 網絡和 IO 開

4，啓動 sentinel 服務:

./redis-sentinel conf/sentinel_26379.conf &

./redis-sentinel conf/sentinel_26380.conf &

./redis-sentinel conf/sentinel_26381.conf &

關閉：./redis-cli -h 192.168.42.111 -p 26379 shutdown

5，測試：kill -9 6379 殺掉 6379 的 redis 服務

看日誌是分配 6380 仍是 6381 作爲主節點，當 6379 服務再啓動時，已變成從節點

假設 6380 升級爲主節點:進入 6380>info replication 能夠看到 role:master

打開 sentinel_26379.conf 等三個配置，sentinel monitor mymaster 127.0.0.1 6380 2

打開 redis6379.conf 等三個配置, slaveof 192.168.42.111 6380,也變成了 6380

注意：生產環境建議讓 redis Sentinel 部署到不一樣的物理機上。

重 要： sentinel monitor mymaster 192.168.42.111 6379 2 //切 記 將 IP 不 要 寫 成 127.0.0.1

否則使用 JedisSentinelPool 取 jedis 鏈接的時候會變成取 127.0.0.1 6379 的錯誤地址

注：咱們稍後要啓動四個 redis 實例，其中端口爲 6379 的 redis 設爲 master，其餘兩個設爲 slave 。因此 mymaster 後跟的是 master 的 ip 和端口，最後一個’2’表明只 要有 2 個 sentinel 認爲 master 下線，就認爲該 master 客觀下線，選舉產生新的 master。 一般最後一個參數不能多於啓動的 sentinel 實例數。

哨兵 sentinel 個數爲奇數，選舉嘛，奇數哨兵個才能選舉成功，通常建議 3

 

6，RedisSentinel 如何監控 2 個 redis 主節點呢？

sentinel monitor mymasterB 192.168.1.20 6379 2 ……與上面同樣…………。

 

7，部署建議：

a，sentinel 節點應部署在多臺物理機（線上環境）

b，至少三個且奇數個 sentinel 節點

c，經過以上咱們知道，3 個 sentinel 可同時監控一個主節點或多個主節點

監聽 N 個主節點較多時，若是 sentinel 出現異常，會對多個主節點有影響，同 時還會形成 sentinel 節點產生過多的網絡鏈接，

通常線上建議仍是， 3 個 sentinel 監聽一個主節點

8，sentinel 哨兵的 API

命令：redis-cli -p 26379 //進入哨兵的命令模式，使用 redis-cli 進入

26379>sentinel masters 或 sentinel master mymaster //查看 redis 主節點相關信息

26379>sentinel slaves mymaster //查看從節點狀態與相關信息

26379>sentinel sentinels mymaster //查 sentinel 節點集合信息(不包括當前 26379)

26379>sentinel failover mymaster //對主節點強制故障轉移，沒和其它節點協商

9，客戶端鏈接（redis-sentinel 例子工程）

遠程客戶端鏈接時，要打開 protected-mode no

./redis-cli -p 26380 shutdown //關閉

在使用工程 redis-sentinel，調用 jedis 查詢的流程以下：

1，將三個 sentinel 的 IP 和地址加入 JedisSentinelPool

2，根據 IP 和地址建立 JedisSentinelPool 池對象

3，在這個對象建立完後，此時該對象已把 redis 的主節點 （ 此 時 sentinel monitor mymaster 必 須 寫 成 192.168.42.111 6379 2 ， 不 能 爲 127.0.0.1，否則查詢出來的主節點的 IP 在客戶端就變成了 127.0.0.1，拿不到鏈接了） 查詢出來了，當客戶準備發起查詢請求時，調用 pool.getResource()借用一個 jedis 對象， 內容包括主節點的 IP 和端口；

4，將獲得 jedis 對象後，可執行 jedis.get(「age」)指令了……