Redis高可用概述
高可用是如今Web服務的一個基本訴求，它是指伺服器可以正常通路的時間，衡量标準是多少時間内可以提供正常服務。在Redis層面内，不僅僅需要能正常提供服務，還需要考慮資料擴容、資料安全等。
Redis主從複制問題
主從複制是為了解決分布式系統中的單點問題，通常會把資料複制到多個副本部署到其他機器上，滿足了故障恢複和負載均衡等需求。Redis也提供了這樣的功能，它可以将主節點資料的改變同步給其他從節點，這樣當主節點因為故障不可達，那麼從節點就可以作為後備“頂”上來，并保證資料盡量不丢失，也是最終一緻性的保證。同時主從複制也擴充了主節點的讀能力，對于一緻性要求不是那麼嚴格的場景下，一旦主節點不能支撐住大并發量的讀操作，可以使用從節點分攤主節點的讀壓力。
但是主從複制模式下一旦主節點出現故障，就需要手動将一個從節點晉升為主節點，同時需要修改應用方的從節點位址，還需要指令其他從節點去複制新的主節點，整個過程都需要人工的幹預，如果處理不及時，那麼系統很長時間都可能處于不可用狀态。對于應用方來說，因為無法感覺主節點的變化，必然會造成一定寫資料的丢失和讀資料的錯誤，甚至可能造成應用放服務的不可用。對于運維來說，整個故障轉移過程都需要人工介入，故障轉移的實時性和準确性上都無法得到保障。
Redis Sentinel架構
Redis主從複制模式下，一旦主節點出現故障不可達，需要人工幹預進行故障轉移，無論對Redis的應用方還是運維都帶來了很大的不便。為了讓一切不需要人為幹預，在Redis2.8以後提供了Redis Sentinel哨兵機制來解決這個問題。
是以Redis 的高可用架構就分為Redis資料節點和Sentinel節點，資料節點是主節點和從節點的資料程序，保證資料的最終一緻性；Sentinel節點對資料節點進行監控，當它發現節點不可達時，會對節點做下線便是。如果被辨別的是主節點，他還會對其他Sentinel節點進行“協商”，當大多數Sentinel節點都認為主節點不可達時，他們會選舉出一個Sentinel節點來完成自動的故障轉移工作，同時還會将這個變化通知給應用方，整個過程是完全自動的，不需要人工來介入，是以這套方案很有效的解決了Redis高可用問題。
故障轉移流
1）每個Sentinel節點定期監控發現主節點出現了故障
2）多個Sentinel節點對主節點故障達成一緻，選舉sentinel3節點作為上司者，負責此次故障轉移。
3）此時Sentinel3完成整個故障轉移過程故障轉移後整個Redis Sentinel的變化
通過上面過程，我們就可以看出Redis Sentinel具有以下幾個功能：
監控：Sentinel節點會定期檢查Redis資料節點、其餘Sentinel節點是否可達
通知：Sentinel節點會将故障轉移的結果通知給應用方
主節點故障轉移：實作從節點晉升為主節點并維護後續正确的主從關系
配置提供者：在Redis Sentinel結構中，用戶端在初始化的時候連接配接的是Sentinel節點集合，從中擷取主節點資訊。
Redis Sentinel用戶端連接配接邏輯
Sentinel節點集合具備了監控、通知、自動故障轉移、配置提供者等若幹功能。也就是說實際上主節點的資訊就是儲存在Sentinel節點，是以我們隻要能正确的連接配接到Redis Sentinel擷取到主節點資訊，就能正常通路Redis。
1）擷取一個可用的Sentinel
2）擷取主節點資訊并連接配接
從傳回的Sentinel節點中，調用API擷取主節點的資訊并連接配接。為了防止故障轉移期間主節點發送了變化，在進行第二步連接配接主節點之前，需要先驗證一下目前節點是不是主節點
3）保持和Sentinel節點集合聯系，時刻關注主節點相關資訊
從上面模型來看，服務端隻有在初次連接配接和要切換主節點的時候才需要和Sentinel節點集合進行交換來擷取直接點資訊，其他時間都是和以前一樣。整個擷取很靈活自動進行，也不需要人為的幹預。
小結
Redis Sentinel哨兵模式是Redis高可用的實作，彌補了Redis主從複制的不足。但是Redis Sentinel僅僅隻是解決了高可用問題，對于主節點單點寫入和單節點無法擴容等問題還是沒有解決，這裡還需要引入Redis Cluster叢集模式來解決。