一.什么是哨兵機制?
答：Redis的哨兵(sentinel) 系統用於管理多個 Redis 服務器,該系統執行以下三個任務:
監控(Monitoring): 哨兵(sentinel) 會不斷地檢查你的Master和Slave是否運作正常。
提醒(Notification):當被監控的某個 Redis出現問題時, 哨兵(sentinel) 可以通過 API 向管理員或者其他應用程序發送通知。
自動故障遷移(Automatic failover):當一個Master不能正常工作時，哨兵(sentinel) 會開始一次自動故障遷移操作,它會將失效Master的其中一個Slave升級為新的Master, 並讓失效Master的其他Slave改為復制新的Master; 當客戶端試圖連接失效的Master時,集群也會向客戶端返回新Master的地址,使得集群可以使用Master代替失效Master。
哨兵(sentinel) 是一個分布式系統,你可以在一個架構中運行多個哨兵(sentinel) 進程,這些進程使用流言協議(gossipprotocols)來接收關於Master是否下線的信息,並使用投票協議(agreement protocols)來決定是否執行自動故障遷移,以及選擇哪個Slave作為新的Master。
每個哨兵(sentinel) 會向其它哨兵(sentinel)、master、slave定時發送消息,以確認對方是否”活”着,如果發現對方在指定時間(可配置)內未回應,則暫時認為對方已掛(所謂的”主觀認為宕機” Subjective Down,簡稱sdown).
若“哨兵群”中的多數sentinel,都報告某一master沒響應,系統才認為該master"徹底死亡"(即:客觀上的真正down機,Objective Down,簡稱odown),通過一定的vote算法,從剩下的slave節點中,選一台提升為master,然后自動修改相關配置。
雖然哨兵(sentinel) 釋出為一個單獨的可執行文件 redis-sentinel ,但實際上它只是一個運行在特殊模式下的 Redis 服務器，你可以在啟動一個普通 Redis 服務器時通過給定 --sentinel 選項來啟動哨兵(sentinel)。
哨兵(sentinel) 的一些設計思路和zookeeper非常類似
二.哨兵模式的配置修改
實現步驟:
1.拷貝到etc目錄
cp sentinel.conf /usr/local/redis/etc
2.修改sentinel.conf配置文件
sentinel monitor mymast 192.168.110.133 6379 1 #主節點 名稱 IP 端口號 選舉次數
#配置主服務器的密碼(如沒設置密碼，可以省略)
sentinel auth-pass mymaster 123456
3. 修改心跳檢測 5000毫秒
sentinel down-after-milliseconds mymaster 5000
4. 做多多少合格節點
sentinel parallel-syncs mymaster 2
5. 啟動哨兵模式
./redis-server /usr/local/redis/etc/sentinel.conf --sentinel &
6. 停止哨兵模式
注意：
1.當啟動哨兵模式之后，如果你的master服務器宕機之后，哨兵自動會在從redis服務器里面 投票選舉一個master主服務器出來；這個主服務器也可以進行讀寫操作！
2.如果之前宕機的主服務器已經修好，可以正式運行了。那么這個服務器只能進行讀的操作，會自動跟隨由哨兵選舉出來的新服務器！
3.大家可以進入./redis-cli，輸入info，查看你的狀態信息；
三、哨兵(Sentinel)總結
1、Sentinel的作用：
A、Master 狀態監測
B、如果Master 異常，則會進行Master-slave 轉換，將其中一個Slave作為Master，將之前的Master作為Slave
C、Master-Slave切換后，master_redis.conf、slave_redis.conf和sentinel.conf的內容都會發生改變，即master_redis.conf中會多一行slaveof的配置，sentinel.conf的監控目標會隨之調換
2、Sentinel的工作方式:
1)：每個Sentinel以每秒鍾一次的頻率向它所知的Master，Slave以及其他 Sentinel 實例發送一個 PING 命令。
2)：如果一個實例（instance）距離最后一次有效回復 PING 命令的時間超過 down-after-milliseconds 選項所指定的值， 則這個實例會被 Sentinel 標記為主觀下線。
3)：如果一個Master被標記為主觀下線，則正在監視這個Master的所有 Sentinel 要以每秒一次的頻率確認Master的確進入了主觀下線狀態。
4)：當有足夠數量的 Sentinel（大於等於配置文件指定的值）在指定的時間范圍內確認Master的確進入了主觀下線狀態， 則Master會被標記為客觀下線 。
5)：在一般情況下， 每個 Sentinel 會以每 10 秒一次的頻率向它已知的所有Master，Slave發送 INFO 命令 。
6)：當Master被 Sentinel 標記為客觀下線時，Sentinel 向下線的 Master 的所有 Slave 發送 INFO 命令的頻率會從 10 秒一次改為每秒一次 。
7)：若沒有足夠數量的 Sentinel 同意 Master 已經下線， Master 的客觀下線狀態就會被移除。
若 Master 重新向 Sentinel 的 PING 命令返回有效回復， Master 的主觀下線狀態就會被移除。
最后，如果大家看不太懂，推薦大家看兩個博客，就明白了！
1.http://blog.csdn.net/zbw18297786698/article/details/52891695
2.http://blog.csdn.net/candy_rainbow/article/details/52842402
===========================================================================
心跳檢測
在命令傳播階段，從服務器默認以每秒一次的頻率，向主服務器發送命令：
REPLCONF ACK <replication_offset> //replication_offset是從服務器當前的復制偏移量。
心跳檢測的作用：檢測主服務器的網絡連接狀態；輔助實現min-slaves選項；檢測命令丟失。
檢測主從服務器的網絡連接狀態
通過向主服務器發送INFO replication命令，可以列出從服務器列表，可以看出從最后一次向主發送命令距離現在過了多少秒。
lag的值應該在0或1之間跳動，如果超過1則說明主從之間的連接有故障。
輔助實現min-slaves選項
Redis可以通過配置防止主服務器在不安全的情況下執行寫命令；
min-slaves-to-write 3
min-slaves-max-lag 10
上面的配置表示：從服務器的數量少於3個，或者三個從服務器的延遲（lag）值都大於或等於10秒時，主服務器將拒絕執行寫命令。這里的延遲值就是上面INFOreplication命令的lag值。
檢測命令丟失
如果因為網絡故障，主服務器傳播給從服務器的寫命令在半路丟失，那么當從服務器向主服務器發送REPLCONF ACK命令時，主服務器將發覺從服務器當前的復制偏移量少於自己的復制偏移量，然后主服務器就會根據從服務器提交的復制偏移量，在復制積壓緩沖區里面找到從服務器缺少的數據，並將這些數據重新發送給從服務器。
主服務器向從服務器補發缺失數據這一操作的原理和部分重同步操作的原理非常相似，它們的區別在於：補發缺失數據操作在主從服務器沒有斷線的情況下執行，而部分重同步操作則在主從服務器斷線並重連之后執行。