Redis的主從複製模式下， 一旦主節點由於故障不能提供服務， 需要人工將從節點晉升爲主節點， 同時還要通知應用方更新主節點地址， 對於很多應用場景這種故障處理的方式是無法接受的。 可喜的是Redis從2.8開始正式
提供了Redis Sentinel（哨兵） 架構來解決這個問題。
總結：
Redis主從複製的缺點：沒有辦法對master進行動態選舉，需要使用Sentinel機制完成動態選舉
架構圖：
1.哨兵進程的作用
- 監控(Monitoring): 哨兵(sentinel) 會不斷地檢查你的Master和Slave是否運作正常。
- 提醒(Notification):當被監控的某個Redis節點出現問題時, 哨兵(sentinel) 可以通過 API 向管理員或者其他應用程序發送通知。
- 自動故障遷移(Automatic failover)：當一個Master不能正常工作時，哨兵(sentinel) 會開始一次自動故障遷移操作。
它會將失效Master的其中一個Slave升級爲新的Master, 並讓失效Master的其他Slave改爲複製新的Master；
當客戶端試圖連接失效的Master時，集羣也會向客戶端返回新Master的地址，使得集羣可以使用現在的Master替換失效Master。Master和Slave服務器切換後，Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的內容都會發生相應的改變，即，Master主服務器的redis.conf配置文件中會多一行slaveof的配置，sentinel.conf的監控目標會隨之調換。
2.哨兵進程的工作方式
- 每個Sentinel（哨兵）進程以每秒鐘一次的頻率向整個集羣中的Master主服務器，Slave從服務器以及其他Sentinel（哨兵）進程發送一個 PING 命令。
- 如果一個實例（instance）距離最後一次有效回覆 PING 命令的時間超過 down-after-milliseconds 選項所指定的值，則這個實例會被 Sentinel（哨兵）進程標記爲主觀下線（SDOWN）。
- 如果一個Master主服務器被標記爲主觀下線（SDOWN），則正在監視這個Master主服務器的所有
- Sentinel（哨兵）進程要以每秒一次的頻率確認Master主服務器的確進入了主觀下線狀態。
- 當有足夠數量的 Sentinel（哨兵）進程（大於等於配置文件指定的值）在指定的時間範圍內確認Master主服務器進入了主觀下線狀態（SDOWN）， 則Master主服務器會被標記爲客觀下線（ODOWN）。
- 在一般情況下， 每個Sentinel（哨兵）進程會以每 10 秒一次的頻率向集羣中的所有Master主服務器、Slave從服務器發送 INFO 命令。
- 當Master主服務器被 Sentinel（哨兵）進程標記爲客觀下線（ODOWN）時，Sentinel（哨兵）進程向下線的 Master主服務器的所有 Slave從服務器發送 INFO 命令的頻率會從 10 秒一次改爲每秒一次。
- 若沒有足夠數量的 Sentinel（哨兵）進程同意 Master主服務器下線， Master主服務器的客觀下線狀態就會被移除。若 Master主服務器重新向 Sentinel（哨兵）進程發送 PING 命令返回有效回覆，Master主服務器的主觀下線狀態就會被移除。
哨兵模式sentinel.conf配置文件
#當前Sentinel服務運行的端口
port 26379
bind 127.0.0.1
# 哨兵監聽的主服務器
sentinel myid dd6aad6f6f353a4d3105de2e646a06b127354f89
#哨兵模式下一開始主服務器的地址+端口以及可達到客觀下線的sentinel數量
sentinel monitor mymaster 127.0.0.1 6381 2
# 3s內mymaster無響應，則認爲mymaster宕機了，主觀下線
sentinel down-after-milliseconds mymaster 3000
#如果10秒後,mysater仍沒啓動過來，則啓動failover
sentinel failover-timeout mymaster 10000
3、監控
sentinel會每秒一次的頻率與之前創建了命令連接的實例發送PING，包括主服務器、從服務器和sentinel實例，以此來判斷當前實例的狀態。down-after-milliseconds時間內PING連接無效，則將該實例視爲主觀下線。之後該sentinel會向其他監控同一主服務器的sentinel實例詢問是否也將該服務器視爲主觀下線狀態，當超過某quorum後將其視爲客觀下線狀態。
當一個主服務器被某sentinel視爲客觀下線狀態後，該sentinel會與其他sentinel協商選出零頭sentinel進行故障轉移工作。每個發現主服務器進入客觀下線的sentinel都可以要求其他sentinel選自己爲領頭sentinel，選舉是先到先得。同時每個sentinel每次選舉都會自增配置紀元，每個紀元中只會選擇一個領頭sentinel。如果所有超過一半的sentinel選舉某sentinel領頭sentinel。之後該sentinel進行故障轉移操作。
如果一個Sentinel爲了指定的主服務器故障轉移而投票給另一個Sentinel，將會等待一段時間後試圖再次故障轉移這臺主服務器。如果該次失敗另一個將嘗試，Redis Sentinel保證第一個活性(liveness)屬性，如果大多數Sentinel能夠對話，如果主服務器下線，最後只會有一個被授權來故障轉移。 同時Redis Sentinel也保證安全(safety)屬性，每個Sentinel將會使用不同的配置紀元來故障轉移同一臺主服務器。
4、故障轉移（選舉新的主服務器）
首先是從主服務器的從服務器中選出一個從服務器作爲新的主服務器。選點的依據依次是：網絡連接正常->5秒內回覆過INFO命令->10*down-after-milliseconds內與主連接過的->從服務器優先級->複製偏移量->運行id較小的。選出之後通過slaveif no ont將該從服務器升爲新主服務器。
通過slaveof ip port命令讓其他從服務器複製該信主服務器。
最後當舊主重新連接後將其變爲新主的從服務器。注意如果客戶端與就主服務器分隔在一起，寫入的數據在恢復後由於舊主會複製新主的數據會造成數據丟失。
故障轉移成功後會通過發佈訂閱連接廣播新的配置信息，其他sentinel收到後依據配置紀元更大來更新主服務器信息。Sentinel保證第二個活性屬性：一個可以相互通信的Sentinel集合會統一到一個擁有更高版本號的相同配置上。