前言

　　當按照上一篇《redis主從複製》部署好之後，我們會想，一旦redis的master出現了宕機，並且我們並沒有及時發現，這時候就可能會出現資料丟失或程式無法執行。此時，redis的哨兵模式就派上用場了，可以用它來做redis的高可用。

功能作用

1. 監控(monitoring)：Sentinel 會不斷地檢查你的主伺服器和從伺服器是否運作正常。
2. 提醒(Notifation)：當被監控的某個 Redis 伺服器出現問題時， Sentinel 可以通過 API 向管理員或者其他應用程式傳送通知。
3. 自動故障轉移(Automatic failover)：當一個主伺服器不能正常工作時， Sentinel 會開始一次自動故障遷移操作， 它會將失效主伺服器的其中一個從伺服器升級為新的主伺服器， 並讓失效主伺服器的其他從伺服器改為複製新的主伺服器； 當客戶端試圖連線失效的主伺服器時， 叢集也會向客戶端返回新主伺服器的地址， 使得叢集可以使用新主伺服器代替失效伺服器。

部署

　　同樣，我們還是將每個哨兵部署在一個單獨的容器中。

　　sentinel配置檔案

　　redis-sentinel1:https://github.com/Johnson19900110/johnsondock/blob/master/redis-sentinel/config/sentinel.conf

　　redis-sentinel2:https://github.com/Johnson19900110/johnsondock/blob/master/redis-sentinel/config/sentinel-slave1.conf

　　redis-sentinel3:https://github.com/Johnson19900110/johnsondock/blob/master/redis-sentinel/config/sentinel-slave2.conf

　　這三個配置檔案一模一樣，都是監聽master的。要不你把這個配置檔案copy到容器中，要不你就建立三份，分別掛載到容器中，這裡選擇了後面一種方法。

　　這裡介紹幾個基本的配置

　　　　sentinel monitor mymaster redis 6379 2 監聽的master的容器別名為redis，埠是6379，最後面的2是當大於等於2個哨兵認為master主觀下線後（無論這個值為多少，至少得有一半以上的哨兵判定master主觀下線後，master才會被客觀下線），master才會被客觀下線，這是sentinel重新從slave中選舉一個來當master。

　　　　sentinel auth-pass mymaster 123456

　　docker-composer配置檔案

### REDIS-SENTINEL ################################################
  # master
  redis-sentinel:
    image: johnson19900110/redis-sentinel:latest
    restart: always　　#如果master未開啟資料持久化，此項應該刪除
    volumes:
      - ./redis-sentinel/config/sentinel.conf:/usr/local/etc/redis/redis-sentinel.conf
    networks:
      - backend
    depends_on:
      - redis

  # redis sentinel slave 1
  redis-sentinel-slave1:
    image: johnson19900110/redis-sentinel:latest
    restart: always
    volumes:
      - ./redis-sentinel/config/sentinel-slave1.conf:/usr/local/etc/redis/redis-sentinel.conf
    networks:
      - backend
    depends_on:
      - redis-slave1
      - redis-sentinel

  # redis sentinel slave 2
  redis-sentinel-slave2:
    image: johnson19900110/redis-sentinel:latest
    restart: always
    volumes:
      - ./redis-sentinel/config/sentinel-slave2.conf:/usr/local/etc/redis/redis-sentinel.conf
    networks:
      - backend
    depends_on:
      - redis-slave2
      - redis-sentinel-slave1

　　啟動容器

docker-compose up -d redis-sentinel-slave2

執行以上命令後，就啟動了三個哨兵模式的容器

這是我們進入容器，檢視是否redis-sentinel是否在工作。 

我們可看到，已經與master建立連線，通過status=ok可以知道，master正在正常工作，並且有2個從節點和3個哨兵節點。現在你再開啟sentinel的配置檔案，會發現發生了改變。

conf檔案被重寫了，並且哨兵模式會自動檢測到master的兩個slave和另外兩個sentinel。

故障演示

　　1、使master宕機，只需要關閉master的容器即可。 

如果此時再去三個哨兵節點裡用info sentinel檢視資訊。

會發現這時候master節點的address資訊變了，這就說明哨兵模式起作用了。但他這裡還是顯示新的master有兩個slave。是因為原master節點宕機了，一旦它重啟，sentinel就會把它變成新的master節點的slave節點。我們可以去172.18.0.6這個容器中看下。

可以用以上docker命令檢視容器的IP地址。進入容器後，還是在redis-cli下用info replication檢視資訊。 

我們可以看到這個slave變成了新的master，另外一個slave也變成了新master節點的slave。如果你檢視redis節點的配置檔案，會發現也被重寫了。 這是我們再重啟原master節點試試（注意：當他重啟成功後，就變成了slave節點，所以要開啟持久化配置）。

當容器重啟成功後，我們再去新的master節點中使用info replication檢視下。

正如我們所料，它成為了新的master的slave節點。如果你檢視原master的配置檔案，會發現多了 

最後，因為新的master節點是slave節點升級的，所以他的持久化配置還是存在的，如果你想要關掉它，只需要進入redis-cli，然後執行

至此，一次redis的master節點故障轉移就演示完成了。這次演示實現了redis的監控和自動故障轉移特性。

提醒特性是使用的訂閱功能，需要後端程式碼開發配合的。

釋出與訂閱資訊

客戶端可以將 Sentinel 看作是一個只提供了訂閱功能的 Redis 伺服器： 你不可以使用 PUBLISH 命令向這個伺服器傳送資訊， 但你可以用 SUBSCRIBE 命令或者 PSUBSCRIBE 命令， 通過訂閱給定的頻道來獲取相應的事件提醒。

一個頻道能夠接收和這個頻道的名字相同的事件。 比如說， 名為 +sdown 的頻道就可以接收所有例項進入主觀下線（SDOWN）狀態的事件。

通過執行 PSUBSCRIBE * 命令可以接收所有事件資訊。

以下列出的是客戶端可以通過訂閱來獲得的頻道和資訊的格式： 第一個英文單詞是頻道/事件的名字， 其餘的是資料的格式。

注意， 當格式中包含 instance details 字樣時， 表示頻道所返回的資訊中包含了以下用於識別目標例項的內容：

@ 字元之後的內容用於指定主伺服器， 這些內容是可選的， 它們僅在 @ 字元之前的內容指定的例項不是主伺服器時使用。

• +reset-master ：主伺服器已被重置。
• +slave ：一個新的從伺服器已經被 Sentinel 識別並關聯。
• +failover-state-reconf-slaves ：故障轉移狀態切換到了 reconf-slaves 狀態。
• +failover-detected ：另一個 Sentinel 開始了一次故障轉移操作，或者一個從伺服器轉換成了主伺服器。
• +slave-reconf-sent ：領頭（leader）的 Sentinel 向例項傳送了 [SLAVEOF](/commands/slaveof.html) 命令，為例項設定新的主伺服器。
• +slave-reconf-inprog ：例項正在將自己設定為指定主伺服器的從伺服器，但相應的同步過程仍未完成。
• +slave-reconf-done ：從伺服器已經成功完成對新主伺服器的同步。
• -dup-sentinel ：對給定主伺服器進行監視的一個或多個 Sentinel 已經因為重複出現而被移除 —— 當 Sentinel 例項重啟的時候，就會出現這種情況。
• +sentinel ：一個監視給定主伺服器的新 Sentinel 已經被識別並新增。
• +sdown ：給定的例項現在處於主觀下線狀態。
• -sdown ：給定的例項已經不再處於主觀下線狀態。
• +odown ：給定的例項現在處於客觀下線狀態。
• -odown ：給定的例項已經不再處於客觀下線狀態。
• +new-epoch ：當前的紀元（epoch）已經被更新。
• +try-failover ：一個新的故障遷移操作正在執行中，等待被大多數 Sentinel 選中（waiting to be elected by the majority）。
• +elected-leader ：贏得指定紀元的選舉，可以進行故障遷移操作了。
• +failover-state-select-slave ：故障轉移操作現在處於 select-slave 狀態 —— Sentinel 正在尋找可以升級為主伺服器的從伺服器。
• no-good-slave ：Sentinel 操作未能找到適合進行升級的從伺服器。Sentinel 會在一段時間之後再次嘗試尋找合適的從伺服器來進行升級，又或者直接放棄執行故障轉移操作。
• selected-slave ：Sentinel 順利找到適合進行升級的從伺服器。
• failover-state-send-slaveof-noone ：Sentinel 正在將指定的從伺服器升級為主伺服器，等待升級功能完成。
• failover-end-for-timeout ：故障轉移因為超時而中止，不過最終所有從伺服器都會開始複製新的主伺服器（slaves will eventually be configured to replicate with the new master anyway）。
• failover-end ：故障轉移操作順利完成。所有從伺服器都開始複製新的主伺服器了。
• +switch-master ：配置變更，主伺服器的 IP 和地址已經改變。 這是絕大多數外部使用者都關心的資訊。
• +tilt ：進入 tilt 模式。
• -tilt ：退出 tilt 模式。