成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

深入學(xué)習(xí)Redis高可用架構(gòu):哨兵原理及實踐

原創(chuàng)
開發(fā) 架構(gòu) 開發(fā)工具 Redis
在上篇文章《深入學(xué)習(xí) Redis 高可用的基石:主從復(fù)制》中曾提到,Redis 主從復(fù)制的作用有數(shù)據(jù)熱備、負(fù)載均衡、故障恢復(fù)等;但主從復(fù)制存在的一個問題是故障恢復(fù)無法自動化。

【51CTO.com原創(chuàng)稿件】在上篇文章《深入學(xué)習(xí) Redis 高可用的基石:主從復(fù)制》中曾提到,Redis 主從復(fù)制的作用有數(shù)據(jù)熱備、負(fù)載均衡、故障恢復(fù)等;但主從復(fù)制存在的一個問題是故障恢復(fù)無法自動化。

本文將要介紹的哨兵,它基于 Redis 主從復(fù)制,主要作用便是解決主節(jié)點故障恢復(fù)的自動化問題,進一步提高系統(tǒng)的高可用性。

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

哨兵的作用和架構(gòu)

哨兵的作用

在介紹哨兵之前,首先從宏觀角度回顧一下 Redis 實現(xiàn)高可用相關(guān)的技術(shù)。

它們包括:持久化、復(fù)制、哨兵和集群,其主要作用和解決的問題是:

  • 持久化:持久化是最簡單的高可用方法(有時甚至不被歸為高可用的手段),主要作用是數(shù)據(jù)備份,即將數(shù)據(jù)存儲在硬盤,保證數(shù)據(jù)不會因進程退出而丟失。
  • 復(fù)制:復(fù)制是高可用 Redis 的基礎(chǔ),哨兵和集群都是在復(fù)制基礎(chǔ)上實現(xiàn)高可用的。

復(fù)制主要實現(xiàn)了數(shù)據(jù)的多機備份,以及對于讀操作的負(fù)載均衡和簡單的故障恢復(fù)。缺陷:故障恢復(fù)無法自動化;寫操作無法負(fù)載均衡;存儲能力受到單機的限制。

  • 哨兵:在復(fù)制的基礎(chǔ)上,哨兵實現(xiàn)了自動化的故障恢復(fù)。缺陷:寫操作無法負(fù)載均衡;存儲能力受到單機的限制。
  • 集群:通過集群,Redis 解決了寫操作無法負(fù)載均衡,以及存儲能力受到單機限制的問題,實現(xiàn)了較為完善的高可用方案。

下面說回哨兵,Redis Sentinel,即 Redis 哨兵,在 Redis 2.8 版本開始引入。哨兵的核心功能是主節(jié)點的自動故障轉(zhuǎn)移。

下面是 Redis 官方文檔對于哨兵功能的描述:

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

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

這里對“客戶端”一詞在本文的用法做一個說明:在前面的文章中,只要通過 API 訪問 Redis 服務(wù)器,都會稱作客戶端,包括 redis-cli、Java 客戶端 Jedis 等。

為了便于區(qū)分說明,本文中的客戶端并不包括 redis-cli,而是比 redis-cli 更加復(fù)雜。

redis-cli 使用的是 Redis 提供的底層接口,而客戶端則對這些接口、功能進行了封裝,以便充分利用哨兵的配置提供者和通知功能。

哨兵的架構(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)的部署方法

這一部分將部署一個簡單的哨兵系統(tǒng),包含 1 個主節(jié)點、2 個從節(jié)點和 3 個哨兵節(jié)點。

方便起見:所有這些節(jié)點都部署在一臺機器上(局域網(wǎng) IP:192.168.92.128),使用端口號區(qū)分;節(jié)點的配置盡可能簡化。

部署主從節(jié)點

哨兵系統(tǒng)中的主從節(jié)點,與普通的主從節(jié)點配置是一樣的,并不需要做任何額外配置。

下面分別是主節(jié)點(port=6379)和 2 個從節(jié)點(port=6380/6381)的配置文件,配置都比較簡單,不再詳述。

  1. #redis-6379.conf 
  2. port 6379 
  3. daemonize yes 
  4. logfile "6379.log" 
  5. dbfilename "dump-6379.rdb" 
  6.  
  7. #redis-6380.conf 
  8. port 6380 
  9. daemonize yes 
  10. logfile "6380.log" 
  11. dbfilename "dump-6380.rdb" 
  12. slaveof 192.168.92.128 6379 
  13.  
  14. #redis-6381.conf 
  15. port 6381 
  16. daemonize yes 
  17. logfile "6381.log" 
  18. dbfilename "dump-6381.rdb" 
  19. slaveof 192.168.92.128 6379 

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

  1. redis-server redis-6379.conf 
  2. redis-server redis-6380.conf 
  3. redis-server redis-6381.conf 

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

部署哨兵節(jié)點

哨兵節(jié)點本質(zhì)上是特殊的 Redis 節(jié)點。3 個哨兵節(jié)點的配置幾乎是完全一樣的,主要區(qū)別在于端口號的不同(26379/26380/26381)。

下面以 26379 節(jié)點為例,介紹節(jié)點的配置和啟動方式,配置部分盡量簡化,更多配置會在后面介紹。

  1. #sentinel-26379.conf 
  2. port 26379 
  3. daemonize yes 
  4. logfile "26379.log" 
  5. 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é)點的故障判定有關(guān):至少需要 2 個哨兵節(jié)點同意,才能判定主節(jié)點故障并進行故障轉(zhuǎn)移。

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

  1. redis-sentinel sentinel-26379.conf 
  2. redis-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ù)與配置紀(jì)元有關(guān)(配置紀(jì)元是一個從 0 開始的計數(shù)器,每進行一次***哨兵選舉,都會 +1;***哨兵選舉是故障轉(zhuǎn)移階段的一個操作,在后文原理部分會介紹)。

演示故障轉(zhuǎn)移

哨兵的四個作用中,配置提供者和通知需要客戶端的配合,本文將在下一章介紹客戶端訪問哨兵系統(tǒng)的方法時再詳細(xì)介紹。

這一小節(jié)將演示當(dāng)主節(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é)點認(rèn)為新的主節(jié)點仍然有 2 個從節(jié)點,這是因為哨兵在將 6380 切換成主節(jié)點的同時,將 6379 節(jié)點置為其從節(jié)點。

雖然 6379 從節(jié)點已經(jīng)掛掉,但是由于哨兵并不會對從節(jié)點進行客觀下線(其含義將在原理部分介紹),因此認(rèn)為該從節(jié)點一直存在。

當(dāng) 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é)點信息的變化,紀(jì)元(epoch)也會變化,下圖中可以看到紀(jì)元相關(guān)的參數(shù)都 +1 了。

小結(jié)

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

  • 哨兵系統(tǒng)中的主從節(jié)點,與普通的主從節(jié)點并沒有什么區(qū)別,故障發(fā)現(xiàn)和轉(zhuǎn)移是由哨兵來控制和完成的。
  • 哨兵節(jié)點本質(zhì)上是 Redis 節(jié)點。
  • 每個哨兵節(jié)點,只需要配置監(jiān)控主節(jié)點,便可以自動發(fā)現(xiàn)其他的哨兵節(jié)點和從節(jié)點。
  • 在哨兵節(jié)點啟動和故障轉(zhuǎn)移階段,各個節(jié)點的配置文件會被重寫(config rewrite)。
  • 本章的例子中,一個哨兵只監(jiān)控了一個主節(jié)點;實際上,一個哨兵可以監(jiān)控多個主節(jié)點,通過配置多條 sentinel monitor 即可實現(xiàn)。

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

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

代碼示例

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

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

客戶端原理

Jedis 客戶端對哨兵提供了很好的支持。如上述代碼所示,我們只需要向 Jedis 提供哨兵節(jié)點集合和 masterName,構(gòu)造 JedisSentinelPool 對象。

然后便可以像使用普通 Redis 連接池一樣來使用了:通過 pool.getResource() 獲取連接,執(zhí)行具體的命令。

在整個過程中,我們的代碼不需要顯式的指定主節(jié)點的地址,就可以連接到主節(jié)點;代碼中對故障轉(zhuǎn)移沒有任何體現(xiàn),就可以在哨兵完成故障轉(zhuǎn)移后自動的切換主節(jié)點。

之所以可以做到這一點,是因為在 JedisSentinelPool 的構(gòu)造器中,進行了相關(guān)的工作;主要包括以下兩點:

遍歷哨兵節(jié)點,獲取主節(jié)點信息:遍歷哨兵節(jié)點,通過其中一個哨兵節(jié)點 + masterName 獲得主節(jié)點的信息。

該功能是通過調(diào)用哨兵節(jié)點的 sentinelget-master-addr-by-name 命令實現(xiàn),該命令示例如下:

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

增加對哨兵的監(jiān)聽:這樣當(dāng)發(fā)生故障轉(zhuǎn)移時,客戶端便可以收到哨兵的通知,從而完成主節(jié)點的切換。

具體做法是:利用 Redis 提供的發(fā)布訂閱功能,為每一個哨兵節(jié)點開啟一個單獨的線程,訂閱哨兵節(jié)點的 + switch-master 頻道,當(dāng)收到消息時,重新初始化連接池。

小結(jié)

通過客戶端原理的介紹,我們可以加深對哨兵功能的理解。

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

需要注意的是,哨兵只是配置提供者,而不是代理。二者的區(qū)別在于:

  • 如果是配置提供者,客戶端在通過哨兵獲得主節(jié)點信息后,會直接建立到主節(jié)點的連接,后續(xù)的請求(如 set/get)會直接發(fā)向主節(jié)點。
  • 如果是代理,客戶端的每一次請求都會發(fā)向哨兵,哨兵再通過主節(jié)點處理請求。

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

  1. sentinel monitor mymaster 192.168.92.128 6379 2 
  2. 改為 
  3. 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)了。

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

哨兵實現(xiàn)的基本原理

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

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

哨兵節(jié)點作為運行在特殊模式下的 Redis 節(jié)點,其支持的命令與普通的 Redis 節(jié)點不同。

在運維中,我們可以通過這些命令查詢或修改哨兵系統(tǒng);不過更重要的是,哨兵系統(tǒng)要實現(xiàn)故障發(fā)現(xiàn)、故障轉(zhuǎn)移等各種功能,離不開哨兵節(jié)點之間的通信。

而通信的很大一部分是通過哨兵節(jié)點支持的命令來實現(xiàn)的。下面介紹哨兵節(jié)點支持的主要命令。

基礎(chǔ)查詢

通過這些命令,可以查詢哨兵系統(tǒng)的拓?fù)浣Y(jié)構(gòu)、節(jié)點信息、配置信息等:

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

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

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

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

強制故障轉(zhuǎn)移

sentinel failover mymaster:該命令可以強制對 mymaster 執(zhí)行故障轉(zhuǎn)移,即便當(dāng)前的主節(jié)點運行完好。

例如,如果當(dāng)前主節(jié)點所在機器即將報廢,便可以提前通過failover命令進行故障轉(zhuǎn)移。

基本原理

關(guān)于哨兵的原理,關(guān)鍵是了解以下幾個概念。

定時任務(wù)

每個哨兵節(jié)點維護了 3 個定時任務(wù),定時任務(wù)的功能分別如下:

  • 通過向主從節(jié)點發(fā)送 info 命令獲取***的主從結(jié)構(gòu)。
  • 通過發(fā)布訂閱功能獲取其他哨兵節(jié)點的信息。
  • 通過向其他節(jié)點發(fā)送 ping 命令進行心跳檢測,判斷是否下線。

主觀下線

在心跳檢測的定時任務(wù)中,如果其他節(jié)點超過一定時間沒有回復(fù),哨兵節(jié)點就會將其進行主觀下線。

顧名思義,主觀下線的意思是一個哨兵節(jié)點“主觀地”判斷下線;與主觀下線相對應(yīng)的是客觀下線。

客觀下線

哨兵節(jié)點在對主節(jié)點進行主觀下線后,會通過 sentinelis-master-down-by-addr 命令詢問其他哨兵節(jié)點該主節(jié)點的狀態(tài)。

如果判斷主節(jié)點下線的哨兵數(shù)量達(dá)到一定數(shù)值,則對該主節(jié)點進行客觀下線。

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

選舉***哨兵節(jié)點

當(dāng)主節(jié)點被判斷客觀下線以后,各個哨兵節(jié)點會進行協(xié)商,選舉出一個***哨兵節(jié)點,并由該***節(jié)點對其進行故障轉(zhuǎn)移操作。

監(jiān)視該主節(jié)點的所有哨兵都有可能被選為***,選舉使用的算法是 Raft 算法。

Raft 算法的基本思路是先到先得:即在一輪選舉中,哨兵 A 向 B 發(fā)送成為***的申請,如果 B 沒有同意過其他哨兵,則會同意 A 成為***。

選舉的具體過程這里不做詳細(xì)描述,一般來說,哨兵選擇的過程很快,誰先完成客觀下線,一般就能成為***。

故障轉(zhuǎn)移

選舉出的***哨兵,開始進行故障轉(zhuǎn)移操作,該操作大體可以分為 3 個步驟:

  • 在從節(jié)點中選擇新的主節(jié)點:選擇的原則是,首先過濾掉不健康的從節(jié)點,然后選擇優(yōu)先級***的從節(jié)點(由 slave-priority 指定)。

如果優(yōu)先級無法區(qū)分,則選擇復(fù)制偏移量***的從節(jié)點;如果仍無法區(qū)分,則選擇 runid 最小的從節(jié)點。

  • 更新主從狀態(tài):通過 slaveof no one 命令,讓選出來的從節(jié)點成為主節(jié)點;并通過 slaveof 命令讓其他節(jié)點成為其從節(jié)點。
  • 將已經(jīng)下線的主節(jié)點(即 6379)設(shè)置為新的主節(jié)點的從節(jié)點,當(dāng) 6379 重新上線后,它會成為新的主節(jié)點的從節(jié)點。

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

哨兵配置與實踐建議

哨兵配置

下面介紹與哨兵相關(guān)的幾個配置。

sentinel monitor {masterName} {masterIp} {masterPort}{quorum}

sentinel monitor 是哨兵最核心的配置,在前文講述部署哨兵節(jié)點時已說明,其中:masterName 指定了主節(jié)點名稱,masterIp 和 masterPort 指定了主節(jié)點地址,quorum 是判斷主節(jié)點客觀下線的哨兵數(shù)量閾值。

當(dāng)判定主節(jié)點下線的哨兵數(shù)量達(dá)到 quorum 時,對主節(jié)點進行客觀下線。建議取值為哨兵數(shù)量的一半加 1。

sentinel down-after-milliseconds {masterName} {time}

sentinel down-after-milliseconds 與主觀下線的判斷有關(guān):哨兵使用 ping 命令對其他節(jié)點進行心跳檢測。

如果其他節(jié)點超過 down-after-milliseconds 配置的時間沒有回復(fù),哨兵就會將其進行主觀下線,該配置對主節(jié)點、從節(jié)點和哨兵節(jié)點的主觀下線判定都有效。

down-after-milliseconds 的默認(rèn)值是 30000,即 30s;可以根據(jù)不同的網(wǎng)絡(luò)環(huán)境和應(yīng)用要求來調(diào)整。

值越大,對主觀下線的判定會越寬松,好處是誤判的可能性小,壞處是故障發(fā)現(xiàn)和故障轉(zhuǎn)移的時間變長,客戶端等待的時間也會變長。

例如,如果應(yīng)用對可用性要求較高,則可以將值適當(dāng)調(diào)小,當(dāng)故障發(fā)生時盡快完成轉(zhuǎn)移;如果網(wǎng)絡(luò)環(huán)境相對較差,可以適當(dāng)提高該閾值,避免頻繁誤判。

sentinel parallel-syncs {masterName} {number}

sentinel parallel-syncs 與故障轉(zhuǎn)移之后從節(jié)點的復(fù)制有關(guān):它規(guī)定了每次向新的主節(jié)點發(fā)起復(fù)制操作的從節(jié)點個數(shù)。

例如,假設(shè)主節(jié)點切換完成之后,有 3 個從節(jié)點要向新的主節(jié)點發(fā)起復(fù)制;如果 parallel-syncs=1,則從節(jié)點會一個一個開始復(fù)制;如果 parallel-syncs=3,則 3 個從節(jié)點會一起開始復(fù)制。

parallel-syncs 取值越大,從節(jié)點完成復(fù)制的時間越快,但是對主節(jié)點的網(wǎng)絡(luò)負(fù)載、硬盤負(fù)載造成的壓力也越大;應(yīng)根據(jù)實際情況設(shè)置。

例如,如果主節(jié)點的負(fù)載較低,而從節(jié)點對服務(wù)可用的要求較高,可以適量增加 parallel-syncs 取值。parallel-syncs 的默認(rèn)值是 1。

sentinel failover-timeout {masterName} {time}

sentinel failover-timeout 與故障轉(zhuǎn)移超時的判斷有關(guān),但是該參數(shù)不是用來判斷整個故障轉(zhuǎn)移階段的超時,而是其幾個子階段的超時。

例如如果主節(jié)點晉升從節(jié)點時間超過 timeout,或從節(jié)點向新的主節(jié)點發(fā)起復(fù)制操作的時間(不包括復(fù)制數(shù)據(jù)的時間)超過 timeout,都會導(dǎo)致故障轉(zhuǎn)移超時失敗。

failover-timeout 的默認(rèn)值是 180000,即 180s;如果超時,則下一次該值會變?yōu)樵瓉淼?2 倍。

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

實踐建議

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

哨兵節(jié)點的數(shù)量應(yīng)該是奇數(shù),便于哨兵通過投票做出“決策”:***選舉的決策、客觀下線的決策等。

各個哨兵節(jié)點的配置應(yīng)一致,包括硬件、參數(shù)等;此外,所有節(jié)點都應(yīng)該使用 ntp 或類似服務(wù),保證時間準(zhǔn)確、一致。

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

當(dāng)哨兵系統(tǒng)中的節(jié)點在 Docker(或其他可能進行端口映射的軟件)中部署時,應(yīng)特別注意端口映射可能會導(dǎo)致哨兵系統(tǒng)無法正常工作。

因為哨兵的工作基于與其他節(jié)點的通信,而 Docker 的端口映射可能導(dǎo)致哨兵無法連接到其他節(jié)點。

例如,哨兵之間互相發(fā)現(xiàn),依賴于它們對外宣稱的 IP 和 port,如果某個哨兵 A 部署在做了端口映射的 Docker 中,那么其他哨兵使用 A 宣稱的 port 無法連接到 A。

總結(jié)

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

在主從復(fù)制的基礎(chǔ)上,哨兵引入了主節(jié)點的自動故障轉(zhuǎn)移,進一步提高了 Redis 的高可用性。

但是哨兵的缺陷同樣很明顯:哨兵無法對從節(jié)點進行自動故障轉(zhuǎn)移,在讀寫分離場景下,從節(jié)點故障會導(dǎo)致讀服務(wù)不可用,需要我們對從節(jié)點做額外的監(jiān)控、切換操作。

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

參考文獻:

https://redis.io/topics/sentinel

http://www.redis.cn/

《Redis開發(fā)與運維》

《Redis設(shè)計與實現(xiàn)》

【51CTO原創(chuàng)稿件,合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】

 

責(zé)任編輯:武曉燕 來源: 51CTO技術(shù)棧
相關(guān)推薦

2018-07-06 09:58:38

Redis高可用主從復(fù)制

2023-11-12 00:10:07

Redis高可用

2018-10-30 09:38:55

Redis集群實現(xiàn)

2022-05-31 08:04:03

Redis高可用集群

2018-06-12 09:33:45

Redis高可用AOF

2010-08-31 13:06:45

CSS

2021-04-01 08:50:54

SentinelRedis 集群原理

2010-09-25 14:38:18

Java內(nèi)存分配

2019-10-11 10:52:42

Web架構(gòu)MongoDB

2022-06-21 07:51:06

Redis高可用哨兵進程

2010-07-06 10:41:22

UML對象及關(guān)系圖

2024-04-29 08:06:19

Redis分布式系統(tǒng)

2009-11-17 14:13:34

PHP配置

2015-09-29 08:57:46

javascript對象

2019-12-05 10:00:03

架構(gòu)Redis服務(wù)器

2010-09-17 14:17:05

JVM內(nèi)存設(shè)置

2015-09-29 09:27:04

JavaScript對象

2010-06-29 15:29:22

UML建模流程

2017-10-27 14:52:31

互聯(lián)網(wǎng)高可用架構(gòu)高可用

2019-12-24 09:30:59

蘇寧高可用高并發(fā)
點贊
收藏

51CTO技術(shù)棧公眾號

主站蜘蛛池模板: 精品一区久久 | 天天干天天想 | 中文字幕在线一区二区三区 | 一区二区精品 | 91干b| 午夜成人免费视频 | 热re99久久精品国产99热 | 激情视频网站 | 国产精品欧美一区二区 | 91精品久久久久久久久 | 欧日韩不卡在线视频 | 亚洲精品888| 欧美精品福利 | 久久久免费观看视频 | 欧美在线a | 精品国产欧美一区二区三区不卡 | 国产精品久久久久久福利一牛影视 | 九九久久精品视频 | 午夜精品久久久 | 午夜免费精品视频 | 精品国产91乱码一区二区三区 | 久久久久久免费毛片精品 | 天天久久 | 午夜小视频免费观看 | 欧美极品在线 | 日韩av电影在线观看 | 91久色 | 精品在线一区二区 | 欧美日韩亚洲三区 | 久久成人精品视频 | 二区成人 | 国产成人精品一区二区三区在线 | 狠狠爱综合 | 精品粉嫩超白一线天av | 日韩精品视频一区二区三区 | 曰韩一二三区 | 综合色在线 | 91精品国产综合久久久密闭 | 中国一级特黄真人毛片 | 91视频观看| 黄色三级免费网站 |