溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹“Redis怎么部署簡單的哨兵系統”的相關知識，小編通過實際案例向大家展示操作過程，操作方法簡單快捷，實用性強，希望這篇“Redis怎么部署簡單的哨兵系統”文章能幫助大家解決問題。
在介紹哨兵之前，首先從宏觀角度回顧一下Redis實現高可用相關的技術。它們包括：持久化、復制、哨兵和集群，其主要作用和解決的問題是：
持久化：持久化是最簡單的高可用方法(有時甚至不被歸為高可用的手段)，主要作用是數據備份，即將數據存儲在硬盤，保證數據不會因進程退出而丟失。
復制：復制是高可用Redis的基礎，哨兵和集群都是在復制基礎上實現高可用的。復制主要實現了數據的多機備份，以及對于讀操作的負載均衡和簡單的故障恢復。缺陷：故障恢復無法自動化；寫操作無法負載均衡；存儲能力受到單機的限制。
哨兵：在復制的基礎上，哨兵實現了自動化的故障恢復。缺陷：寫操作無法負載均衡；存儲能力受到單機的限制。
集群：通過集群，Redis解決了寫操作無法負載均衡，以及存儲能力受到單機限制的問題，實現了較為完善的高可用方案。
下面說回哨兵。
Redis Sentinel，即Redis哨兵，在Redis 2.8版本開始引入。哨兵的核心功能是主節點的自動故障轉移。下面是Redis官方文檔對于哨兵功能的描述：
監控（Monitoring）：哨兵會不斷地檢查主節點和從節點是否運作正常。
自動故障轉移（Automatic failover）：當主節點不能正常工作時，哨兵會開始自動故障轉移操作，它會將失效主節點的其中一個從節點升級為新的主節點，并讓其他從節點改為復制新的主節點。
配置提供者（Configuration provider）：客戶端在初始化時，通過連接哨兵來獲得當前Redis服務的主節點地址。
通知（Notification）：哨兵可以將故障轉移的結果發送給客戶端。
其中，監控和自動故障轉移功能，使得哨兵可以及時發現主節點故障并完成轉移；而配置提供者和通知功能，則需要在與客戶端的交互中才能體現。
這里對“客戶端”一詞在文章中的用法做一個說明：在前面的文章中，只要通過API訪問redis服務器，都會稱作客戶端，包括redis-cli、Java客戶端Jedis等；為了便于區分說明，本文中的客戶端并不包括redis-cli，而是比redis-cli更加復雜：redis-cli使用的是redis提供的底層接口，而客戶端則對這些接口、功能進行了封裝，以便充分利用哨兵的配置提供者和通知功能。
典型的哨兵架構圖如下所示：
它由兩部分組成，哨兵節點和數據節點：
哨兵節點：哨兵系統由一個或多個哨兵節點組成，哨兵節點是特殊的redis節點，不存儲數據。
數據節點：主節點和從節點都是數據節點。
這一部分將部署一個簡單的哨兵系統，包含1個主節點、2個從節點和3個哨兵節點。方便起見：所有這些節點都部署在一臺機器上（局域網IP：192.168.92.128），使用端口號區分；節點的配置盡可能簡化。
哨兵系統中的主從節點，與普通的主從節點配置是一樣的，并不需要做任何額外配置。下面分別是主節點（port=6379）和2個從節點（port=6380/6381）的配置文件，配置都比較簡單，不再詳述。
#redis-6379.conf port 6379 daemonize yes logfile "6379.log" dbfilename "dump-6379.rdb" #redis-6380.conf port 6380 daemonize yes logfile "6380.log" dbfilename "dump-6380.rdb" slaveof 192.168.92.128 6379 #redis-6381.conf port 6381 daemonize yes logfile "6381.log" dbfilename "dump-6381.rdb" slaveof 192.168.92.128 6379
redis-server redis-6379.conf redis-server redis-6380.conf redis-server redis-6381.conf
節點啟動后，連接主節點查看主從狀態是否正常。配置完成后，依次啟動主節點和從節點：
哨兵節點本質上是特殊的Redis節點。
3個哨兵節點的配置幾乎是完全一樣的，主要區別在于端口號的不同（26379/26380/26381），下面以26379節點為例介紹節點的配置和啟動方式；配置部分盡量簡化，更多配置會在后面介紹。
#sentinel-26379.conf port 26379 daemonize yes logfile "26379.log" sentinel monitor mymaster 192.168.92.128 6379 2
哨兵節點的啟動有兩種方式，二者作用是完全相同的：其中，sentinel monitor mymaster 192.168.92.128 6379 2 配置的含義是：該哨兵節點監控192.168.92.128:6379這個主節點，該主節點的名稱是mymaster，最后的2的含義與主節點的故障判定有關：至少需要2個哨兵節點同意，才能判定主節點故障并進行故障轉移。
redis-sentinel sentinel-26379.conf redis-server sentinel-26379.conf --sentinel
3. 總結
按照上述方式配置和啟動之后，整個哨兵系統就啟動完畢了。可以通過redis-cli連接哨兵節點進行驗證
哨兵系統的搭建過程，有幾點需要注意：
（1）哨兵系統中的主從節點，與普通的主從節點并沒有什么區別，故障發現和轉移是由哨兵來控制和完成的。
（2）哨兵節點本質上是redis節點。
（3）每個哨兵節點，只需要配置監控主節點，便可以自動發現其他的哨兵節點和從節點。
（4）在哨兵節點啟動和故障轉移階段，各個節點的配置文件會被重寫(config rewrite)。
上一小節演示了哨兵的兩大作用：監控和自動故障轉移，本小節則結合客戶端演示哨兵的另外兩個作用：配置提供者和通知。
在介紹客戶端的原理之前，先以Java客戶端Jedis為例，演示一下使用方法：下面代碼可以連接我們剛剛搭建的哨兵系統，并進行各種讀寫操作（代碼中只演示如何連接哨兵，異常處理、資源關閉等未考慮）。
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();
}在整個過程中，我們的代碼不需要顯式的指定主節點的地址，就可以連接到主節點；代碼中對故障轉移沒有任何體現，就可以在哨兵完成故障轉移后自動的切換主節點。之所以可以做到這一點，是因為在JedisSentinelPool的構造器中，進行了相關的工作；主要包括以下兩點：
（1）遍歷哨兵節點，獲取主節點信息：遍歷哨兵節點，通過其中一個哨兵節點+masterName獲得主節點的信息；該功能是通過調用哨兵節點的sentinel get-master-addr-by-name命令實現，該命令示例如下：
一旦獲得主節點信息，停止遍歷（因此一般來說遍歷到第一個哨兵節點，循環就停止了）。
（2）增加對哨兵的監聽：這樣當發生故障轉移時，客戶端便可以收到哨兵的通知，從而完成主節點的切換。具體做法是：利用redis提供的發布訂閱功能，為每一個哨兵節點開啟一個單獨的線程，訂閱哨兵節點的+switch-master頻道，當收到消息時，重新初始化連接池。
通過客戶端原理的介紹，可以加深對哨兵功能的理解：
（1）配置提供者：客戶端可以通過哨兵節點+masterName獲取主節點信息，在這里哨兵起到的作用就是配置提供者。
需要注意的是，哨兵只是配置提供者，而不是代理。二者的區別在于：如果是配置提供者，客戶端在通過哨兵獲得主節點信息后，會直接建立到主節點的連接，后續的請求(如set/get)會直接發向主節點；如果是代理，客戶端的每一次請求都會發向哨兵，哨兵再通過主節點處理請求。
舉一個例子可以很好的理解哨兵的作用是配置提供者，而不是代理。在前面部署的哨兵系統中，將哨兵節點的配置文件進行如下修改：
sentinel monitor mymaster 192.168.92.128 6379 2 改為 sentinel monitor mymaster 127.0.0.1 6379 2
（2）通知：哨兵節點在故障轉移完成后，會將新的主節點信息發送給客戶端，以便客戶端及時切換主節點。然后，將前述客戶端代碼在局域網的另外一臺機器上運行，會發現客戶端無法連接主節點；這是因為哨兵作為配置提供者，客戶端通過它查詢到主節點的地址為127.0.0.1:6379，客戶端會向127.0.0.1:6379建立redis連接，自然無法連接。如果哨兵是代理，這個問題就不會出現了。
前面介紹了哨兵部署、使用的基本方法，本部分介紹哨兵實現的基本原理。
哨兵節點作為運行在特殊模式下的redis節點，其支持的命令與普通的redis節點不同。在運維中，我們可以通過這些命令查詢或修改哨兵系統；不過更重要的是，哨兵系統要實現故障發現、故障轉移等各種功能，離不開哨兵節點之間的通信，而通信的很大一部分是通過哨兵節點支持的命令來實現的。下面介紹哨兵節點支持的主要命令。
（1）基礎查詢：通過這些命令，可以查詢哨兵系統的拓撲結構、節點信息、配置信息等。
info sentinel：獲取監控的所有主節點的基本信息
sentinel masters：獲取監控的所有主節點的詳細信息
sentinel master mymaster：獲取監控的主節點mymaster的詳細信息
sentinel slaves mymaster：獲取監控的主節點mymaster的從節點的詳細信息
sentinel sentinels mymaster：獲取監控的主節點mymaster的哨兵節點的詳細信息
sentinel get-master-addr-by-name mymaster：獲取監控的主節點mymaster的地址信息，前文已有介紹
sentinel is-master-down-by-addr：哨兵節點之間可以通過該命令詢問主節點是否下線，從而對是否客觀下線做出判斷
（2）增加/移除對主節點的監控
sentinel monitor mymaster2 192.168.92.128 16379 2：與部署哨兵節點時配置文件中的sentinel monitor功能完全一樣，不再詳述
sentinel remove mymaster2：取消當前哨兵節點對主節點mymaster2的監控
（3）強制故障轉移
sentinel failover mymaster：該命令可以強制對mymaster執行故障轉移，即便當前的主節點運行完好；例如，如果當前主節點所在機器即將報廢，便可以提前通過failover命令進行故障轉移。
關于哨兵的原理，關鍵是了解以下幾個概念。
（1）定時任務：每個哨兵節點維護了3個定時任務。定時任務的功能分別如下：通過向主從節點發送info命令獲取最新的主從結構；通過發布訂閱功能獲取其他哨兵節點的信息；通過向其他節點發送ping命令進行心跳檢測，判斷是否下線。
（2）主觀下線：在心跳檢測的定時任務中，如果其他節點超過一定時間沒有回復，哨兵節點就會將其進行主觀下線。顧名思義，主觀下線的意思是一個哨兵節點“主觀地”判斷下線；與主觀下線相對應的是客觀下線。
（3）客觀下線：哨兵節點在對主節點進行主觀下線后，會通過sentinel is-master-down-by-addr命令詢問其他哨兵節點該主節點的狀態；如果判斷主節點下線的哨兵數量達到一定數值，則對該主節點進行客觀下線。
需要特別注意的是，客觀下線是主節點才有的概念；如果從節點和哨兵節點發生故障，被哨兵主觀下線后，不會再有后續的客觀下線和故障轉移操作。
（4）選舉領導者哨兵節點：當主節點被判斷客觀下線以后，各個哨兵節點會進行協商，選舉出一個領導者哨兵節點，并由該領導者節點對其進行故障轉移操作。
監視該主節點的所有哨兵都有可能被選為領導者，選舉使用的算法是Raft算法；Raft算法的基本思路是先到先得：即在一輪選舉中，哨兵A向B發送成為領導者的申請，如果B沒有同意過其他哨兵，則會同意A成為領導者。選舉的具體過程這里不做詳細描述，一般來說，哨兵選擇的過程很快，誰先完成客觀下線，一般就能成為領導者。
（5）故障轉移：選舉出的領導者哨兵，開始進行故障轉移操作，該操作大體可以分為3個步驟：
在從節點中選擇新的主節點：選擇的原則是，首先過濾掉不健康的從節點；然后選擇優先級最高的從節點(由slave-priority指定)；如果優先級無法區分，則選擇復制偏移量最大的從節點；如果仍無法區分，則選擇runid最小的從節點。
更新主從狀態：通過slaveof no one命令，讓選出來的從節點成為主節點；并通過slaveof命令讓其他節點成為其從節點。
將已經下線的主節點(即6379)設置為新的主節點的從節點，當6379重新上線后，它會成為新的主節點的從節點。
下面介紹與哨兵相關的幾個配置。
（1） sentinel monitor {masterName} {masterIp} {masterPort} {quorum}
sentinel monitor是哨兵最核心的配置，在前文講述部署哨兵節點時已說明，其中：masterName指定了主節點名稱，masterIp和masterPort指定了主節點地址，quorum是判斷主節點客觀下線的哨兵數量閾值：當判定主節點下線的哨兵數量達到quorum時，對主節點進行客觀下線。建議取值為哨兵數量的一半加1。
（2） sentinel down-after-milliseconds {masterName} {time}
sentinel down-after-milliseconds與主觀下線的判斷有關：哨兵使用ping命令對其他節點進行心跳檢測，如果其他節點超過down-after-milliseconds配置的時間沒有回復，哨兵就會將其進行主觀下線。該配置對主節點、從節點和哨兵節點的主觀下線判定都有效。
down-after-milliseconds的默認值是30000，即30s；可以根據不同的網絡環境和應用要求來調整：值越大，對主觀下線的判定會越寬松，好處是誤判的可能性小，壞處是故障發現和故障轉移的時間變長，客戶端等待的時間也會變長。例如，如果應用對可用性要求較高，則可以將值適當調小，當故障發生時盡快完成轉移；如果網絡環境相對較差，可以適當提高該閾值，避免頻繁誤判。
（3） sentinel parallel-syncs {masterName} {number}
sentinel parallel-syncs與故障轉移之后從節點的復制有關：它規定了每次向新的主節點發起復制操作的從節點個數。例如，假設主節點切換完成之后，有3個從節點要向新的主節點發起復制；如果parallel-syncs=1，則從節點會一個一個開始復制；如果parallel-syncs=3，則3個從節點會一起開始復制。
parallel-syncs取值越大，從節點完成復制的時間越快，但是對主節點的網絡負載、硬盤負載造成的壓力也越大；應根據實際情況設置。例如，如果主節點的負載較低，而從節點對服務可用的要求較高，可以適量增加parallel-syncs取值。parallel-syncs的默認值是1。
（4） sentinel failover-timeout {masterName} {time}
sentinel failover-timeout與故障轉移超時的判斷有關，但是該參數不是用來判斷整個故障轉移階段的超時，而是其幾個子階段的超時，例如如果主節點晉升從節點時間超過timeout，或從節點向新的主節點發起復制操作的時間(不包括復制數據的時間)超過timeout，都會導致故障轉移超時失敗。
failover-timeout的默認值是180000，即180s；如果超時，則下一次該值會變為原來的2倍。
（5）除上述幾個參數外，還有一些其他參數，如安全驗證相關的參數，這里不做介紹。
（1）哨兵節點的數量應不止一個，一方面增加哨兵節點的冗余，避免哨兵本身成為高可用的瓶頸；另一方面減少對下線的誤判。此外，這些不同的哨兵節點應部署在不同的物理機上。
（2）哨兵節點的數量應該是奇數，便于哨兵通過投票做出“決策”：領導者選舉的決策、客觀下線的決策等。
（3）各個哨兵節點的配置應一致，包括硬件、參數等；此外，所有節點都應該使用ntp或類似服務，保證時間準確、一致。
（4）哨兵的配置提供者和通知客戶端功能，需要客戶端的支持才能實現，如前文所說的Jedis；如果開發者使用的庫未提供相應支持，則可能需要開發者自己實現。
（5）當哨兵系統中的節點在docker（或其他可能進行端口映射的軟件）中部署時，應特別注意端口映射可能會導致哨兵系統無法正常工作，因為哨兵的工作基于與其他節點的通信，而docker的端口映射可能導致哨兵無法連接到其他節點。例如，哨兵之間互相發現，依賴于它們對外宣稱的IP和port，如果某個哨兵A部署在做了端口映射的docker中，那么其他哨兵使用A宣稱的port無法連接到A。
關于“Redis怎么部署簡單的哨兵系統”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識，可以關注億速云行業資訊頻道，小編每天都會為大家更新不同的知識點。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
