【深度知識(shí)】Redis高可用架構(gòu)之哨兵原理及實(shí)踐

摘要

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

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

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

哨兵的作用

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

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

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

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

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

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

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

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

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

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

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

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

哨兵的架構(gòu)

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

它由兩部分組成,哨兵節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn):

  • 哨兵節(jié)點(diǎn):哨兵系統(tǒng)由一個(gè)或多個(gè)哨兵節(jié)點(diǎn)組成,哨兵節(jié)點(diǎn)是特殊的 Redis 節(jié)點(diǎn),不存儲(chǔ)數(shù)據(jù)。
  • 數(shù)據(jù)節(jié)點(diǎn):主節(jié)點(diǎn)和從節(jié)點(diǎn)都是數(shù)據(jù)節(jié)點(diǎn)。

哨兵系統(tǒng)的部署方法

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

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

部署主從節(jié)點(diǎn)

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

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

1.  #redis-6379.conf 
2.  port 6379 
3.  daemonize yes 
4.  logfile "6379.log" 
5.  dbfilename "dump-6379.rdb" 

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 

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 

配置完成后,依次啟動(dòng)主節(jié)點(diǎn)和從節(jié)點(diǎn):

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

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

部署哨兵節(jié)點(diǎn)

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

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


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é)點(diǎn)監(jiān)控 192.168.92.128:6379 這個(gè)主節(jié)點(diǎn)。

該主節(jié)點(diǎn)的名稱是 mymaster,***的 2 的含義與主節(jié)點(diǎn)的故障判定有關(guān):至少需要 2 個(gè)哨兵節(jié)點(diǎn)同意,才能判定主節(jié)點(diǎn)故障并進(jìn)行故障轉(zhuǎn)移。

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

1.  redis-sentinel sentinel-26379.conf 
2.  redis-server sentinel-26379.conf --sentinel 

按照上述方式配置和啟動(dòng)之后,整個(gè)哨兵系統(tǒng)就啟動(dòng)完畢了,可以通過 redis-cli 連接哨兵節(jié)點(diǎn)進(jìn)行驗(yàn)證。

如下圖所示:可以看出 26379 哨兵節(jié)點(diǎn)已經(jīng)在監(jiān)控 mymaster 主節(jié)點(diǎn)(即192.168.92.128:6379),并發(fā)現(xiàn)了其 2 個(gè)從節(jié)點(diǎn)和另外 2 個(gè)哨兵節(jié)點(diǎn)。

此時(shí)如果查看哨兵節(jié)點(diǎn)的配置文件,會(huì)發(fā)現(xiàn)一些變化,以 26379 為例:

其中,dir 只是顯式聲明了數(shù)據(jù)和日志所在的目錄(在哨兵語境下只有日志);known-slave 和 known-sentinel 顯示哨兵已經(jīng)發(fā)現(xiàn)了從節(jié)點(diǎn)和其他哨兵。

帶有 epoch 的參數(shù)與配置紀(jì)元有關(guān)(配置紀(jì)元是一個(gè)從 0 開始的計(jì)數(shù)器,每進(jìn)行一次哨兵選舉,都會(huì) +1;哨兵選舉是故障轉(zhuǎn)移階段的一個(gè)操作,在后文原理部分會(huì)介紹)。

演示故障轉(zhuǎn)移

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

這一小節(jié)將演示當(dāng)主節(jié)點(diǎn)發(fā)生故障時(shí),哨兵的監(jiān)控和自動(dòng)故障轉(zhuǎn)移功能。

(1)首先,使用 Kill 命令殺掉主節(jié)點(diǎn):

(2)如果此時(shí)立即在哨兵節(jié)點(diǎn)中使用 info Sentinel 命令查看,會(huì)發(fā)現(xiàn)主節(jié)點(diǎn)還沒有切換過來,因?yàn)樯诒l(fā)現(xiàn)主節(jié)點(diǎn)故障并轉(zhuǎn)移,需要一段時(shí)間。

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

但是同時(shí)可以發(fā)現(xiàn),哨兵節(jié)點(diǎn)認(rèn)為新的主節(jié)點(diǎn)仍然有 2 個(gè)從節(jié)點(diǎn),這是因?yàn)樯诒趯?6380 切換成主節(jié)點(diǎn)的同時(shí),將 6379 節(jié)點(diǎn)置為其從節(jié)點(diǎn)。

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

當(dāng) 6379 節(jié)點(diǎn)重新啟動(dòng)后,會(huì)自動(dòng)變成 6380 節(jié)點(diǎn)的從節(jié)點(diǎn),下面驗(yàn)證一下。

(4)重啟 6379 節(jié)點(diǎn):可以看到 6379 節(jié)點(diǎn)成為了 6380 節(jié)點(diǎn)的從節(jié)點(diǎn)。

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

對(duì)于主從節(jié)點(diǎn),主要是 slaveof 配置的變化:新的主節(jié)點(diǎn)沒有了 slaveof 配置,其從節(jié)點(diǎn)則 slaveof 新的主節(jié)點(diǎn)。

對(duì)于哨兵節(jié)點(diǎn),除了主從節(jié)點(diǎn)信息的變化,紀(jì)元(epoch)也會(huì)變化,下圖中可以看到紀(jì)元相關(guān)的參數(shù)都 +1 了。

小結(jié)

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

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

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

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

代碼示例

在介紹客戶端的原理之前,先以 Java 客戶端 Jedis 為例,演示一下使用方法:下面代碼可以連接我們剛剛搭建的哨兵系統(tǒng),并進(jìn)行各種讀寫操作(代碼中只演示如何連接哨兵,異常處理、資源關(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"); 

8.  JedisSentinelPool pool = new JedisSentinelPool(masterName, sentinels); //初始化過程做了很多工作 
9.  Jedis jedis = pool.getResource(); 
10.  jedis.set("key1", "value1"); 
11.  pool.close(); 
12.  } 

客戶端原理

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

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

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

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

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

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

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

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

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

小結(jié)

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

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

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

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

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

1.  sentinel monitor mymaster 192.168.92.128 6379 2 
2.  改為 
3.  sentinel monitor mymaster 127.0.0.1 6379 2 

然后,將前述客戶端代碼在局域網(wǎng)的另外一臺(tái)機(jī)器上運(yùn)行,會(huì)發(fā)現(xiàn)客戶端無法連接主節(jié)點(diǎn)。

這是因?yàn)樯诒鳛榕渲锰峁┱?,客戶端通過它查詢到主節(jié)點(diǎn)的地址為 127.0.0.1:6379,客戶端會(huì)向 127.0.0.1:6379 建立 Redis 連接,自然無法連接。如果哨兵是代理,這個(gè)問題就不會(huì)出現(xiàn)了。

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

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

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

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

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

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

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

基礎(chǔ)查詢

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

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

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

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

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

強(qiáng)制故障轉(zhuǎn)移

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

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

基本原理

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

定時(shí)任務(wù)

每個(gè)哨兵節(jié)點(diǎn)維護(hù)了 3 個(gè)定時(shí)任務(wù),定時(shí)任務(wù)的功能分別如下:

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

主觀下線

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

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

客觀下線

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

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

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

選舉哨兵節(jié)點(diǎn)

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

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

Raft 算法的基本思路是先到先得:即在一輪選舉中,哨兵 A 向 B 發(fā)送成為主哨兵節(jié)點(diǎn)的申請(qǐng),如果 B 沒有同意過其他哨兵,則會(huì)同意 A 成為主哨兵節(jié)點(diǎn)。

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

故障轉(zhuǎn)移

選舉出的主哨兵節(jié)點(diǎn),開始進(jìn)行故障轉(zhuǎn)移操作,該操作大體可以分為 3 個(gè)步驟:

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

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

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

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

哨兵配置與實(shí)踐建議

哨兵配置

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

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

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

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

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

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

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

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

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

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

sentinel parallel-syncs {masterName} {number}

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

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

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

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

sentinel failover-timeout {masterName} {time}

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

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

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

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

實(shí)踐建議

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

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

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

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

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

因?yàn)樯诒墓ぷ骰谂c其他節(jié)點(diǎn)的通信,而 Docker 的端口映射可能導(dǎo)致哨兵無法連接到其他節(jié)點(diǎn)。

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

總結(jié)

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

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

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

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

參考文獻(xiàn):

https://redis.io/topics/sentinel
http://www.redis.cn/
《Redis開發(fā)與運(yùn)維》
《Redis設(shè)計(jì)與實(shí)現(xiàn)》

本文轉(zhuǎn)載自51CTO.com的《深入學(xué)習(xí)Redis高可用架構(gòu):哨兵原理及實(shí)踐》http://developer.51cto.com/art/201809/583104.htm

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點(diǎn),簡(jiǎn)書系信息發(fā)布平臺(tái),僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 本文將要介紹的哨兵,它基于 Redis 主從復(fù)制,主要作用便是解決主節(jié)點(diǎn)故障恢復(fù)的自動(dòng)化問題,進(jìn)一步提高系統(tǒng)的高可...
    java成功之路閱讀 2,262評(píng)論 0 4
  • Redis-哨兵機(jī)制 一、主從復(fù)制的問題我們講了 Redis 復(fù)制的主要內(nèi)容,但 Redis 復(fù)制有一個(gè)缺點(diǎn),當(dāng)主...
    心似南風(fēng)閱讀 2,981評(píng)論 1 1
  • Redis 復(fù)制有一個(gè)缺點(diǎn),當(dāng)主機(jī) Master 宕機(jī)以后,我們需要人工解決切換,比如使用slaveof no o...
    firstsecret閱讀 2,499評(píng)論 0 0
  • 前言 Redis是一個(gè)高性能的key-value數(shù)據(jù)庫(kù),現(xiàn)時(shí)越來越多企業(yè)與應(yīng)用使用Redis作為緩存服務(wù)器。樓主是...
    liangzzz閱讀 4,437評(píng)論 9 152
  • 一直以來,我覺得我做得力所能及的事是應(yīng)盡的孝道,而現(xiàn)在時(shí)間長(zhǎng)了我就好似融入了這平淡無奇的生活,我討厭的自己的...
    ?音閱讀 244評(píng)論 0 0

友情鏈接更多精彩內(nèi)容