一、爲什麼要有哨兵機制
上小節介紹了redis的主從複製及主從複製的缺點，但是爲什麼還要有redis的哨兵機制呢？
主要是因爲主從複製沒有辦法對master進行動態選舉，因此需要使用Sentinel（哨兵）機制來完成動態選舉，也就是說哨兵機制的出現是爲了解決主從複製的缺點的。
Sentinel(哨兵)進程是用於監控redis集羣中Master主服務器工作的狀態。在Master主服務器發生故障的時候，可以實現Master和Slave服務器的切換，保證系統的高可用（HA）。哨兵機制被集成在了redis2.6+的版本中，到了2.8版本之後穩定了下來。
哨兵機制(sentinel)的高可用：
原理：當主節點出現故障時，由Redis Sentinel自動完成故障發現和轉移，並通知應用方，實現高可用性。
其實整個過程只需要一個哨兵節點來完成，首先使用Raft算法（選舉算法）實現選舉機制，選出一個哨兵節點來完成轉移和通知
二、哨兵進程的作用
1.監控(Monitoring): 哨兵(sentinel) 會不斷地檢查你的Master和Slave是否運作正常。
2.提醒(Notification)： 當被監控的某個Redis節點出現問題時, 哨兵(sentinel) 可以通過 API 向管理員或者其他應用程序發送通知。
3.自動故障遷移(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的監控目標會隨之調換。
由一個或多個Sentinel 實例 組成的Sentinel 系統可以監視任意多個主服務器，以及這些主服務器屬下的所有從服務器，並在被監視的主服務器進入下線狀態時，自動將下線主服務器屬下的某個從服務器升級爲新的主服務器。如下圖：
在Server1 掉線後：
升級Server2 爲新的主服務器：
三、哨兵進程的工作方式
1.每個Sentinel（哨兵）進程以每秒鐘一次的頻率向整個集羣中的Master主服務器，Slave從服務器以及其他Sentinel（哨兵）進程發送一個 PING 命令。
2.如果一個實例（instance）距離最後一次有效回覆 PING 命令的時間超過 down-after-milliseconds 選項所指定的值， 則這個實例會被 Sentinel（哨兵）進程標記爲主觀下線（SDOWN）。
3.如果一個Master主服務器被標記爲主觀下線（SDOWN），則正在監視這個Master主服務器的所有 Sentinel（哨兵）進程要以每秒一次的頻率確認Master主服務器的確進入了主觀下線狀態。
4.當有足夠數量的 Sentinel（哨兵）進程（大於等於配置文件指定的值）在指定的時間範圍內確認Master主服務器進入了主觀下線狀態（SDOWN）， 則Master主服務器會被標記爲客觀下線（ODOWN）。
5.在一般情況下， 每個 Sentinel（哨兵）進程會以每 10 秒一次的頻率向集羣中的所有Master主服務器、Slave從服務器發送 INFO 命令。
6.當Master主服務器被 Sentinel（哨兵）進程標記爲客觀下線（ODOWN）時，Sentinel（哨兵）進程向下線的 Master主服務器的所有 Slave從服務器發送 INFO 命令的頻率會從 10 秒一次改爲每秒一次。
7.若沒有足夠數量的 Sentinel（哨兵）進程同意 Master主服務器下線， Master主服務器的客觀下線狀態就會被移除。若 Master主服務器重新向 Sentinel（哨兵）進程發送 PING 命令返回有效回覆，Master主服務器的主觀下線狀態就會被移除。
