Redis全方位講解--哨兵模式（Sentinel模式）(轉載)
前言
當按照上一篇《redis主從復制》部署好之後，我們會想，一旦redis的master出現了宕機，並且我們並沒有及時發現，這時候就可能會出現數據丟失或程序無法運行。此時，redis的哨兵模式就派上用場了，可以用它來做redis的高可用。
功能作用
- 監控(monitoring)：Sentinel 會不斷地檢查你的主服務器和從服務器是否運作正常。
- 提醒(Notifation)：當被監控的某個 Redis 服務器出現問題時， Sentinel 可以通過 API 向管理員或者其他應用程序發送通知。
- 自動故障轉移(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 模式。
作者:JohnsonChung
轉載URL: https://www.cnblogs.com/johnson108178/p/9888482.htmlRedis全方位講解--哨兵模式（Sentinel模式）(轉載)