當前位置：首頁 > 运维知识 > 数据库 >内容正文

数据库

深入学习Redis（4）：哨兵

發(fā)布時間：2023/11/29 数据库 71 豆豆

生活随笔收集整理的這篇文章主要介紹了深入学习Redis（4）：哨兵小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

前言

在深入學習Redis（3）：主從復制中曾提到，Redis主從復制的作用有數(shù)據(jù)熱備、負載均衡、故障恢復等；但主從復制存在的一個問題是故障恢復無法自動化。本文將要介紹的哨兵，它基于Redis主從復制，主要作用便是解決主節(jié)點故障恢復的自動化問題，進一步提高系統(tǒng)的高可用性。

文章主要內(nèi)容如下：首先介紹哨兵的作用和架構(gòu)；然后講述哨兵系統(tǒng)的部署方法，以及通過客戶端訪問哨兵系統(tǒng)的方法；然后簡要說明哨兵實現(xiàn)的基本原理；最后給出關于哨兵實踐的一些建議。文章內(nèi)容基于Redis 3.0版本。

系列文章

深入學習Redis（1）：Redis內(nèi)存模型

深入學習Redis（2）：持久化

深入學習Redis（3）：主從復制

深入學習Redis（4）：哨兵

一、作用和架構(gòu)

1. 作用

在介紹哨兵之前，首先從宏觀角度回顧一下Redis實現(xiàn)高可用相關的技術(shù)。它們包括：持久化、復制、哨兵和集群，其主要作用和解決的問題是：

持久化：持久化是最簡單的高可用方法(有時甚至不被歸為高可用的手段)，主要作用是數(shù)據(jù)備份，即將數(shù)據(jù)存儲在硬盤，保證數(shù)據(jù)不會因進程退出而丟失。
復制：復制是高可用Redis的基礎，哨兵和集群都是在復制基礎上實現(xiàn)高可用的。復制主要實現(xiàn)了數(shù)據(jù)的多機備份，以及對于讀操作的負載均衡和簡單的故障恢復。缺陷：故障恢復無法自動化；寫操作無法負載均衡；存儲能力受到單機的限制。
哨兵：在復制的基礎上，哨兵實現(xiàn)了自動化的故障恢復。缺陷：寫操作無法負載均衡；存儲能力受到單機的限制。
集群：通過集群，Redis解決了寫操作無法負載均衡，以及存儲能力受到單機限制的問題，實現(xiàn)了較為完善的高可用方案。

下面說回哨兵。

Redis Sentinel，即Redis哨兵，在Redis 2.8版本開始引入。哨兵的核心功能是主節(jié)點的自動故障轉(zhuǎn)移。下面是Redis官方文檔對于哨兵功能的描述：

監(jiān)控（Monitoring）：哨兵會不斷地檢查主節(jié)點和從節(jié)點是否運作正常。
自動故障轉(zhuǎn)移（Automatic failover）：當主節(jié)點不能正常工作時，哨兵會開始自動故障轉(zhuǎn)移操作，它會將失效主節(jié)點的其中一個從節(jié)點升級為新的主節(jié)點，并讓其他從節(jié)點改為復制新的主節(jié)點。
配置提供者（Configuration provider）：客戶端在初始化時，通過連接哨兵來獲得當前Redis服務的主節(jié)點地址。
通知（Notification）：哨兵可以將故障轉(zhuǎn)移的結(jié)果發(fā)送給客戶端。

其中，監(jiān)控和自動故障轉(zhuǎn)移功能，使得哨兵可以及時發(fā)現(xiàn)主節(jié)點故障并完成轉(zhuǎn)移；而配置提供者和通知功能，則需要在與客戶端的交互中才能體現(xiàn)。

這里對“客戶端”一詞在文章中的用法做一個說明：在前面的文章中，只要通過API訪問redis服務器，都會稱作客戶端，包括redis-cli、Java客戶端Jedis等；為了便于區(qū)分說明，本文中的客戶端并不包括redis-cli，而是比redis-cli更加復雜：redis-cli使用的是redis提供的底層接口，而客戶端則對這些接口、功能進行了封裝，以便充分利用哨兵的配置提供者和通知功能。

2. 架構(gòu)

典型的哨兵架構(gòu)圖如下所示：

它由兩部分組成，哨兵節(jié)點和數(shù)據(jù)節(jié)點：

哨兵節(jié)點：哨兵系統(tǒng)由一個或多個哨兵節(jié)點組成，哨兵節(jié)點是特殊的redis節(jié)點，不存儲數(shù)據(jù)。
數(shù)據(jù)節(jié)點：主節(jié)點和從節(jié)點都是數(shù)據(jù)節(jié)點。

二、部署

這一部分將部署一個簡單的哨兵系統(tǒng)，包含1個主節(jié)點、2個從節(jié)點和3個哨兵節(jié)點。方便起見：所有這些節(jié)點都部署在一臺機器上（局域網(wǎng)IP：192.168.92.128），使用端口號區(qū)分；節(jié)點的配置盡可能簡化。

1. 部署主從節(jié)點

哨兵系統(tǒng)中的主從節(jié)點，與普通的主從節(jié)點配置是一樣的，并不需要做任何額外配置。下面分別是主節(jié)點（port=6379）和2個從節(jié)點（port=6380/6381）的配置文件，配置都比較簡單，不再詳述。

12345678910111213141516171819

#redis-6379.confport 6379daemonize yeslogfile "6379.log"dbfilename "dump-6379.rdb" #redis-6380.confport 6380daemonize yeslogfile "6380.log"dbfilename "dump-6380.rdb"slaveof 192.168.92.128 6379 #redis-6381.confport 6381daemonize yeslogfile "6381.log"dbfilename "dump-6381.rdb"slaveof 192.168.92.128 6379

配置完成后，依次啟動主節(jié)點和從節(jié)點：

123	redis-server redis-6379.confredis-server redis-6380.confredis-server redis-6381.conf

節(jié)點啟動后，連接主節(jié)點查看主從狀態(tài)是否正常，如下圖所示：

2. 部署哨兵節(jié)點

哨兵節(jié)點本質(zhì)上是特殊的Redis節(jié)點。

3個哨兵節(jié)點的配置幾乎是完全一樣的，主要區(qū)別在于端口號的不同（26379/26380/26381），下面以26379節(jié)點為例介紹節(jié)點的配置和啟動方式；配置部分盡量簡化，更多配置會在后面介紹。

12345

#sentinel-26379.confport 26379daemonize yeslogfile "26379.log"sentinel monitor mymaster 192.168.92.128 6379 2

其中，sentinel monitor mymaster 192.168.92.128 6379 2 配置的含義是：該哨兵節(jié)點監(jiān)控192.168.92.128:6379這個主節(jié)點，該主節(jié)點的名稱是mymaster，最后的2的含義與主節(jié)點的故障判定有關：至少需要2個哨兵節(jié)點同意，才能判定主節(jié)點故障并進行故障轉(zhuǎn)移。

哨兵節(jié)點的啟動有兩種方式，二者作用是完全相同的：

12	redis-sentinel sentinel-26379.confredis-server sentinel-26379.conf --sentinel

按照上述方式配置和啟動之后，整個哨兵系統(tǒng)就啟動完畢了。可以通過redis-cli連接哨兵節(jié)點進行驗證，如下圖所示：可以看出26379哨兵節(jié)點已經(jīng)在監(jiān)控mymaster主節(jié)點(即192.168.92.128:6379)，并發(fā)現(xiàn)了其2個從節(jié)點和另外2個哨兵節(jié)點。

此時如果查看哨兵節(jié)點的配置文件，會發(fā)現(xiàn)一些變化，以26379為例：

其中，dir只是顯式聲明了數(shù)據(jù)和日志所在的目錄（在哨兵語境下只有日志）；known-slave和known-sentinel顯示哨兵已經(jīng)發(fā)現(xiàn)了從節(jié)點和其他哨兵；帶有epoch的參數(shù)與配置紀元有關（配置紀元是一個從0開始的計數(shù)器，每進行一次領導者哨兵選舉，都會+1；領導者哨兵選舉是故障轉(zhuǎn)移階段的一個操作，在后文原理部分會介紹）。

3. 演示故障轉(zhuǎn)移

哨兵的4個作用中，配置提供者和通知需要客戶端的配合，本文將在下一章介紹客戶端訪問哨兵系統(tǒng)的方法時詳細介紹。這一小節(jié)將演示當主節(jié)點發(fā)生故障時，哨兵的監(jiān)控和自動故障轉(zhuǎn)移功能。

（1）首先，使用kill命令殺掉主節(jié)點：

（2）如果此時立即在哨兵節(jié)點中使用info Sentinel命令查看，會發(fā)現(xiàn)主節(jié)點還沒有切換過來，因為哨兵發(fā)現(xiàn)主節(jié)點故障并轉(zhuǎn)移，需要一段時間。

（3）一段時間以后，再次在哨兵節(jié)點中執(zhí)行info Sentinel查看，發(fā)現(xiàn)主節(jié)點已經(jīng)切換成6380節(jié)點。

但是同時可以發(fā)現(xiàn)，哨兵節(jié)點認為新的主節(jié)點仍然有2個從節(jié)點，這是因為哨兵在將6380切換成主節(jié)點的同時，將6379節(jié)點置為其從節(jié)點；雖然6379從節(jié)點已經(jīng)掛掉，但是由于哨兵并不會對從節(jié)點進行客觀下線（其含義將在原理部分介紹），因此認為該從節(jié)點一直存在。當6379節(jié)點重新啟動后，會自動變成6380節(jié)點的從節(jié)點。下面驗證一下。

（4）重啟6379節(jié)點：可以看到6379節(jié)點成為了6380節(jié)點的從節(jié)點。

（5）在故障轉(zhuǎn)移階段，哨兵和主從節(jié)點的配置文件都會被改寫。

對于主從節(jié)點，主要是slaveof配置的變化：新的主節(jié)點沒有了slaveof配置，其從節(jié)點則slaveof新的主節(jié)點。

對于哨兵節(jié)點，除了主從節(jié)點信息的變化，紀元(epoch)也會變化，下圖中可以看到紀元相關的參數(shù)都+1了。

4. 總結(jié)

哨兵系統(tǒng)的搭建過程，有幾點需要注意：

（1）哨兵系統(tǒng)中的主從節(jié)點，與普通的主從節(jié)點并沒有什么區(qū)別，故障發(fā)現(xiàn)和轉(zhuǎn)移是由哨兵來控制和完成的。

（2）哨兵節(jié)點本質(zhì)上是redis節(jié)點。

（3）每個哨兵節(jié)點，只需要配置監(jiān)控主節(jié)點，便可以自動發(fā)現(xiàn)其他的哨兵節(jié)點和從節(jié)點。

（4）在哨兵節(jié)點啟動和故障轉(zhuǎn)移階段，各個節(jié)點的配置文件會被重寫(config rewrite)。

（5）本章的例子中，一個哨兵只監(jiān)控了一個主節(jié)點；實際上，一個哨兵可以監(jiān)控多個主節(jié)點，通過配置多條sentinel monitor即可實現(xiàn)。

三、客戶端訪問哨兵系統(tǒng)

上一小節(jié)演示了哨兵的兩大作用：監(jiān)控和自動故障轉(zhuǎn)移，本小節(jié)則結(jié)合客戶端演示哨兵的另外兩個作用：配置提供者和通知。

1. 代碼示例

在介紹客戶端的原理之前，先以Java客戶端Jedis為例，演示一下使用方法：下面代碼可以連接我們剛剛搭建的哨兵系統(tǒng)，并進行各種讀寫操作（代碼中只演示如何連接哨兵，異常處理、資源關閉等未考慮）。

123456789101112

public static void testSentinel() throws Exception { String masterName = "mymaster"; Set<String> sentinels = new HashSet<>(); sentinels.add("192.168.92.128:26379"); sentinels.add("192.168.92.128:26380"); sentinels.add("192.168.92.128:26381"); JedisSentinelPool pool = new JedisSentinelPool(masterName, sentinels); //初始化過程做了很多工作 Jedis jedis = pool.getResource(); jedis.set("key1", "value1"); pool.close();}

2. 客戶端原理

Jedis客戶端對哨兵提供了很好的支持。如上述代碼所示，我們只需要向Jedis提供哨兵節(jié)點集合和masterName，構(gòu)造JedisSentinelPool對象；然后便可以像使用普通redis連接池一樣來使用了：通過pool.getResource()獲取連接，執(zhí)行具體的命令。

在整個過程中，我們的代碼不需要顯式的指定主節(jié)點的地址，就可以連接到主節(jié)點；代碼中對故障轉(zhuǎn)移沒有任何體現(xiàn)，就可以在哨兵完成故障轉(zhuǎn)移后自動的切換主節(jié)點。之所以可以做到這一點，是因為在JedisSentinelPool的構(gòu)造器中，進行了相關的工作；主要包括以下兩點：

（1）遍歷哨兵節(jié)點，獲取主節(jié)點信息：遍歷哨兵節(jié)點，通過其中一個哨兵節(jié)點+masterName獲得主節(jié)點的信息；該功能是通過調(diào)用哨兵節(jié)點的sentinel get-master-addr-by-name命令實現(xiàn)，該命令示例如下：

一旦獲得主節(jié)點信息，停止遍歷（因此一般來說遍歷到第一個哨兵節(jié)點，循環(huán)就停止了）。

（2）增加對哨兵的監(jiān)聽：這樣當發(fā)生故障轉(zhuǎn)移時，客戶端便可以收到哨兵的通知，從而完成主節(jié)點的切換。具體做法是：利用redis提供的發(fā)布訂閱功能，為每一個哨兵節(jié)點開啟一個單獨的線程，訂閱哨兵節(jié)點的+switch-master頻道，當收到消息時，重新初始化連接池。

3. 總結(jié)

通過客戶端原理的介紹，可以加深對哨兵功能的理解：

（1）配置提供者：客戶端可以通過哨兵節(jié)點+masterName獲取主節(jié)點信息，在這里哨兵起到的作用就是配置提供者。

需要注意的是，哨兵只是配置提供者，而不是代理。二者的區(qū)別在于：如果是配置提供者，客戶端在通過哨兵獲得主節(jié)點信息后，會直接建立到主節(jié)點的連接，后續(xù)的請求(如set/get)會直接發(fā)向主節(jié)點；如果是代理，客戶端的每一次請求都會發(fā)向哨兵，哨兵再通過主節(jié)點處理請求。

舉一個例子可以很好的理解哨兵的作用是配置提供者，而不是代理。在前面部署的哨兵系統(tǒng)中，將哨兵節(jié)點的配置文件進行如下修改：

123	sentinel monitor mymaster 192.168.92.128 6379 2改為sentinel monitor mymaster 127.0.0.1 6379 2

然后，將前述客戶端代碼在局域網(wǎng)的另外一臺機器上運行，會發(fā)現(xiàn)客戶端無法連接主節(jié)點；這是因為哨兵作為配置提供者，客戶端通過它查詢到主節(jié)點的地址為127.0.0.1:6379，客戶端會向127.0.0.1:6379建立redis連接，自然無法連接。如果哨兵是代理，這個問題就不會出現(xiàn)了。

（2）通知：哨兵節(jié)點在故障轉(zhuǎn)移完成后，會將新的主節(jié)點信息發(fā)送給客戶端，以便客戶端及時切換主節(jié)點。

四、基本原理

前面介紹了哨兵部署、使用的基本方法，本部分介紹哨兵實現(xiàn)的基本原理。

1. 哨兵節(jié)點支持的命令

哨兵節(jié)點作為運行在特殊模式下的redis節(jié)點，其支持的命令與普通的redis節(jié)點不同。在運維中，我們可以通過這些命令查詢或修改哨兵系統(tǒng)；不過更重要的是，哨兵系統(tǒng)要實現(xiàn)故障發(fā)現(xiàn)、故障轉(zhuǎn)移等各種功能，離不開哨兵節(jié)點之間的通信，而通信的很大一部分是通過哨兵節(jié)點支持的命令來實現(xiàn)的。下面介紹哨兵節(jié)點支持的主要命令。

（1）基礎查詢：通過這些命令，可以查詢哨兵系統(tǒng)的拓撲結(jié)構(gòu)、節(jié)點信息、配置信息等。

info sentinel：獲取監(jiān)控的所有主節(jié)點的基本信息
sentinel masters：獲取監(jiān)控的所有主節(jié)點的詳細信息
sentinel master mymaster：獲取監(jiān)控的主節(jié)點mymaster的詳細信息
sentinel slaves mymaster：獲取監(jiān)控的主節(jié)點mymaster的從節(jié)點的詳細信息
sentinel sentinels mymaster：獲取監(jiān)控的主節(jié)點mymaster的哨兵節(jié)點的詳細信息
sentinel get-master-addr-by-name mymaster：獲取監(jiān)控的主節(jié)點mymaster的地址信息，前文已有介紹
sentinel is-master-down-by-addr：哨兵節(jié)點之間可以通過該命令詢問主節(jié)點是否下線，從而對是否客觀下線做出判斷

（2）增加/移除對主節(jié)點的監(jiān)控

sentinel monitor mymaster2 192.168.92.128 16379 2：與部署哨兵節(jié)點時配置文件中的sentinel monitor功能完全一樣，不再詳述

sentinel remove mymaster2：取消當前哨兵節(jié)點對主節(jié)點mymaster2的監(jiān)控

（3）強制故障轉(zhuǎn)移

sentinel failover mymaster：該命令可以強制對mymaster執(zhí)行故障轉(zhuǎn)移，即便當前的主節(jié)點運行完好；例如，如果當前主節(jié)點所在機器即將報廢，便可以提前通過failover命令進行故障轉(zhuǎn)移。

2. 基本原理

關于哨兵的原理，關鍵是了解以下幾個概念。

（1）定時任務：每個哨兵節(jié)點維護了3個定時任務。定時任務的功能分別如下：通過向主從節(jié)點發(fā)送info命令獲取最新的主從結(jié)構(gòu)；通過發(fā)布訂閱功能獲取其他哨兵節(jié)點的信息；通過向其他節(jié)點發(fā)送ping命令進行心跳檢測，判斷是否下線。

（2）主觀下線：在心跳檢測的定時任務中，如果其他節(jié)點超過一定時間沒有回復，哨兵節(jié)點就會將其進行主觀下線。顧名思義，主觀下線的意思是一個哨兵節(jié)點“主觀地”判斷下線；與主觀下線相對應的是客觀下線。

（3）客觀下線：哨兵節(jié)點在對主節(jié)點進行主觀下線后，會通過sentinel is-master-down-by-addr命令詢問其他哨兵節(jié)點該主節(jié)點的狀態(tài)；如果判斷主節(jié)點下線的哨兵數(shù)量達到一定數(shù)值，則對該主節(jié)點進行客觀下線。

需要特別注意的是，客觀下線是主節(jié)點才有的概念；如果從節(jié)點和哨兵節(jié)點發(fā)生故障，被哨兵主觀下線后，不會再有后續(xù)的客觀下線和故障轉(zhuǎn)移操作。

（4）選舉領導者哨兵節(jié)點：當主節(jié)點被判斷客觀下線以后，各個哨兵節(jié)點會進行協(xié)商，選舉出一個領導者哨兵節(jié)點，并由該領導者節(jié)點對其進行故障轉(zhuǎn)移操作。

監(jiān)視該主節(jié)點的所有哨兵都有可能被選為領導者，選舉使用的算法是Raft算法；Raft算法的基本思路是先到先得：即在一輪選舉中，哨兵A向B發(fā)送成為領導者的申請，如果B沒有同意過其他哨兵，則會同意A成為領導者。選舉的具體過程這里不做詳細描述，一般來說，哨兵選擇的過程很快，誰先完成客觀下線，一般就能成為領導者。

（5）故障轉(zhuǎn)移：選舉出的領導者哨兵，開始進行故障轉(zhuǎn)移操作，該操作大體可以分為3個步驟：

在從節(jié)點中選擇新的主節(jié)點：選擇的原則是，首先過濾掉不健康的從節(jié)點；然后選擇優(yōu)先級最高的從節(jié)點(由slave-priority指定)；如果優(yōu)先級無法區(qū)分，則選擇復制偏移量最大的從節(jié)點；如果仍無法區(qū)分，則選擇runid最小的從節(jié)點。
更新主從狀態(tài)：通過slaveof no one命令，讓選出來的從節(jié)點成為主節(jié)點；并通過slaveof命令讓其他節(jié)點成為其從節(jié)點。
將已經(jīng)下線的主節(jié)點(即6379)設置為新的主節(jié)點的從節(jié)點，當6379重新上線后，它會成為新的主節(jié)點的從節(jié)點。

通過上述幾個關鍵概念，可以基本了解哨兵的工作原理。為了更形象的說明，下圖展示了領導者哨兵節(jié)點的日志，包括從節(jié)點啟動到完成故障轉(zhuǎn)移。

五、配置與實踐建議

1. 配置

下面介紹與哨兵相關的幾個配置。

（1） sentinel monitor {masterName} {masterIp} {masterPort} {quorum}

sentinel monitor是哨兵最核心的配置，在前文講述部署哨兵節(jié)點時已說明，其中：masterName指定了主節(jié)點名稱，masterIp和masterPort指定了主節(jié)點地址，quorum是判斷主節(jié)點客觀下線的哨兵數(shù)量閾值：當判定主節(jié)點下線的哨兵數(shù)量達到quorum時，對主節(jié)點進行客觀下線。建議取值為哨兵數(shù)量的一半加1。

（2） sentinel down-after-milliseconds {masterName} {time}

sentinel down-after-milliseconds與主觀下線的判斷有關：哨兵使用ping命令對其他節(jié)點進行心跳檢測，如果其他節(jié)點超過down-after-milliseconds配置的時間沒有回復，哨兵就會將其進行主觀下線。該配置對主節(jié)點、從節(jié)點和哨兵節(jié)點的主觀下線判定都有效。

down-after-milliseconds的默認值是30000，即30s；可以根據(jù)不同的網(wǎng)絡環(huán)境和應用要求來調(diào)整：值越大，對主觀下線的判定會越寬松，好處是誤判的可能性小，壞處是故障發(fā)現(xiàn)和故障轉(zhuǎn)移的時間變長，客戶端等待的時間也會變長。例如，如果應用對可用性要求較高，則可以將值適當調(diào)小，當故障發(fā)生時盡快完成轉(zhuǎn)移；如果網(wǎng)絡環(huán)境相對較差，可以適當提高該閾值，避免頻繁誤判。

（3） sentinel parallel-syncs {masterName} {number}

sentinel parallel-syncs與故障轉(zhuǎn)移之后從節(jié)點的復制有關：它規(guī)定了每次向新的主節(jié)點發(fā)起復制操作的從節(jié)點個數(shù)。例如，假設主節(jié)點切換完成之后，有3個從節(jié)點要向新的主節(jié)點發(fā)起復制；如果parallel-syncs=1，則從節(jié)點會一個一個開始復制；如果parallel-syncs=3，則3個從節(jié)點會一起開始復制。

parallel-syncs取值越大，從節(jié)點完成復制的時間越快，但是對主節(jié)點的網(wǎng)絡負載、硬盤負載造成的壓力也越大；應根據(jù)實際情況設置。例如，如果主節(jié)點的負載較低，而從節(jié)點對服務可用的要求較高，可以適量增加parallel-syncs取值。parallel-syncs的默認值是1。

（4） sentinel failover-timeout {masterName} {time}

sentinel failover-timeout與故障轉(zhuǎn)移超時的判斷有關，但是該參數(shù)不是用來判斷整個故障轉(zhuǎn)移階段的超時，而是其幾個子階段的超時，例如如果主節(jié)點晉升從節(jié)點時間超過timeout，或從節(jié)點向新的主節(jié)點發(fā)起復制操作的時間(不包括復制數(shù)據(jù)的時間)超過timeout，都會導致故障轉(zhuǎn)移超時失敗。

failover-timeout的默認值是180000，即180s；如果超時，則下一次該值會變?yōu)樵瓉淼?倍。

（5）除上述幾個參數(shù)外，還有一些其他參數(shù)，如安全驗證相關的參數(shù)，這里不做介紹。

2. 實踐建議

（1）哨兵節(jié)點的數(shù)量應不止一個，一方面增加哨兵節(jié)點的冗余，避免哨兵本身成為高可用的瓶頸；另一方面減少對下線的誤判。此外，這些不同的哨兵節(jié)點應部署在不同的物理機上。

（2）哨兵節(jié)點的數(shù)量應該是奇數(shù)，便于哨兵通過投票做出“決策”：領導者選舉的決策、客觀下線的決策等。

（3）各個哨兵節(jié)點的配置應一致，包括硬件、參數(shù)等；此外，所有節(jié)點都應該使用ntp或類似服務，保證時間準確、一致。

（4）哨兵的配置提供者和通知客戶端功能，需要客戶端的支持才能實現(xiàn)，如前文所說的Jedis；如果開發(fā)者使用的庫未提供相應支持，則可能需要開發(fā)者自己實現(xiàn)。

（5）當哨兵系統(tǒng)中的節(jié)點在docker（或其他可能進行端口映射的軟件）中部署時，應特別注意端口映射可能會導致哨兵系統(tǒng)無法正常工作，因為哨兵的工作基于與其他節(jié)點的通信，而docker的端口映射可能導致哨兵無法連接到其他節(jié)點。例如，哨兵之間互相發(fā)現(xiàn)，依賴于它們對外宣稱的IP和port，如果某個哨兵A部署在做了端口映射的docker中，那么其他哨兵使用A宣稱的port無法連接到A。

六、總結(jié)

本文首先介紹了哨兵的作用：監(jiān)控、故障轉(zhuǎn)移、配置提供者和通知；然后講述了哨兵系統(tǒng)的部署方法，以及通過客戶端訪問哨兵系統(tǒng)的方法；再然后簡要說明了哨兵實現(xiàn)的基本原理；最后給出了關于哨兵實踐的一些建議。

在主從復制的基礎上，哨兵引入了主節(jié)點的自動故障轉(zhuǎn)移，進一步提高了Redis的高可用性；但是哨兵的缺陷同樣很明顯：哨兵無法對從節(jié)點進行自動故障轉(zhuǎn)移，在讀寫分離場景下，從節(jié)點故障會導致讀服務不可用，需要我們對從節(jié)點做額外的監(jiān)控、切換操作。

此外，哨兵仍然沒有解決寫操作無法負載均衡、及存儲能力受到單機限制的問題；這些問題的解決需要使用集群，我將在后面的文章中介紹，歡迎關注。

總結(jié)

以上是生活随笔為你收集整理的深入学习Redis（4）：哨兵的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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

Redis
哨兵