背景

在生產環境中，為了保證redis服務的高可用，通常都會搭建主從。我們知道主從的原理是從服務器獲取rdb文件的全量復制+寫操作的增量復制來共同保證數據的一致性，所以在配置從服務器的時候，一個很重要的配置項就是標明主服務器的ip和端口號，總得知道哪一臺服務器是我的主子不是，像下圖中的replicaof配置。

對于圖中的部署方案，如果主服務器宕機了，我們只能進行手動干預，選擇一臺從服務器重新作為主服務器，然后將另外的兩臺從服務器的配置文件修改一下，將replicaof的配置重新改成新的主服務器地址。人工干預費時費力不說，更重要的是，這樣會造成一段時間內服務是不可用的。在這種場景下，哨兵模式應運而生了。

什么是哨兵模式Sentinel

redis的哨兵模式，就是用于在一主多從的集群環境下，如果主服務器宕機了，它會自動的將從服務器中的一臺設為新的master，并且將其余的slave的配置文件自動修改，這樣就切換出一套新的主從服務，不需要人工干預，且不會影響服務的使用。

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

哨兵模式結構圖

首先哨兵是一個獨立于主從服務之外的服務，它也是一個集群服務。哨兵實例會不斷給主服務器發送Ping命令，主服務器在收到命令后，返回一個有效回復，這樣哨兵實例認為服務器是正常的。

主觀下線

假設主服務器宕機，哨兵1在指定時間內(可配置)沒有收到主服務器的有效回復，那么這個哨兵會把服務器標記為下線，叫做主觀下線SDOWN。

注意此時只有一個哨兵標記為下線，實際上哨兵沒有收到回復原因可能有很多，可能是服務器確實掛了，也有可能是服務器并沒有掛，由于網絡原因沒有收到回復，總之，一個哨兵沒有收到回復并不能證明主服務器宕機。

客觀下線

哨兵2也發送了Ping命令，同樣也沒有收到回復，哨兵2也會將主服務器標記為SDOWN。這個時候，3個哨兵中有2個哨兵上報了SDOWN，哨兵們在彼此交流之后，認為已經有足夠數量的實例證明該服務已經不可用，因此，哨兵實例會將該服務器標記為客觀下線ODOWN。

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

投票選舉，故障轉移

當哨兵實例將服務標記為客觀下線時，會進行一次選舉。在剩下的從服務器實例中，選出一個作為主節點，并同時修改其余從服務器的配置文件，將新的主節點作為數據同步的來源，然后重新啟動服務，完成切換。

至此，一個完整的哨兵自動進行故障轉移的過程就完成了。

springboot配置一主多從+哨兵

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

需要注意的是，這里nodes里配置的是哨兵集群的IP+端口，而不是主從節點，一定不要配錯了。