Redis全方位講解--哨兵模式（Sentinel模式）
前言
當按照上一篇《redis主從複製》部署好之後，我們會想，一旦redis的master出現了宕機，並且我們並沒有及時發現，這時候就可能會出現資料丟失或程式無法執行。此時，redis的哨兵模式就派上用場了，可以用它來做redis的高可用。
功能作用
- 監控(monitoring) ：Sentinel 會不斷地檢查你的主伺服器和從伺服器是否運作正常。
- 提醒(Notifation) ：當被監控的某個 Redis 伺服器出現問題時， Sentinel 可以通過 API 向管理員或者其他應用程式傳送通知。
- 自動故障轉移(Automatic failover) ：當一個主伺服器不能正常工作時， Sentinel 會開始一次自動故障遷移操作， 它會將失效主伺服器的其中一個從伺服器升級為新的主伺服器， 並讓失效主伺服器的其他從伺服器改為複製新的主伺服器； 當客戶端試圖連線失效的主伺服器時， 叢集也會向客戶端返回新主伺服器的地址， 使得叢集可以使用新主伺服器代替失效伺服器。
部署
同樣，我們還是將每個哨兵部署在一個單獨的容器中。
sentinel配置檔案
redis-sentinel1: ofollow,noindex" target="_blank">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如果master配置了密碼，則此項必須配置，否則sentinel會將master標記問主觀下線(sdown)。
### 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 模式。