Redis哨兵

Redis Sentinel

Redis哨兵為Redis提供高可用。這就意味着你用哨兵可以創建一個Redis部署，在沒有人為干預的情況下抵抗某些失敗。（PS：自動故障轉移）

Redis哨兵還提供其他的附件任務，比如監控，通知，以及作為客戶端的配置提供者。

• Monitoring（監視） ： 哨兵會不斷地檢查master和slave實例是否按照預期的那樣工作
• Notification（通知） ： 哨兵可以通過API的方式來通知管理員（另一台計算機程序），告訴它其中一個被監視的Redis實例出了問題
• Automatic failover（自動故障轉移） ： 如果一個master沒有如期望的那樣工作，哨兵可以開始一個故障轉移處理，處理的結果時一個slave被提升為master，其余的slave將用這個新master重新配置，使用這個Redis服務器的應用程序會被通知在連接時使用新的地址。
• Configuration provider（配置提供者） ： 哨兵充當客戶端服務發現的權威來源：為了對給定的服務請求作出響應，客戶端連接到哨兵以獲得當前master的地址。如果發生故障轉移，前哨將報告新地址。

哨兵的分布式特性

Redis哨兵是一個分布式系統：

哨兵自身被設計為在一個配置中運行，其中有多個Sentinel進程協同工作。

多個哨兵進程協同工作的優勢在於：

1. 當多個哨兵都同意且一致認為給定的master不可用時才會執行失敗檢測。這降低了誤報的概率。
2. 即使不是所有哨兵進程都正常工作（PS：個別哨兵不能正常工作）的情況下，仍然會使得系統對故障有較強的抵抗力。

獲得哨兵

當前版本的哨兵被叫做“Sentinel 2”。它是用更強大和更簡單的預測算法重寫最初的Sentinel實現。

運行哨兵

redis-sentinel /path/to/sentinel.conf

或者

redis-server /path/to/sentinel.conf --sentinel

這兩種方式是一樣的

當運行哨兵時，必須使用一個配置文件，因為系統將會使用這個文件來保存當前狀態，以便在重啟的時候開業重新加載。如果沒有提供配置文件，或者配置文件路徑不可寫，哨兵將拒絕啟動。

默認情況下，哨兵會監聽TCP端口26379，因此，為了讓哨兵正常工作，服務器的26379端口必須是開放的，以便可以接收到來自其它哨兵實例的IP的連接。否則，哨兵就不能說話，也不能同意，故障轉移也永遠不會執行。（PS：意思是，哨兵之間用26379端口進行通信，如果不開放這個端口，其它哨兵就無法與它通信，它也不同同意其它哨兵）

部署哨兵之前要了解的基本知識：

1、對於一個健壯的部署，你需要至少3個哨兵實例

2、這三個哨兵應該被放置到相對獨立的計算機或者虛擬機上（PS：獨立失敗，意思是一個失敗了對其它的沒用影響）

3、Sentinel + Redis分布式系統不能保證在故障期間已經確認的寫操作被保留，因為Redis使用異步復制。

4、你的Redis客戶端需要支持哨兵

5、如果你在開發環境（甚至是生產環境）沒用經過一次又一次嚴格的測試，那么沒用任何HA是安全的。可能你有一個錯誤的配置，但是一時半會兒看不出什么問題來，有可能過來很久以后這個錯誤配置導致的問題才會變得明顯起來。（PS：意思是，上線前要嚴格測試，因為你的生產環境上並不是只有redis，有可能其它的隱患因素，比如防火牆什么的。。。）

6、哨兵、Docker，或者其它NAT或端口映射，這些混在一起要特別小心

配置哨兵

配置文件 sentinel.conf

一個典型的，最小最簡潔的配置如下：

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1

sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 180000
sentinel parallel-syncs resque 5

你只需要指定要監視的masters，並且給它們（PS：指的是被監視的master）每一個（也許它們有許多slaves）指定一個唯一的名稱。不需要指定slaves，哨兵會自動發現它們。哨兵將自動更新配置，向配置文件中添加一些關於slaves的信息（為了在重啟的時候保留這些信息）。每次故障轉移期間一個slave被提升為master，以及每次發現一個新的哨兵時，都會重寫配置文件。

上面的配置示例中，監視兩組Redis實例，每一組的都由一個master和未知數量的slaves。一個實例叫mymaster，另一個叫resque。

sentinel monitor 語句的格式如下：

sentinel monitor <master-group-name> <ip> <port> <quorum>

第一行是用來告訴Redis監視一個叫“mymaster”的master，它的地址是127.0.0.1，端口是6379，法定人數是2。

關於 quorum 參數：

1、quorum 是一個數字，代表需要有多少個哨兵同意給定的master不可達這個事實，為了真正標記這個slave失敗，並且如果可能的話最終啟動一個故障轉移

2、quorum 只用於檢測失敗。為了真的執行一個故障轉移，其中一個哨兵需要被選舉成為leader，然后由這個leader來執行故障轉移。而且，只有在哨兵中的大多數參與投票選舉才算是有效。

如果你有5個哨兵，對於給定master的法定人數是2，那么將會發生：

1、如果兩個哨兵都同意並且一致認為master不可訪問，那么其中一個將嘗試啟動一個故障轉移

2、如果至少有3個哨兵正常工作且相互可以正常通信，那么故障轉移將會被授權，並真正開始執行

也就是說，如果哨兵中的大多數相互之間都無法通信，那么故障轉移便從來都不會發生。

（畫外音：上面這段話的意思是，只有當至少有法定人數個哨兵認為某個master不可到達的時候，才會嘗試啟動故障轉移，但是最后是否真的執行要看本次投票是否有效，只有當大多數哨兵正常工作時投票才算有效。

也就是說要執行故障轉移有兩個條件：第一、大多數的哨兵工作正常；第二、至少法定人數個哨兵一致認為master不可訪問）

其它哨兵選項

其它的選項大多數都是這樣的格式：

sentinel <option_name> <master_name> <option_value>

1、down-after-milliseconds 參數是一個毫秒時間，表示多少毫秒沒有回復則認為下線（要么是沒有收到ping回復，要么是回復錯誤）

2、parallel-syncs 參數表示在一個故障轉移后新的master需要配置的slave數量。這個數值越小，故障轉移完成的所需的時間越長。如果將從服務器配置為服務舊數據，您可能不希望所有從服務器同時與主服務器重新同步。對於slave來說，復制過程基本上不是阻塞的，但有時它會停止從master裝載大量數據。通過將此選項設置為1，可以確保一次只能訪問一個slave。

哨兵部署示例

參考

https://redis.io/topics/sentinel

其它相關

《Redis集群》