背景

在生產(chǎn)環(huán)境中，為了保證redis服務(wù)的高可用，通常都會(huì)搭建主從。我們知道主從的原理是從服務(wù)器獲取rdb文件的全量復(fù)制+寫(xiě)操作的增量復(fù)制來(lái)共同保證數(shù)據(jù)的一致性，所以在配置從服務(wù)器的時(shí)候，一個(gè)很重要的配置項(xiàng)就是標(biāo)明主服務(wù)器的ip和端口號(hào)，總得知道哪一臺(tái)服務(wù)器是我的主子不是，像下圖中的replicaof配置。

對(duì)于圖中的部署方案，如果主服務(wù)器宕機(jī)了，我們只能進(jìn)行手動(dòng)干預(yù)，選擇一臺(tái)從服務(wù)器重新作為主服務(wù)器，然后將另外的兩臺(tái)從服務(wù)器的配置文件修改一下，將replicaof的配置重新改成新的主服務(wù)器地址。人工干預(yù)費(fèi)時(shí)費(fèi)力不說(shuō)，更重要的是，這樣會(huì)造成一段時(shí)間內(nèi)服務(wù)是不可用的。在這種場(chǎng)景下，哨兵模式應(yīng)運(yùn)而生了。

什么是哨兵模式Sentinel

redis的哨兵模式，就是用于在一主多從的集群環(huán)境下，如果主服務(wù)器宕機(jī)了，它會(huì)自動(dòng)的將從服務(wù)器中的一臺(tái)設(shè)為新的master，并且將其余的slave的配置文件自動(dòng)修改，這樣就切換出一套新的主從服務(wù)，不需要人工干預(yù)，且不會(huì)影響服務(wù)的使用。

那么它具體是怎么工作的呢？首先看下面這張圖：

哨兵模式結(jié)構(gòu)圖

首先哨兵是一個(gè)獨(dú)立于主從服務(wù)之外的服務(wù)，它也是一個(gè)集群服務(wù)。哨兵實(shí)例會(huì)不斷給主服務(wù)器發(fā)送Ping命令，主服務(wù)器在收到命令后，返回一個(gè)有效回復(fù)，這樣哨兵實(shí)例認(rèn)為服務(wù)器是正常的。

主觀下線

假設(shè)主服務(wù)器宕機(jī)，哨兵1在指定時(shí)間內(nèi)(可配置)沒(méi)有收到主服務(wù)器的有效回復(fù)，那么這個(gè)哨兵會(huì)把服務(wù)器標(biāo)記為下線，叫做主觀下線SDOWN。

注意此時(shí)只有一個(gè)哨兵標(biāo)記為下線，實(shí)際上哨兵沒(méi)有收到回復(fù)原因可能有很多，可能是服務(wù)器確實(shí)掛了，也有可能是服務(wù)器并沒(méi)有掛，由于網(wǎng)絡(luò)原因沒(méi)有收到回復(fù)，總之，一個(gè)哨兵沒(méi)有收到回復(fù)并不能證明主服務(wù)器宕機(jī)。

客觀下線

哨兵2也發(fā)送了Ping命令，同樣也沒(méi)有收到回復(fù)，哨兵2也會(huì)將主服務(wù)器標(biāo)記為SDOWN。這個(gè)時(shí)候，3個(gè)哨兵中有2個(gè)哨兵上報(bào)了SDOWN，哨兵們?cè)诒舜私涣髦螅J(rèn)為已經(jīng)有足夠數(shù)量的實(shí)例證明該服務(wù)已經(jīng)不可用，因此，哨兵實(shí)例會(huì)將該服務(wù)器標(biāo)記為客觀下線ODOWN。

這里的足夠數(shù)量是可配置的，一般是哨兵個(gè)數(shù)的一半加1，比如3個(gè)哨兵則就設(shè)置為2。

投票選舉，故障轉(zhuǎn)移

當(dāng)哨兵實(shí)例將服務(wù)標(biāo)記為客觀下線時(shí)，會(huì)進(jìn)行一次選舉。在剩下的從服務(wù)器實(shí)例中，選出一個(gè)作為主節(jié)點(diǎn)，并同時(shí)修改其余從服務(wù)器的配置文件，將新的主節(jié)點(diǎn)作為數(shù)據(jù)同步的來(lái)源，然后重新啟動(dòng)服務(wù)，完成切換。

至此，一個(gè)完整的哨兵自動(dòng)進(jìn)行故障轉(zhuǎn)移的過(guò)程就完成了。

springboot配置一主多從+哨兵

如果我們的環(huán)境由主從換成了主從+哨兵，修改配置也比較簡(jiǎn)單，先注釋掉原來(lái)的host和port的配置，替換成哨兵的配置，如下圖：

需要注意的是，這里nodes里配置的是哨兵集群的IP+端口，而不是主從節(jié)點(diǎn)，一定不要配錯(cuò)了。