模式二：哨兵模式

上一篇問講述了redis集群的主從模式，這一篇我們講述哨兵模式。

Redis 的 Sentinel 系統用于管理多個 Redis 服務器（instance）， 該系統執行以下三個任務：

• 監控（Monitoring）： Sentinel 會不斷地檢查你的主服務器和從服務器是否運作正常。
• 提醒（Notification）： 當被監控的某個 Redis 服務器出現問題時， Sentinel 可以通過 API 向管理員或者其他應用程序發送通知。
• 自動故障遷移（Automatic failover）： 當一個主服務器不能正常工作時， Sentinel 會開始一次自動故障遷移操作， 它會將失效主服務器的其中一個從服務器升級為新的主服務器， 并讓失效主服務器的其他從服務器改為復制新的主服務器； 當客戶端試圖連接失效的主服務器時， 集群也會向客戶端返回新主服務器的地址， 使得集群可以使用新主服務器代替失效服務器。

這個就相比于主從系統更加的靈活化，主從系統一旦主節點崩潰，整個系統寫的功能就喪失。

Redis Sentinel 是一個分布式系統， 你可以在一個架構中運行多個 Sentinel 進程（progress）， 這些進程使用流言協議（gossip protocols)來接收關于主服務器是否下線的信息， 并使用投票協議（agreement protocols）來決定是否執行自動故障遷移， 以及選擇哪個從服務器作為新的主服務器。

哨兵進程工作方式：

每個Sentinel（哨兵）進程以每秒鐘一次的頻率向整個集群中的Master主服務器，Slave從服務器以及其他Sentinel（哨兵）進程發送一個 PING 命令。

如果一個實例（instance）距離最后一次有效回復 PING 命令的時間超過 down-after-milliseconds 選項所指定的值， 那么這個實例會被 Sentinel 標記為主觀下線。 一個有效回復可以是： +PONG 、 -LOADING 或者 -MASTERDOWN 。

如果一個主服務器被標記為主觀下線， 那么正在監視這個主服務器的所有 Sentinel 要以每秒一次的頻率確認主服務器的確進入了主觀下線狀態。

如果一個主服務器被標記為主觀下線， 并且有足夠數量的 Sentinel （至少要達到配置文件指定的數量）在指定的時間范圍內同意這一判斷， 那么這個主服務器被標記為客觀下線。

在一般情況下， 每個 Sentinel 會以每 10 秒一次的頻率向它已知的所有主服務器和從服務器發送 INFO 命令。 當一個主服務器被 Sentinel 標記為客觀下線時， Sentinel 向下線主服務器的所有從服務器發送 INFO 命令的頻率會從 10 秒一次改為每秒一次。

只要一個 Sentinel 發現某個主服務器進入了客觀下線狀態， 這個 Sentinel 就可能會被其他 Sentinel 推選出， 并對失效的主服務器執行自動故障遷移操作。

當沒有足夠數量的 Sentinel 同意主服務器已經下線， 主服務器的客觀下線狀態就會被移除。 當主服務器重新向 Sentinel 的 PING 命令返回有效回復時， 主服務器的主觀下線狀態就會被移除。

主觀下線以及客觀下線解釋：

主觀下線（Subjectively Down， 簡稱 SDOWN）指的是單個 Sentinel 實例對服務器做出的下線判斷。

客觀下線（Objectively Down， 簡稱 ODOWN）指的是多個 Sentinel 實例在對同一個服務器做出 SDOWN 判斷， 并且通過 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服務器下線判斷。

從主觀下線狀態切換到客觀下線狀態并沒有使用嚴格的法定人數算法（strong quorum algorithm）， 而是使用了流言協議： 如果 Sentinel 在給定的時間范圍內， 從其他 Sentinel 那里接收到了足夠數量的主服務器下線報告， 那么 Sentinel 就會將主服務器的狀態從主觀下線改變為客觀下線。 如果之后其他 Sentinel 不再報告主服務器已下線， 那么客觀下線狀態就會被移除。

客觀下線條件只適用于主服務器： 對于任何其他類型的 Redis 實例， Sentinel 在將它們判斷為下線前不需要進行協商， 所以從服務器或者其他 Sentinel 永遠不會達到客觀下線條件。

Sentinel是如何發現其他的Sentinel 和從服務器的？

每個 Sentinel 會以每兩秒一次的頻率， 通過發布與訂閱功能， 向被它監視的所有主服務器和從服務器的 sentinel:hello 頻道發送一條信息， 信息中包含了 Sentinel 的 IP 地址、端口號和運行 ID （runid）。

每個 Sentinel 都訂閱了被它監視的所有主服務器和從服務器的 sentinel:hello 頻道， 查找之前未出現過的 sentinel （looking for unknown sentinels）。 當一個 Sentinel 發現一個新的 Sentinel 時， 它會將新的 Sentinel 添加到一個列表中， 這個列表保存了 Sentinel 已知的， 監視同一個主服務器的所有其他 Sentinel 。

Sentinel 發送的信息中還包括完整的主服務器當前配置（configuration）。 如果一個 Sentinel 包含的主服務器配置比另一個 Sentinel 發送的配置要舊， 那么這個 Sentinel 會立即升級到新配置上。

在將一個新 Sentinel 添加到監視主服務器的列表上面之前， Sentinel 會先檢查列表中是否已經包含了和要添加的 Sentinel 擁有相同運行 ID 或者相同地址（包括 IP 地址和端口號）的 Sentinel ， 如果是的話， Sentinel 會先移除列表中已有的那些擁有相同運行 ID 或者相同地址的 Sentinel ， 然后再添加新 Sentinel 。

從上述我們可以看出哨兵之間的互相發現以及發現從服務器，都是通過發布訂閱的功能來實現的，既我們之前所講的redis的發布訂閱。當有一個新的哨兵加入進來就會向頻道中發送自己的信息，其他所有訂閱的哨兵會通過消費信息添加新的哨兵信息。

自動故障遷移過程：

• 發現主服務器已經進入客觀下線狀態。
• 在失效主服務器屬下的從服務器當中， 那些被標記為主觀下線、已斷線、或者最后一次回復 PING 命令的時間大于五秒鐘的從服務器都會被淘汰。
• 在失效主服務器屬下的從服務器當中， 那些與失效主服務器連接斷開的時長超過 down-after 選項指定的時長十倍的從服務器都會被淘汰。
• 在經歷了以上兩輪淘汰之后剩下來的從服務器中， 我們選出復制偏移量（replication offset）最大的那個從服務器作為新的主服務器； 如果復制偏移量不可用， 或者從服務器的復制偏移量相同， 那么帶有最小運行 ID 的那個從服務器成為新的主服務器。
• 向被選中的從服務器發送 SLAVEOF NO ONE 命令，讓它轉變為主服務器。
• 通過發布與訂閱功能， 將更新后的配置傳播給所有其他 Sentinel ， 其他 Sentinel 對它們自己的配置進行更新。
• 向已下線主服務器的從服務器發送 SLAVEOF 命令， 讓它們去復制新的主服務器。
• 當所有從服務器都已經開始復制新的主服務器時， 領頭 Sentinel 終止這次故障遷移操作。

上述簡單講述了： - Sentinel是如何發現其他的Sentinel 以及從服務器 - Sentinel是如何判斷主服務器主觀下線以及客觀下線的 - Sentinel是如何自動故障遷移的

下面我們將具體的搭建哨兵模式

首先我們像搭建主從模式一樣，搭建出主從并啟動，如上一篇文章一樣，這里我們主節點為：6380端口，從節點為6381端口，如圖所示：

啟動主從后，6380redis文件中創建哨兵模式所需要的配置文件，需要啟動幾個哨兵就創建幾個配置文件,如圖：

配置文件內容如下:

如上就是我們需要的全部配置，現在我們開始啟動兩個哨兵。

啟動命令為 redis-service sentinel.conf --sentinel

首先啟動端口號為26379的哨兵，如圖：

啟動端口號為26380的哨兵，如圖：

此時我們查看主節點服務的模式也是哨兵模式。

并且我們可以看到兩個哨兵啟動成功后，兩個哨兵的配置文件也有所變化：

可以看到兩個配置文件都自動添加了從節點以及另一個哨兵的信息。

此時我們的redis哨兵模式就創建成功了，后面我們測試主節點斷開及主節點恢復的時候和java代碼結合演示。

我們要整合哨兵模式，首先要修改redis的配置文件。如下：

@Component @Slf4j public class JedisConfig {@Value("${spring.redis.host}")private String host;@Value("${spring.redis.port}")private int port;@Value("${spring.redis.timeout}")private int timeout;@Value("${spring.redis.pool.max-active}")private int maxActive;@Value("${spring.redis.pool.max-idle}")private int maxIdle;@Value("${spring.redis.pool.min-idle}")private int minIdle;@Value("${spring.redis.pool.max-wait}")private long maxWaitMillis;@Beanpublic JedisSentinelPool redisPoolFactory(){JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();jedisPoolConfig.setMaxIdle(maxIdle);jedisPoolConfig.setMaxWaitMillis(maxWaitMillis);jedisPoolConfig.setMaxTotal(maxActive);jedisPoolConfig.setMinIdle(minIdle);//此處配置的哨兵信息，切記不要配置主節點地址，這樣故障遷移的時候才能切換過來。Set<String> sentinels = new HashSet<String>(Arrays.asList("127.0.0.1:26379","127.0.0.1:26380")); // JedisPool jedisPool = new JedisPool(jedisPoolConfig,host,port,timeout,null);JedisSentinelPool jedisPool = new JedisSentinelPool("mymaster",sentinels,jedisPoolConfig);log.info("JedisPool注入成功！");log.info("redis地址：" + host + ":" + port);return jedisPool;}}

并將RedisClient中連接池修改：

//@Resource//private JedisPool jedisPool;@Resourceprivate JedisSentinelPool jedisPool;這個具體配置之前文章中有詳細內容

我們先測試一下哨兵模式是否連接正常

@Testpublic void setRedis() {try {redisClient.set("testSentinel5","aaaa");} catch (Exception e) {e.printStackTrace();}}

運行結果：

可以看到連接正常，那么我們現在將主節點關掉，測試一下故障遷移。

從上圖我們可以看出在6380主節點斷開后，6381從節點講過哨兵的故障遷移變為了主節點。

并且我們可以看到原先加在6381從節點redis.windows.conf配置文件中的slaveof配置以及自動刪除了，而且兩個哨兵中的主節點監控也由6380變為了6381.

我們再測試一下遷移后的寫入功能。

@Testpublic void setRedis() {try {redisClient.set("testSentinel6","aaaa");} catch (Exception e) {e.printStackTrace();}}

可以看出在主節點斷開后，集群的寫入查看功能正常。

接下來我們將6380恢復，看是否能夠重新連接入集群：

可以看到6380重新開啟后，自動變為從節點連接入集群，并在6380的redis.windows.conf的配置文件中自動加入了：

slaveof 10.66.205.85 6381

今天就寫到這里了，Redis的哨兵模式是以主從模式為基礎的，所以說，主從模式擁有的一些缺點，在哨兵模式下也具有。哨兵模式主要是監控Master主服務器的運行情況，當然也會監控Slave從服務器的運行情況，如果Master主服務器發生了故障，該模式可以保證Slave從服務器順利升級為Master主服務器繼續提供服務，以此提高系統的高可用性。雖然哨兵模式比主從模式提高了不少系統的高可用性，但是該模式不能水平擴容，不能動態的增、刪節點，這也是限制哨兵模式廣泛應用的主要原因。Redis也看到了這個情況，所在在Redis的3.x以后的版本提供了一個更加強大集群模式，那就是Cluster集群模式，這個模式也是我們下一篇文章的主題。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的down redis集群_Redis总结（十）redis集群-哨兵模式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。