redis哨兵模式
redis主從雖然解決了單點導致的數據丟失問題，但是還是沒有解決無縫的故障轉移，也就是說在主庫宕機後，從庫無法自動切換爲主庫，需要手工去切換，在這一瞬間會對後端數據庫造成極大的負載，可能直接導致後端數據宕機。
哨兵主要作用
哨兵模式是一種特殊的模式，首先Redis提供了哨兵的命令，哨兵是一個獨立的進程，作爲進程，它會獨立運行。其原理是哨兵通過發送命令，等待Redis服務器響應，從而監控運行的多個Redis實例。
監控：監控redis主庫及從庫運行狀態；
通知：如果redis發生故障轉移，可以通過郵件通知管理員；
自動故障轉移：當哨兵監測到master宕機，會自動將slave切換成master，然後通過發佈訂閱模式通知其他的從服務器，修改配置文件，讓它們切換主機。
然而一個哨兵進程對Redis服務器進行監控，可能會出現問題，爲此，我們可以使用多個哨兵進行監控。各個哨兵之間還會進行監控，這樣就形成了多哨兵模式。
工作原理
哨兵(sentinel) 是一個分佈式系統，你可以在一個架構中運行多個哨兵(sentinel) 進程，這些進程使用流言協議(gossipprotocols)來接收關於Master是否下線的信息，並使用投票協議(agreement protocols)來決定是否執行自動故障遷移，以及選擇哪個Slave作爲新的Master。
每個哨兵(sentinel) 會向其它哨兵(sentinel)、master、slave定時發送消息，以確認對方是否”活”着，如果發現對方在指定時間(可配置)內未迴應，則暫時認爲對方宕機了，這就是所謂的”主觀認爲宕機”Subjective Down,簡稱sdown)。
若“哨兵羣”中的多數sentinel，都報告某一master沒響應，系統才認爲該master真正宕機，即客觀上認爲宕機，Objective Down,簡稱odown)，通過一定的vote算法，從剩下的slave節點中，選一臺提升爲master，然後自動修改相關配置。
用文字描述一下故障切換（failover）的過程。假設主服務器宕機，哨兵1先檢測到這個結果，系統並不會馬上進行failover過程，僅僅是哨兵1主觀的認爲主服務器不可用，這個現象成爲主觀下線。當後面的哨兵也檢測到主服務器不可用，並且數量達到一定值時，那麼哨兵之間就會進行一次投票，投票的結果由一個哨兵發起，進行failover操作。切換成功後，就會通過發佈訂閱模式，讓各個哨兵把自己監控的從服務器實現切換主機，這個過程稱爲客觀下線。這樣對於客戶端而言，一切都是透明的。
Redis配置哨兵模式
配置3個哨兵和1主2從的Redis服務器來演示這個過程。
| 服務類型 | 是否是主服務器 | IP地址 | 端口 |
|---|---|---|---|
| Redis | 是 | 192.168.179.102 | 6379 |
| Redis | 否 | 192.168.179.103 | 6379 |
| Redis | 否 | 192.168.179.104 | 6379 |
| Sentinel | - | 192.168.179.102 | 26379 |
| Sentinel | - | 192.168.179.103 | 26379 |
| Sentinel | - | 192.168.179.104 | 26379 |
