哨兵模式是一種特殊的模式，首先redis提供了哨兵的命令，哨兵是一個獨立的進程，作為進程，它會獨立運行。其原理是哨兵通過發送命令，等待Redis服務器響應，從而監控運行的多個Redis實例。
一、介紹
主從切換技術的方法是：當主服務器宕機后，需要手動把一臺從服務器切換為主服務器，這就需要人工干預，費事費力，還會造成一段時間內服務不可用。這不是一種推薦的方式，更多時候，我們優先考慮哨兵模式。
在 深入學習Redis（3）：主從復制 中曾提到，Redis主從復制的作用有數據熱備、負載均衡、故障恢復等；但主從復制存在的一個問題是故障恢復無法自動化。本文將要介紹的哨兵，它基于Redis主從復制，主要作用便是解決主節點故障恢復的自動化問題，進一步提高系統的高可用性。
文章主要內容如下：首先介紹哨兵的作用和架構；然后講述哨兵系統的部署方法，以及通過客戶端訪問哨兵系統的方法；然后簡要說明哨兵實現的基本原理；最后給出關于哨兵實踐的一些建議。文章內容基于Redis 3.0版本。
二、哨兵模式概述
哨兵模式是一種特殊的模式，首先Redis提供了哨兵的命令，哨兵是一個獨立的進程，作為進程，它會獨立運行。其原理是哨兵通過發送命令，等待Redis服務器響應，從而監控運行的多個Redis實例。
Redis哨兵
這里的哨兵有兩個作用
- 通過發送命令，讓Redis服務器返回監控其運行狀態，包括主服務器和從服務器。
- 當哨兵監測到master宕機，會自動將slave切換成master，然后通過發布訂閱模式通知其他的從服務器，修改配置文件，讓它們切換主機。
然而一個哨兵進程對Redis服務器進行監控，可能會出現問題，為此，我們可以使用多個哨兵進行監控。各個哨兵之間還會進行監控，這樣就形成了多哨兵模式。
用文字描述一下故障切換（fAIlover）的過程。假設主服務器宕機，哨兵1先檢測到這個結果，系統并不會馬上進行failover過程，僅僅是哨兵1主觀的認為主服務器不可用，這個現象成為主觀下線。當后面的哨兵也檢測到主服務器不可用，并且數量達到一定值時，那么哨兵之間就會進行一次投票，投票的結果由一個哨兵發起，進行failover操作。切換成功后，就會通過發布訂閱模式，讓各個哨兵把自己監控的從服務器實現切換主機，這個過程稱為客觀下線。這樣對于客戶端而言，一切都是透明的。
三、部署
這一部分將部署一個簡單的哨兵系統，包含1個主節點、2個從節點和3個哨兵節點。方便起見：所有這些節點都部署在一臺機器上（局域網IP：192.168.92.128），使用端口號區分；節點的配置盡可能簡化。
1. 部署主從節點
哨兵系統中的主從節點，與普通的主從節點配置是一樣的，并不需要做任何額外配置。下面分別是主節點（port=6379）和2個從節點（port=6380/6381）的配置文件，配置都比較簡單，不再詳述。
#redis-6379.conf
port 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"
#redis-6380.conf
port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
slaveof 192.168.92.128 6379
#redis-6381.conf
port 6381
daemonize yes
logfile "6381.log"
dbfilename "dump-6381.rdb"
slaveof 192.168.92.128 6379
配置完成后，依次啟動主節點和從節點：
redis-server redis-6379.conf
redis-server redis-6380.conf
redis-server redis-6381.conf
節點啟動后，連接主節點查看主從狀態是否正常，如下圖所示：
圖片
2. 部署哨兵節點
哨兵節點本質上是特殊的Redis節點。
3個哨兵節點的配置幾乎是完全一樣的，主要區別在于端口號的不同（26379/26380/26381），下面以26379節點為例介紹節點的配置和啟動方式；配置部分盡量簡化，更多配置會在后面介紹。
#sentinel-26379.conf
port 26379
daemonize yes
logfile "26379.log"
sentinel monitor mymaster 192.168.92.128 6379 2
其中，sentinel monitor mymaster 192.168.92.128 6379 2 配置的含義是：該哨兵節點監控192.168.92.128:6379這個主節點，該主節點的名稱是mymaster，最后的2的含義與主節點的故障判定有關：至少需要2個哨兵節點同意，才能判定主節點故障并進行故障轉移。
哨兵節點的啟動有兩種方式，二者作用是完全相同的：
redis-sentinel sentinel-26379.conf
redis-server sentinel-26379.conf --sentinel
按照上述方式配置和啟動之后，整個哨兵系統就啟動完畢了。可以通過redis-cli連接哨兵節點進行驗證，如下圖所示：可以看出26379哨兵節點已經在監控mymaster主節點(即192.168.92.128:6379)，并發現了其2個從節點和另外2個哨兵節點。
圖片
此時如果查看哨兵節點的配置文件，會發現一些變化，以26379為例：
圖片
其中，dir只是顯式聲明了數據和日志所在的目錄（在哨兵語境下只有日志）；known-slave和known-sentinel顯示哨兵已經發現了從節點和其他哨兵；帶有epoch的參數與配置紀元有關（配置紀元是一個從0開始的計數器，每進行一次領導者哨兵選舉，都會+1；領導者哨兵選舉是故障轉移階段的一個操作，在后文原理部分會介紹）。
3. 演示故障轉移
哨兵的4個作用中，配置提供者和通知需要客戶端的配合，本文將在下一章介紹客戶端訪問哨兵系統的方法時詳細介紹。這一小節將演示當主節點發生故障時，哨兵的監控和自動故障轉移功能。
（1）首先，使用kill命令殺掉主節點：
圖片
（2）如果此時立即在哨兵節點中使用info Sentinel命令查看，會發現主節點還沒有切換過來，因為哨兵發現主節點故障并轉移，需要一段時間。
圖片
（3）一段時間以后，再次在哨兵節點中執行info Sentinel查看，發現主節點已經切換成6380節點。
圖片
但是同時可以發現，哨兵節點認為新的主節點仍然有2個從節點，這是因為哨兵在將6380切換成主節點的同時，將6379節點置為其從節點；雖然6379從節點已經掛掉，但是由于哨兵并不會對從節點進行客觀下線（其含義將在原理部分介紹），因此認為該從節點一直存在。當6379節點重新啟動后，會自動變成6380節點的從節點。下面驗證一下。
（4）重啟6379節點：可以看到6379節點成為了6380節點的從節點。
圖片
（5）在故障轉移階段，哨兵和主從節點的配置文件都會被改寫。
對于主從節點，主要是slaveof配置的變化：新的主節點沒有了slaveof配置，其從節點則slaveof新的主節點。
對于哨兵節點，除了主從節點信息的變化，紀元(epoch)也會變化，下圖中可以看到紀元相關的參數都+1了。
圖片
4. 總結
哨兵系統的搭建過程，有幾點需要注意：
（1）哨兵系統中的主從節點，與普通的主從節點并沒有什么區別，故障發現和轉移是由哨兵來控制和完成的。
（2）哨兵節點本質上是redis節點。
（3）每個哨兵節點，只需要配置監控主節點，便可以自動發現其他的哨兵節點和從節點。
（4）在哨兵節點啟動和故障轉移階段，各個節點的配置文件會被重寫(config rewrite)。
（5）本章的例子中，一個哨兵只監控了一個主節點；實際上，一個哨兵可以監控多個主節點，通過配置多條sentinel monitor即可實現。
