哨兵模式
主從切換技術的方法是：當主服務器宕機后，需要手動把一台從服務器切換為主服務器，這就需要人工干預，費事費力，還會造成一段時間內服務不可用。這不是一種推薦的方式，更多時候，我們優先考慮哨兵模式。
一、哨兵模式概述
哨兵模式是一種特殊的模式，首先Redis提供了哨兵的命令，哨兵是一個獨立的進程，作為進程，它會獨立運行。其原理是哨兵通過發送命令，等待Redis服務器響應，從而監控運行的多個Redis實例。
Redis哨兵
這里的哨兵有兩個作用
- 通過發送命令，讓Redis服務器返回監控其運行狀態，包括主服務器和從服務器。
- 當哨兵監測到master宕機，會自動將slave切換成master，然后通過發布訂閱模式通知其他的從服務器，修改配置文件，讓它們切換主機。
然而一個哨兵進程對Redis服務器進行監控，可能會出現問題，為此，我們可以使用多個哨兵進行監控。各個哨兵之間還會進行監控，這樣就形成了多哨兵模式。
用文字描述一下故障切換（failover）的過程。假設主服務器宕機，哨兵1先檢測到這個結果，系統並不會馬上進行failover過程，僅僅是哨兵1主觀的認為主服務器不可用，這個現象成為主觀下線。當后面的哨兵也檢測到主服務器不可用，並且數量達到一定值時，那么哨兵之間就會進行一次投票，投票的結果由一個哨兵發起，進行failover操作。切換成功后，就會通過發布訂閱模式，讓各個哨兵把自己監控的從服務器實現切換主機，這個過程稱為客觀下線。這樣對於客戶端而言，一切都是透明的。
測試
我們目前的狀態是一主二從！
如果配置3個哨兵，每個哨兵的配置都是一樣的。在Redis安裝目錄下有一個sentinel.conf文件，copy一份進行修改
1、配置哨兵配置文件 sentinel.conf
# sentinel monitor 被監控的名稱 host port 1
sentinel monitor myredis 127.0.0.1 6379 1
后面這個數字1代表主機掛了，slave投票看讓誰接替成為主機，票數最多的，就會成為主機！
2、啟動哨兵！
redis-sentinel dconfig/sentinel.conf
主機宕機會重新選舉主機
如果主機此時回來了，只能歸並到新的主機下，當作從機，這就是哨兵模式的規則！
優點：
- 哨兵集群，基於主從復制模式，所有的主從配置優點，它全有
- 主從可以切換，故障可以轉移，系統的可用性就會更好
- 哨兵模式就是主從模式的升級，手動到自動，更加健壯！
缺點：
- Redis不好在線擴容，集群容量一旦達到上限，在線擴容就十分麻煩！
- 實現哨兵模式的配置其實是很麻煩的，里面有很多選擇！
哨兵模式的其他配置項
| 配置項 | 參數類型 | 作用 |
|---|---|---|
| port | 整數 | 啟動哨兵進程端口 |
| dir | 文件夾目錄 | 哨兵進程服務臨時文件夾，默認為/tmp，要保證有可寫入的權限 |
| sentinel down-after-milliseconds | <服務名稱><毫秒數（整數）> | 指定哨兵在監控Redis服務時，當Redis服務在一個默認毫秒數內都無法回答時，單個哨兵認為的主觀下線時間，默認為30000（30秒） |
| sentinel parallel-syncs | <服務名稱><服務器數（整數）> | 指定可以有多少個Redis服務同步新的主機，一般而言，這個數字越小同步時間越長，而越大，則對網絡資源要求越高 |
| sentinel failover-timeout | <服務名稱><毫秒數（整數）> | 指定故障切換允許的毫秒數，超過這個時間，就認為故障切換失敗，默認為3分鍾 |
| sentinel notification-script | <服務名稱><腳本路徑> | 指定sentinel檢測到該監控的redis實例指向的實例異常時，調用的報警腳本。該配置項可選，比較常用 |
sentinel down-after-milliseconds配置項只是一個哨兵在超過規定時間依舊沒有得到響應后，會自己認為主機不可用。對於其他哨兵而言，並不是這樣認為。哨兵會記錄這個消息，當擁有認為主觀下線的哨兵達到sentinel monitor所配置的數量時，就會發起一次投票，進行failover，此時哨兵會重寫Redis的哨兵配置文件，以適應新場景的需要