深入學習Redis高可用架構:哨兵原理及實踐
【51CTO.com原創稿件】在上篇文章Redis 高可用的基石:主從複製》中曾提到,Redis 主從複製的作用有資料熱備、負載均衡、故障恢復等;但主從複製存在的一個問題是故障恢復無法自動化。" rel="nofollow,noindex" target="_blank">《深入學習 Redis 高可用的基石:主從複製》 中曾提到,Redis 主從複製的作用有資料熱備、負載均衡、故障恢復等;但主從複製存在的一個問題是故障恢復無法自動化。
本文將要介紹的哨兵,它基於 Redis 主從複製,主要作用便是解決主節點故障恢復的自動化問題,進一步提高系統的高可用性。
文章將首先介紹哨兵的作用和架構;然後講述哨兵系統的部署方法,以及通過客戶端訪問哨兵系統的方法;然後簡要說明哨兵實現的基本原理;最後給出關於哨兵實踐的一些建議。(注:文章內容基於 Redis 3.0 版本)
哨兵的作用和架構
哨兵的作用
在介紹哨兵之前,首先從巨集觀角度回顧一下 Redis 實現高可用相關的技術。
它們包括:持久化、複製、哨兵和叢集,其主要作用和解決的問題是:
- 持久化:持久化是最簡單的高可用方法(有時甚至不被歸為高可用的手段),主要作用是資料備份,即將資料儲存在硬碟,保證資料不會因程序退出而丟失。
- 複製:複製是高可用 Redis 的基礎,哨兵和叢集都是在複製基礎上實現高可用的。
複製主要實現了資料的多機備份,以及對於讀操作的負載均衡和簡單的故障恢復。缺陷:故障恢復無法自動化;寫操作無法負載均衡;儲存能力受到單機的限制。
- 哨兵:在複製的基礎上,哨兵實現了自動化的故障恢復。缺陷:寫操作無法負載均衡;儲存能力受到單機的限制。
- 叢集:通過叢集,Redis 解決了寫操作無法負載均衡,以及儲存能力受到單機限制的問題,實現了較為完善的高可用方案。
下面說回哨兵,Redis Sentinel,即 Redis 哨兵,在 Redis 2.8 版本開始引入。哨兵的核心功能是主節點的自動故障轉移。
下面是 Redis 官方文件對於哨兵功能的描述:
- 監控(Monitoring):哨兵會不斷地檢查主節點和從節點是否運作正常。
- 自動故障轉移(Automatic failover):當主節點不能正常工作時,哨兵會開始自動故障轉移操作,它會將失效主節點的其中一個從節點升級為新的主節點,並讓其他從節點改為複製新的主節點。
- 配置提供者(Configurationprovider):客戶端在初始化時,通過連線哨兵來獲得當前 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
按照上述方式配置和啟動之後,整個哨兵系統就啟動完畢了,可以通過 redis-cli 連線哨兵節點進行驗證。
如下圖所示:可以看出 26379 哨兵節點已經在監控 mymaster 主節點(即192.168.92.128:6379),並發現了其 2 個從節點和另外 2 個哨兵節點。
此時如果檢視哨兵節點的配置檔案,會發現一些變化,以 26379 為例:
其中,dir 只是顯式聲明瞭資料和日誌所在的目錄(在哨兵語境下只有日誌);known-slave 和 known-sentinel 顯示哨兵已經發現了從節點和其他哨兵。
帶有 epoch 的引數與配置紀元有關(配置紀元是一個從 0 開始的計數器,每進行一次領導者哨兵選舉,都會 +1;領導者哨兵選舉是故障轉移階段的一個操作,在後文原理部分會介紹)。
演示故障轉移
哨兵的四個作用中,配置提供者和通知需要客戶端的配合,本文將在下一章介紹客戶端訪問哨兵系統的方法時再詳細介紹。
這一小節將演示當主節點發生故障時,哨兵的監控和自動故障轉移功能。
(1)首先,使用 Kill 命令殺掉主節點:
(2)如果此時立即在哨兵節點中使用 info Sentinel 命令檢視,會發現主節點還沒有切換過來,因為哨兵發現主節點故障並轉移,需要一段時間。
(3)一段時間以後,再次在哨兵節點中執行 info Sentinel 檢視,發現主節點已經切換成 6380 節點。
但是同時可以發現,哨兵節點認為新的主節點仍然有 2 個從節點,這是因為哨兵在將 6380 切換成主節點的同時,將 6379 節點置為其從節點。
雖然 6379 從節點已經掛掉,但是由於哨兵並不會對從節點進行客觀下線(其含義將在原理部分介紹),因此認為該從節點一直存在。
當 6379 節點重新啟動後,會自動變成 6380 節點的從節點,下面驗證一下。
(4)重啟 6379 節點:可以看到 6379 節點成為了 6380 節點的從節點。
(5)在故障轉移階段,哨兵和主從節點的配置檔案都會被改寫。
對於主從節點,主要是 slaveof 配置的變化:新的主節點沒有了 slaveof 配置,其從節點則 slaveof 新的主節點。
對於哨兵節點,除了主從節點資訊的變化,紀元(epoch)也會變化,下圖中可以看到紀元相關的引數都 +1 了。
小結
哨兵系統的搭建過程,有幾點需要注意:
- 哨兵系統中的主從節點,與普通的主從節點並沒有什麼區別,故障發現和轉移是由哨兵來控制和完成的。
- 哨兵節點本質上是 Redis 節點。
- 每個哨兵節點,只需要配置監控主節點,便可以自動發現其他的哨兵節點和從節點。
- 在哨兵節點啟動和故障轉移階段,各個節點的配置檔案會被重寫(config rewrite)。
- 本章的例子中,一個哨兵只監控了一個主節點;實際上,一個哨兵可以監控多個主節點,通過配置多條 sentinel monitor 即可實現。
客戶端訪問哨兵系統
上一小節演示了哨兵的兩大作用:監控和自動故障轉移。本小節則結合客戶端演示哨兵的另外兩個作用:配置提供者和通知。
程式碼示例
在介紹客戶端的原理之前,先以 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(); }
客戶端原理
Jedis 客戶端對哨兵提供了很好的支援。如上述程式碼所示,我們只需要向 Jedis 提供哨兵節點集合和 masterName,構造 JedisSentinelPool 物件。
然後便可以像使用普通 Redis 連線池一樣來使用了:通過 pool.getResource() 獲取連線,執行具體的命令。
在整個過程中,我們的程式碼不需要顯式的指定主節點的地址,就可以連線到主節點;程式碼中對故障轉移沒有任何體現,就可以在哨兵完成故障轉移後自動的切換主節點。
之所以可以做到這一點,是因為在 JedisSentinelPool 的構造器中,進行了相關的工作;主要包括以下兩點:
遍歷哨兵節點,獲取主節點資訊:遍歷哨兵節點,通過其中一個哨兵節點 + masterName 獲得主節點的資訊。
該功能是通過呼叫哨兵節點的 sentinelget-master-addr-by-name 命令實現,該命令示例如下:
一旦獲得主節點資訊,停止遍歷(因此一般來說遍歷到第一個哨兵節點,迴圈就停止了)。
增加對哨兵的監聽:這樣當發生故障轉移時,客戶端便可以收到哨兵的通知,從而完成主節點的切換。
具體做法是:利用 Redis 提供的釋出訂閱功能,為每一個哨兵節點開啟一個單獨的執行緒,訂閱哨兵節點的 + switch-master 頻道,當收到訊息時,重新初始化連線池。
小結
通過客戶端原理的介紹,我們可以加深對哨兵功能的理解。
配置提供者:客戶端可以通過哨兵節點 + masterName 獲取主節點資訊,在這裡哨兵起到的作用就是配置提供者。
需要注意的是,哨兵只是配置提供者,而不是代理。二者的區別在於:
- 如果是配置提供者,客戶端在通過哨兵獲得主節點資訊後,會直接建立到主節點的連線,後續的請求(如 set/get)會直接發向主節點。
- 如果是代理,客戶端的每一次請求都會發向哨兵,哨兵再通過主節點處理請求。
舉一個例子可以很好的理解哨兵的作用是配置提供者,而不是代理。在前面部署的哨兵系統中,將哨兵節點的配置檔案進行如下修改:
sentinel monitor mymaster 192.168.92.128 6379 2 改為 sentinel monitor mymaster 127.0.0.1 6379 2
然後,將前述客戶端程式碼在區域網的另外一臺機器上執行,會發現客戶端無法連線主節點。
這是因為哨兵作為配置提供者,客戶端通過它查詢到主節點的地址為 127.0.0.1:6379,客戶端會向 127.0.0.1:6379 建立 Redis 連線,自然無法連線。如果哨兵是代理,這個問題就不會出現了。
通知:哨兵節點在故障轉移完成後,會將新的主節點資訊傳送給客戶端,以便客戶端及時切換主節點。
哨兵實現的基本原理
前面介紹了哨兵部署、使用的基本方法,本部分介紹哨兵實現的基本原理。
哨兵節點支援的命令
哨兵節點作為執行在特殊模式下的 Redis 節點,其支援的命令與普通的 Redis 節點不同。
在運維中,我們可以通過這些命令查詢或修改哨兵系統;不過更重要的是,哨兵系統要實現故障發現、故障轉移等各種功能,離不開哨兵節點之間的通訊。
而通訊的很大一部分是通過哨兵節點支援的命令來實現的。下面介紹哨兵節點支援的主要命令。
基礎查詢
通過這些命令,可以查詢哨兵系統的拓撲結構、節點資訊、配置資訊等:
- 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:哨兵節點之間可以通過該命令詢問主節點是否下線,從而對是否客觀下線做出判斷。
增加/移除對主節點的監控
sentinel monitor mymaster2 192.168.92.128 16379 2:與部署哨兵節點時配置檔案中的 sentinel monitor 功能完全一樣,不再詳述。
sentinel remove mymaster2:取消當前哨兵節點對主節點 mymaster2 的監控。
強制故障轉移
sentinel failover mymaster:該命令可以強制對 mymaster 執行故障轉移,即便當前的主節點執行完好。
例如,如果當前主節點所在機器即將報廢,便可以提前通過failover命令進行故障轉移。
基本原理
關於哨兵的原理,關鍵是瞭解以下幾個概念。
定時任務
每個哨兵節點維護了 3 個定時任務,定時任務的功能分別如下:
- 通過向主從節點發送 info 命令獲取最新的主從結構。
- 通過釋出訂閱功能獲取其他哨兵節點的資訊。
- 通過向其他節點發送 ping 命令進行心跳檢測,判斷是否下線。
主觀下線
在心跳檢測的定時任務中,如果其他節點超過一定時間沒有回覆,哨兵節點就會將其進行主觀下線。
顧名思義,主觀下線的意思是一個哨兵節點“主觀地”判斷下線;與主觀下線相對應的是客觀下線。
客觀下線
哨兵節點在對主節點進行主觀下線後,會通過 sentinelis-master-down-by-addr 命令詢問其他哨兵節點該主節點的狀態。
如果判斷主節點下線的哨兵數量達到一定數值,則對該主節點進行客觀下線。
需要特別注意的是,客觀下線是主節點才有的概念;如果從節點和哨兵節點發生故障,被哨兵主觀下線後,不會再有後續的客觀下線和故障轉移操作。
選舉領導者哨兵節點
當主節點被判斷客觀下線以後,各個哨兵節點會進行協商,選舉出一個領導者哨兵節點,並由該領導者節點對其進行故障轉移操作。
監視該主節點的所有哨兵都有可能被選為領導者,選舉使用的演算法是 Raft 演算法。
Raft 演算法的基本思路是先到先得:即在一輪選舉中,哨兵 A 向 B 傳送成為領導者的申請,如果 B 沒有同意過其他哨兵,則會同意 A 成為領導者。
選舉的具體過程這裡不做詳細描述,一般來說,哨兵選擇的過程很快,誰先完成客觀下線,一般就能成為領導者。
故障轉移
選舉出的領導者哨兵,開始進行故障轉移操作,該操作大體可以分為 3 個步驟:
- 在從節點中選擇新的主節點:選擇的原則是,首先過濾掉不健康的從節點,然後選擇優先順序最高的從節點(由 slave-priority 指定)。
如果優先順序無法區分,則選擇複製偏移量最大的從節點;如果仍無法區分,則選擇 runid 最小的從節點。
- 更新主從狀態:通過 slaveof no one 命令,讓選出來的從節點成為主節點;並通過 slaveof 命令讓其他節點成為其從節點。
- 將已經下線的主節點(即 6379)設定為新的主節點的從節點,當 6379 重新上線後,它會成為新的主節點的從節點。
通過上述幾個關鍵概念,可以基本瞭解哨兵的工作原理。為了更形象的說明,下圖展示了領導者哨兵節點的日誌,包括從節點啟動到完成故障轉移。
哨兵配置與實踐建議
哨兵配置
下面介紹與哨兵相關的幾個配置。
sentinel monitor {masterName} {masterIp} {masterPort}{quorum}
sentinel monitor 是哨兵最核心的配置,在前文講述部署哨兵節點時已說明,其中:masterName 指定了主節點名稱,masterIp 和 masterPort 指定了主節點地址,quorum 是判斷主節點客觀下線的哨兵數量閾值。
當判定主節點下線的哨兵數量達到 quorum 時,對主節點進行客觀下線。建議取值為哨兵數量的一半加 1。
sentinel down-after-milliseconds {masterName} {time}
sentinel down-after-milliseconds 與主觀下線的判斷有關:哨兵使用 ping 命令對其他節點進行心跳檢測。
如果其他節點超過 down-after-milliseconds 配置的時間沒有回覆,哨兵就會將其進行主觀下線,該配置對主節點、從節點和哨兵節點的主觀下線判定都有效。
down-after-milliseconds 的預設值是 30000,即 30s;可以根據不同的網路環境和應用要求來調整。
值越大,對主觀下線的判定會越寬鬆,好處是誤判的可能性小,壞處是故障發現和故障轉移的時間變長,客戶端等待的時間也會變長。
例如,如果應用對可用性要求較高,則可以將值適當調小,當故障發生時儘快完成轉移;如果網路環境相對較差,可以適當提高該閾值,避免頻繁誤判。
sentinel parallel-syncs {masterName} {number}
sentinel parallel-syncs 與故障轉移之後從節點的複製有關:它規定了每次向新的主節點發起復制操作的從節點個數。
例如,假設主節點切換完成之後,有 3 個從節點要向新的主節點發起復制;如果 parallel-syncs=1,則從節點會一個一個開始複製;如果 parallel-syncs=3,則 3 個從節點會一起開始複製。
parallel-syncs 取值越大,從節點完成複製的時間越快,但是對主節點的網路負載、硬碟負載造成的壓力也越大;應根據實際情況設定。
例如,如果主節點的負載較低,而從節點對服務可用的要求較高,可以適量增加 parallel-syncs 取值。parallel-syncs 的預設值是 1。
sentinel failover-timeout {masterName} {time}
sentinel failover-timeout 與故障轉移超時的判斷有關,但是該引數不是用來判斷整個故障轉移階段的超時,而是其幾個子階段的超時。
例如如果主節點晉升從節點時間超過 timeout,或從節點向新的主節點發起復制操作的時間(不包括複製資料的時間)超過 timeout,都會導致故障轉移超時失敗。
failover-timeout 的預設值是 180000,即 180s;如果超時,則下一次該值會變為原來的 2 倍。
除上述幾個引數外,還有一些其他引數,如安全驗證相關的引數,這裡不做介紹。
實踐建議
哨兵節點的數量應不止一個,一方面增加哨兵節點的冗餘,避免哨兵本身成為高可用的瓶頸;另一方面減少對下線的誤判。此外,這些不同的哨兵節點應部署在不同的物理機上。
哨兵節點的數量應該是奇數,便於哨兵通過投票做出“決策”:領導者選舉的決策、客觀下線的決策等。
各個哨兵節點的配置應一致,包括硬體、引數等;此外,所有節點都應該使用 ntp 或類似服務,保證時間準確、一致。
哨兵的配置提供者和通知客戶端功能,需要客戶端的支援才能實現,如前文所說的 Jedis;如果開發者使用的庫未提供相應支援,則可能需要開發者自己實現。
當哨兵系統中的節點在 Docker(或其他可能進行埠對映的軟體)中部署時,應特別注意埠對映可能會導致哨兵系統無法正常工作。
因為哨兵的工作基於與其他節點的通訊,而 Docker 的埠對映可能導致哨兵無法連線到其他節點。
例如,哨兵之間互相發現,依賴於它們對外宣稱的 IP 和 port,如果某個哨兵 A 部署在做了埠對映的 Docker 中,那麼其他哨兵使用 A 宣稱的 port 無法連線到 A。
本文首先介紹了哨兵的作用:監控、故障轉移、配置提供者和通知;然後講述了哨兵系統的部署方法,以及通過客戶端訪問哨兵系統的方法;再然後簡要說明了哨兵實現的基本原理;最後給出了關於哨兵實踐的一些建議。
在主從複製的基礎上,哨兵引入了主節點的自動故障轉移,進一步提高了 Redis 的高可用性。
但是哨兵的缺陷同樣很明顯:哨兵無法對從節點進行自動故障轉移,在讀寫分離場景下,從節點故障會導致讀服務不可用,需要我們對從節點做額外的監控、切換操作。
此外,哨兵仍然沒有解決寫操作無法負載均衡、及儲存能力受到單機限制的問題;這些問題的解決需要使用叢集,我將在後面的文章中介紹,歡迎關注。
參考文獻:
https://redis.io/topics/sentinel
http://www.redis.cn/
《Redis開發與運維》
《Redis設計與實現》
【51CTO原創稿件,合作站點轉載請註明原文作者和出處為51CTO.com】