一、為什麼要使用哨兵機制 redis主從複制存在缺陷，如果主節點出現問題不能提供服務，需要人工重新把從節點設定為主節點，還需要通知應用程式更新了主節點的位址。這樣處理是非常不科學的。redis2.8正式提供哨兵架構。 二、哨兵機制原理
當sentinel監控的主節點出現故障時，redis sentinel自動完成故障發現和轉移，并通知應用方，實作高可用性。故障轉移和通知應用方隻需要一個sentinel來完成，這個sentinel是通過Raft算法(選舉算法)得到的。 2.1 哨兵機制的三個定時任務 1）每個哨兵節點每10秒會向主節點和從節點發送info指令擷取最拓撲結構圖，哨兵配置時隻要配置對主節點的監控即可，通過向主節點發送info，擷取從節點的資訊，并當有新的從節點加入時可以馬上感覺到。 （所有哨兵節點監控主、從節點）
2）每個哨兵節點每隔2秒會向redis資料節點的指定頻道上發送該哨兵節點對于 主節點的判斷以及 目前哨兵節點的資訊，同時每個哨兵節點也會訂閱該頻道，來了解其它哨兵節點的資訊及對主節點的判斷，其實就是通過消息publish和subscribe來完成的。 （所有哨兵發送對主節點的判斷以及自己節點資訊到指定的頻道）
3）每隔1秒每個哨兵會向主節點、從節點及其餘哨兵節點發送一次ping指令做一次心跳檢測，這個也是哨兵用來判斷節點是否正常的重要依據。 （所有哨兵會向主、從、其他哨兵節點發送心跳檢測節點是否健康）
2.2 主觀下線和客觀下線 主觀下線：哨兵節點每隔1秒對主節點和從節點、其它哨兵節點 發送ping做心跳檢測，當這些心跳檢測時間超過down-after-milliseconds時，哨兵節點則認為該節點錯誤或下線，這叫主觀下線；這可能會存在錯誤的判斷。
客觀下線：當主觀下線的節點是主節點時，此時該哨兵3節點會通過指令sentinel is-masterdown-by-addr尋求其它哨兵節點對主節點的判斷，當超過quorum（法定人數）個數，此時哨兵節點則認為該主節點确實有問題，這樣就客觀下線了， 大部分哨兵節點都同意下線操作，也就說是客觀下線。
2.3 上司者哨兵的選舉流程 1）每個線上的哨兵節點都可以成為上司者，當它确認（比如哨兵3）主節點下線時，會向其它哨兵發is-master-down-by-addr指令，征求判斷并要求将自己設定為上司者，由上司者處理故障轉移。 2）當其它哨兵收到此指令時，可以同意或者拒絕它成為上司者； 3）如果哨兵3發現自己在選舉的票數大于等于num(sentinels)/2+1時，将成為上司者，如果沒有超過，繼續選舉…………
上司者哨兵的職責是：故障轉移以及通知應用方。
2.4主節點故障轉移流程 1）sentinel會向master發送心跳PING來确認master是否存活，如果master在“一定時間範圍”内不回應PONG 或者是回複了一個錯誤消息，那麼這個sentinel會主觀地(單方面地)認為這個master已經不可用了。 2）當主節點出現故障，此時3個Sentinel節點共同選舉了Sentinel3節點為上司，負載處理主節點的故障轉移。将從節點更新為主節點，将其他從節點指向新的主節點。 3）通知用戶端主節點已經更換。 4）如果原主節點上線，則設定為從節點。 下圖表示步驟2将從節點更新為主節點操作流程圖
三、哨兵機制的搭建 3.1主從節點配置（複制三分redis.conf配置檔案）
#主節點:6379
bind 127.0.0.1
port 6379
logfile "6379.log"
dbfilename "dump-6379.rdb"
#從節點:6380
bind 127.0.0.1
port 6380
logfile "6380.log"
dbfilename "dump-6380.rdb"
slaveof 127.0.0.1 6379
#從節點:6381
bind 127.0.0.1
port 6381
logfile "6381.log"
dbfilename "dump-6381.rdb"
slaveof 127.0.0.1 6379
#啟動主從節點
./src/redis-server 6379.conf &
./src/redis-server 6380.conf &
./src/redis-server 6381.conf &
3.2配置哨兵節點資訊（複制三分redis.conf配置檔案） sentinel-26379.conf,sentinel-26380.conf,sentinel-26380.conf這三個配置檔案加粗 部分按照實際情況自行設定。
port 26379
daemonize yes
logfile "26379.log"
dir /opt/soft/redis/data
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel myid mm55d2d712b1f3f312b637f9b546f00cdcedc787
啟動哨兵
./src/redis-sentinel sentinel-26379.conf &
./src/redis-sentinel sentinel-26380.conf &
./src/redis-sentinel sentinel-26381.conf &
3.3檢查叢集資訊 通過info replication指令檢視叢集資訊 127.0.0.1:6379> info replication
四、注意事項以及建議 1）sentinel節點建議奇數個（3），這樣才能産生上司者哨兵的選舉結果 2）建議redis sentinel節點和redis主從節點分開部署到不同的機器。 3） sentinel monitor mymaster 127.0.0.1 6379 2這個一定要将127.0.0.1改成192.168.1.111内網IP位址，否則JedisSentinelPool 取 jedis 連接配接的時候會變成取 127.0.0.1 6379。 4）sentinel monitor mymaster 192.168.1.111 2中的"2"表示:隻要有2個sentinel認為master下線，就認為該master客觀下線，選舉産生新的master。 （隻要2個sentinel同意下線就客觀下線master節點）
五、哨兵機制的優缺點 1）解決主從模式下主節點的故障轉移工作的。 2）redis中sentinel有效的解決了故障轉移的問題，也解決了主節點下線用戶端無法識别新的可用節點的問題。 3）但是如果是從節點下線了，sentinel是不會對其進行故障轉移的，并且連接配接從節點的用戶端也無法擷取到新的可用從節點。