模式二：哨兵模式

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

Redis 的 Sentinel 系統(tǒng)用于管理多個(gè) Redis 服務(wù)器（instance）， 該系統(tǒng)執(zhí)行以下三個(gè)任務(wù)：

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

這個(gè)就相比于主從系統(tǒng)更加的靈活化，主從系統(tǒng)一旦主節(jié)點(diǎn)崩潰，整個(gè)系統(tǒng)寫(xiě)的功能就喪失。

Redis Sentinel 是一個(gè)分布式系統(tǒng)， 你可以在一個(gè)架構(gòu)中運(yùn)行多個(gè) Sentinel 進(jìn)程（progress）， 這些進(jìn)程使用流言協(xié)議（gossip protocols)來(lái)接收關(guān)于主服務(wù)器是否下線的信息， 并使用投票協(xié)議（agreement protocols）來(lái)決定是否執(zhí)行自動(dòng)故障遷移， 以及選擇哪個(gè)從服務(wù)器作為新的主服務(wù)器。

哨兵進(jìn)程工作方式：

每個(gè)Sentinel（哨兵）進(jìn)程以每秒鐘一次的頻率向整個(gè)集群中的Master主服務(wù)器，Slave從服務(wù)器以及其他Sentinel（哨兵）進(jìn)程發(fā)送一個(gè) PING 命令。

如果一個(gè)實(shí)例（instance）距離最后一次有效回復(fù) PING 命令的時(shí)間超過(guò) down-after-milliseconds 選項(xiàng)所指定的值， 那么這個(gè)實(shí)例會(huì)被 Sentinel 標(biāo)記為主觀下線。 一個(gè)有效回復(fù)可以是： +PONG 、 -LOADING 或者 -MASTERDOWN 。

如果一個(gè)主服務(wù)器被標(biāo)記為主觀下線， 那么正在監(jiān)視這個(gè)主服務(wù)器的所有 Sentinel 要以每秒一次的頻率確認(rèn)主服務(wù)器的確進(jìn)入了主觀下線狀態(tài)。

如果一個(gè)主服務(wù)器被標(biāo)記為主觀下線， 并且有足夠數(shù)量的 Sentinel （至少要達(dá)到配置文件指定的數(shù)量）在指定的時(shí)間范圍內(nèi)同意這一判斷， 那么這個(gè)主服務(wù)器被標(biāo)記為客觀下線。

在一般情況下， 每個(gè) Sentinel 會(huì)以每 10 秒一次的頻率向它已知的所有主服務(wù)器和從服務(wù)器發(fā)送 INFO 命令。 當(dāng)一個(gè)主服務(wù)器被 Sentinel 標(biāo)記為客觀下線時(shí)， Sentinel 向下線主服務(wù)器的所有從服務(wù)器發(fā)送 INFO 命令的頻率會(huì)從 10 秒一次改為每秒一次。

只要一個(gè) Sentinel 發(fā)現(xiàn)某個(gè)主服務(wù)器進(jìn)入了客觀下線狀態(tài)， 這個(gè) Sentinel 就可能會(huì)被其他 Sentinel 推選出， 并對(duì)失效的主服務(wù)器執(zhí)行自動(dòng)故障遷移操作。

當(dāng)沒(méi)有足夠數(shù)量的 Sentinel 同意主服務(wù)器已經(jīng)下線， 主服務(wù)器的客觀下線狀態(tài)就會(huì)被移除。 當(dāng)主服務(wù)器重新向 Sentinel 的 PING 命令返回有效回復(fù)時(shí)， 主服務(wù)器的主觀下線狀態(tài)就會(huì)被移除。

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

主觀下線（Subjectively Down， 簡(jiǎn)稱(chēng) SDOWN）指的是單個(gè) Sentinel 實(shí)例對(duì)服務(wù)器做出的下線判斷。

客觀下線（Objectively Down， 簡(jiǎn)稱(chēng) ODOWN）指的是多個(gè) Sentinel 實(shí)例在對(duì)同一個(gè)服務(wù)器做出 SDOWN 判斷， 并且通過(guò) SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服務(wù)器下線判斷。

從主觀下線狀態(tài)切換到客觀下線狀態(tài)并沒(méi)有使用嚴(yán)格的法定人數(shù)算法（strong quorum algorithm）， 而是使用了流言協(xié)議： 如果 Sentinel 在給定的時(shí)間范圍內(nèi)， 從其他 Sentinel 那里接收到了足夠數(shù)量的主服務(wù)器下線報(bào)告， 那么 Sentinel 就會(huì)將主服務(wù)器的狀態(tài)從主觀下線改變?yōu)榭陀^下線。 如果之后其他 Sentinel 不再報(bào)告主服務(wù)器已下線， 那么客觀下線狀態(tài)就會(huì)被移除。

客觀下線條件只適用于主服務(wù)器： 對(duì)于任何其他類(lèi)型的 Redis 實(shí)例， Sentinel 在將它們判斷為下線前不需要進(jìn)行協(xié)商， 所以從服務(wù)器或者其他 Sentinel 永遠(yuǎn)不會(huì)達(dá)到客觀下線條件。

Sentinel是如何發(fā)現(xiàn)其他的Sentinel 和從服務(wù)器的？

每個(gè) Sentinel 會(huì)以每?jī)擅胍淮蔚念l率， 通過(guò)發(fā)布與訂閱功能， 向被它監(jiān)視的所有主服務(wù)器和從服務(wù)器的 sentinel:hello 頻道發(fā)送一條信息， 信息中包含了 Sentinel 的 IP 地址、端口號(hào)和運(yùn)行 ID （runid）。

每個(gè) Sentinel 都訂閱了被它監(jiān)視的所有主服務(wù)器和從服務(wù)器的 sentinel:hello 頻道， 查找之前未出現(xiàn)過(guò)的 sentinel （looking for unknown sentinels）。 當(dāng)一個(gè) Sentinel 發(fā)現(xiàn)一個(gè)新的 Sentinel 時(shí)， 它會(huì)將新的 Sentinel 添加到一個(gè)列表中， 這個(gè)列表保存了 Sentinel 已知的， 監(jiān)視同一個(gè)主服務(wù)器的所有其他 Sentinel 。

Sentinel 發(fā)送的信息中還包括完整的主服務(wù)器當(dāng)前配置（configuration）。 如果一個(gè) Sentinel 包含的主服務(wù)器配置比另一個(gè) Sentinel 發(fā)送的配置要舊， 那么這個(gè) Sentinel 會(huì)立即升級(jí)到新配置上。

在將一個(gè)新 Sentinel 添加到監(jiān)視主服務(wù)器的列表上面之前， Sentinel 會(huì)先檢查列表中是否已經(jīng)包含了和要添加的 Sentinel 擁有相同運(yùn)行 ID 或者相同地址（包括 IP 地址和端口號(hào)）的 Sentinel ， 如果是的話， Sentinel 會(huì)先移除列表中已有的那些擁有相同運(yùn)行 ID 或者相同地址的 Sentinel ， 然后再添加新 Sentinel 。

從上述我們可以看出哨兵之間的互相發(fā)現(xiàn)以及發(fā)現(xiàn)從服務(wù)器，都是通過(guò)發(fā)布訂閱的功能來(lái)實(shí)現(xiàn)的，既我們之前所講的redis的發(fā)布訂閱。當(dāng)有一個(gè)新的哨兵加入進(jìn)來(lái)就會(huì)向頻道中發(fā)送自己的信息，其他所有訂閱的哨兵會(huì)通過(guò)消費(fèi)信息添加新的哨兵信息。

自動(dòng)故障遷移過(guò)程：

• 發(fā)現(xiàn)主服務(wù)器已經(jīng)進(jìn)入客觀下線狀態(tài)。
• 在失效主服務(wù)器屬下的從服務(wù)器當(dāng)中， 那些被標(biāo)記為主觀下線、已斷線、或者最后一次回復(fù) PING 命令的時(shí)間大于五秒鐘的從服務(wù)器都會(huì)被淘汰。
• 在失效主服務(wù)器屬下的從服務(wù)器當(dāng)中， 那些與失效主服務(wù)器連接斷開(kāi)的時(shí)長(zhǎng)超過(guò) down-after 選項(xiàng)指定的時(shí)長(zhǎng)十倍的從服務(wù)器都會(huì)被淘汰。
• 在經(jīng)歷了以上兩輪淘汰之后剩下來(lái)的從服務(wù)器中， 我們選出復(fù)制偏移量（replication offset）最大的那個(gè)從服務(wù)器作為新的主服務(wù)器； 如果復(fù)制偏移量不可用， 或者從服務(wù)器的復(fù)制偏移量相同， 那么帶有最小運(yùn)行 ID 的那個(gè)從服務(wù)器成為新的主服務(wù)器。
• 向被選中的從服務(wù)器發(fā)送 SLAVEOF NO ONE 命令，讓它轉(zhuǎn)變?yōu)橹鞣?wù)器。
• 通過(guò)發(fā)布與訂閱功能， 將更新后的配置傳播給所有其他 Sentinel ， 其他 Sentinel 對(duì)它們自己的配置進(jìn)行更新。
• 向已下線主服務(wù)器的從服務(wù)器發(fā)送 SLAVEOF 命令， 讓它們?nèi)?fù)制新的主服務(wù)器。
• 當(dāng)所有從服務(wù)器都已經(jīng)開(kāi)始復(fù)制新的主服務(wù)器時(shí)， 領(lǐng)頭 Sentinel 終止這次故障遷移操作。

上述簡(jiǎn)單講述了： - Sentinel是如何發(fā)現(xiàn)其他的Sentinel 以及從服務(wù)器 - Sentinel是如何判斷主服務(wù)器主觀下線以及客觀下線的 - Sentinel是如何自動(dòng)故障遷移的

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

首先我們像搭建主從模式一樣，搭建出主從并啟動(dòng)，如上一篇文章一樣，這里我們主節(jié)點(diǎn)為：6380端口，從節(jié)點(diǎn)為6381端口，如圖所示：

啟動(dòng)主從后，6380redis文件中創(chuàng)建哨兵模式所需要的配置文件，需要啟動(dòng)幾個(gè)哨兵就創(chuàng)建幾個(gè)配置文件,如圖：

配置文件內(nèi)容如下:

如上就是我們需要的全部配置，現(xiàn)在我們開(kāi)始啟動(dòng)兩個(gè)哨兵。

啟動(dòng)命令為 redis-service sentinel.conf --sentinel

首先啟動(dòng)端口號(hào)為26379的哨兵，如圖：

啟動(dòng)端口號(hào)為26380的哨兵，如圖：

此時(shí)我們查看主節(jié)點(diǎn)服務(wù)的模式也是哨兵模式。

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

可以看到兩個(gè)配置文件都自動(dòng)添加了從節(jié)點(diǎn)以及另一個(gè)哨兵的信息。

此時(shí)我們的redis哨兵模式就創(chuàng)建成功了，后面我們測(cè)試主節(jié)點(diǎn)斷開(kāi)及主節(jié)點(diǎn)恢復(fù)的時(shí)候和java代碼結(jié)合演示。

我們要整合哨兵模式，首先要修改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);//此處配置的哨兵信息，切記不要配置主節(jié)點(diǎn)地址，這樣故障遷移的時(shí)候才能切換過(guò)來(lái)。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;這個(gè)具體配置之前文章中有詳細(xì)內(nèi)容

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

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

運(yùn)行結(jié)果：

可以看到連接正常，那么我們現(xiàn)在將主節(jié)點(diǎn)關(guān)掉，測(cè)試一下故障遷移。

從上圖我們可以看出在6380主節(jié)點(diǎn)斷開(kāi)后，6381從節(jié)點(diǎn)講過(guò)哨兵的故障遷移變?yōu)榱酥鞴?jié)點(diǎn)。

并且我們可以看到原先加在6381從節(jié)點(diǎn)redis.windows.conf配置文件中的slaveof配置以及自動(dòng)刪除了，而且兩個(gè)哨兵中的主節(jié)點(diǎn)監(jiān)控也由6380變?yōu)榱?381.

我們?cè)贉y(cè)試一下遷移后的寫(xiě)入功能。

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

可以看出在主節(jié)點(diǎn)斷開(kāi)后，集群的寫(xiě)入查看功能正常。

接下來(lái)我們將6380恢復(fù)，看是否能夠重新連接入集群：

可以看到6380重新開(kāi)啟后，自動(dòng)變?yōu)閺墓?jié)點(diǎn)連接入集群，并在6380的redis.windows.conf的配置文件中自動(dòng)加入了：

slaveof 10.66.205.85 6381

今天就寫(xiě)到這里了，Redis的哨兵模式是以主從模式為基礎(chǔ)的，所以說(shuō)，主從模式擁有的一些缺點(diǎn)，在哨兵模式下也具有。哨兵模式主要是監(jiān)控Master主服務(wù)器的運(yùn)行情況，當(dāng)然也會(huì)監(jiān)控Slave從服務(wù)器的運(yùn)行情況，如果Master主服務(wù)器發(fā)生了故障，該模式可以保證Slave從服務(wù)器順利升級(jí)為Master主服務(wù)器繼續(xù)提供服務(wù)，以此提高系統(tǒng)的高可用性。雖然哨兵模式比主從模式提高了不少系統(tǒng)的高可用性，但是該模式不能水平擴(kuò)容，不能動(dòng)態(tài)的增、刪節(jié)點(diǎn)，這也是限制哨兵模式廣泛應(yīng)用的主要原因。Redis也看到了這個(gè)情況，所在在Redis的3.x以后的版本提供了一個(gè)更加強(qiáng)大集群模式，那就是Cluster集群模式，這個(gè)模式也是我們下一篇文章的主題。

與50位技術(shù)專(zhuān)家面對(duì)面20年技術(shù)見(jiàn)證，附贈(zèng)技術(shù)全景圖

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。