在前面講的master/slave模式，在一個典型的一主多從的系統中，slave在整個體系中起到了數據冗余備份和讀寫分離的作用。當master遇到異常終端后，需要從slave中選舉一個新的master繼續對外提供服務，這種機制在前面提到過N次，比如在zk中通過leader選舉、kafka中可以基于zk的節點實現master選舉。所以在redis中也需要一種機制去實現master的決策，redis并沒有提供自動master選舉功能，而是需要借助一個哨兵來進行監控。
定義
什么是哨兵
顧名思義，哨兵的作用就是監控Redis系統的運行狀況，它的功能包括幾個
\1.監控(Monitoring): 監控master和slave是否正常運行
\2. 自動故障遷移(Automatic failover):當一個Master不能正常工作時，哨兵(sentinel) 會開始一次自動故障遷移操作,它會將失效Master的其中一個Slave升級為新的Master, 并讓失效Master的其他Slave改為復制新的Master; 當客戶端試圖連接失效的Master時,集群也會向客戶端返回新Master的地址,使得集群可以使用Master代替失效Master。
- 提醒(Notification):當被監控的某個 Redis出現問題時, 哨兵(sentinel) 可以通過 API 向管理員或者其他應用程序發送通知。
為了解決master選舉問題，又引出了一個單點問題，也就是哨兵的可用性(哨兵掛了)如何解決，在一個一主多從的Redis系統中，可以使用多個哨兵進行監控任務以保證系統足夠穩定。此時哨兵不僅會監控master和slave，同時還會互相監控；這種方式稱為哨兵集群，哨兵集群需要解決故障發現、和master決策的協商機制問題。
sentinel之間會相互感知
sentinel節點之間會因為共同監視同一個master從而產生了關聯，一個新加入的sentinel節點需要和其他監視相同
master節點的sentinel相互感知，首先:
\1. 需要相互感知的sentinel都向他們共同監視的master節點訂channel:sentinel:hello
\2. 新加入的sentinel節點向這個channel發布一條消息，包含自己本身的信息，這樣訂閱了這個channel的sentinel就可以發現這個新的sentinel
\3. 新加入得sentinel和其他sentinel節點建立長連接。
master的故障發現
sentinel節點會定期向master節點發送心跳包來判斷存活狀態，一旦master節點沒有正確響應，sentinel會把master設置為“主觀不可用狀態”，然后它會把“主觀不可用”發送給其他所有的sentinel節點去確認，當確認的sentinel節點數大于>quorum時，則會認為master是“客觀不可用”，接著就開始進入選舉新的master流程；
但是，這里又會遇到一個問題，就是sentinel中，本身是一個集群，如果多個節點同時發現master節點達到客觀不可用狀態，那誰來決策選擇哪個節點作為maste呢？
這個時候就需要從sentinel集群中選擇一個leader來做決策。而這里用到了一致性算法Raft算法、它和Paxos算法類似，都是分布式一致性算法。但是它比Paxos算法要更容易理解；
Raft和Paxos算法一樣，也是基于投票算法，只要保證過半數節點通過提議即可;
動畫演示地址：http://thesecretlivesofdata.com/raft/
配置實現
通過在這個配置的基礎上增加哨兵機制。在其中任意一臺服務器上創建一個sentinel.conf文件（在redis文件中，也會存在一個sentinel.conf的示例文件），文件內容
sentinel monitor name ip port quorum
其中name表示要監控的master的名字，這個名字是自己定義。 ip和port表示master的ip和端口號。 最后一個1表示最低通過票數，也就是說至少需要幾個哨兵節點統一才可以，后面會具體說明:
port 6040 //哨兵自己的端口號
sentinel monitor mymaster 192.168.11.131 6379 1
sentinel down-after-milliseconds mymaster 5000 --表示如果5s內mymaster沒響應，就認為SDOWN
sentinel failover-timeout mymaster 15000 --表示如果15秒后,mysater仍沒活過來，則啟動failover，從剩下的slave中選一個升級為master
兩種方式啟動哨兵
redis-sentinel sentinel.conf
redis-server /path/to/sentinel.conf --sentinel
啟動如上圖
哨兵監控一個系統時，只需要配置監控master即可，哨兵會自動發現所有slave；
這時候，我們把master關閉，等待指定時間后（默認是30秒），會自動進行切換，會輸出如下消息
shutdown
+sdown表示哨兵主管認為master已經停止服務了，+odown表示哨兵客觀認為master停止服務了。如圖所示:
關于主觀和客觀，每個sentinel以每秒一次向他所記錄的master或slave其他的sentinel相互ping，檢測是否存活。
超過down-after-milliseconds的時間，則標記為主觀下線。然后其他的sentinel也要開始確認是否主觀下線，如果超過一定確認變更為客觀下線。
接著哨兵開始進行故障恢復，挑選一個slave升級為master
+try-failover表示哨兵開始進行故障恢復
+failover-end 表示哨兵完成故障恢復
+slave表示列出新的master和slave服務器，我們仍然可以看到已經停掉的master，哨兵并沒有清楚已停止的服務的實例，這是因為已經停止的服務器有可能會在某個時間進行恢復，恢復以后會以slave角色加入到整個集群中。
即使是使用哨兵，此時的Redis集群的每個數據庫依然存有集群中的所有數據，從而導致集群的總數據存儲量受限于可用存儲內存最小的節點，形成了木桶效應。而因為Redis是基于內存存儲的，所以這一個問題在redis中就顯得尤為突出了
在redis3.0之前，我們是通過在客戶端去做的分片，通過hash環的方式對key進行分片存儲。分片雖然能夠解決各個節點的存儲壓力，但是導致維護成本高、增加、移除節點比較繁瑣。
因此redis3中，就出現支持集群。
總結幾點
1.性能，內存撐不住。
2.只有一個master，并發上不去。
3.Master一掛的過程是無法寫入的，重啟的過程需要一秒或幾秒，如果做的是秒殺的業務，在幾秒內秒殺結束，redis掛了，會影響前臺的業務。大公司已經不會再用哨兵模式了。
