前言
redis的主從複製模式，一旦master宕機，需要人工將slave升級爲master，還得通知client端更新master地址。 redis從2.8開始提供了sentinel(哨兵)模式來實現自動故障轉移。
sentinel模式是redis的高可用實現方案。
redis sentinel的高可用性
sentinel部署和配置
部署
略
配置
sentinel monitor <master-name> <ip> <port> <quorum>
代表sentinel節點需要監控<ip> <port>這個master,<master-name>是master的別名,<quorum> 代表判斷master故障至少需要2個sentinel節點同意。
注意：sentinel實際上會監控所有的數據節點，但這裏只配置了master的節點，因爲sentinel會從master中獲取所有slave以及其它sentinel節點的相關信息。
<quorum>還與sentinel節點leader選舉有關，至少要有max(quorum,num(sentinels)/2+1)個sentinel節點參與選舉，才能選出leader,從而完成故障轉移。
sentinel auth-pass <master-name> <password>
如果master配置了密碼,需要添加master的密碼
sentinel down-after-milliseconds <master-name> <times>
每個sentinel節點都要通過定期發送ping命令來判斷redis數據節點和其餘sentinel節點是否可達，如果超過了down-after-milliseconds配置的時間沒有有效的恢復，則判定節點不可達。
sentinel parallel-syncs <master-name> <nums>
用來限制在一次故障轉移之後,每次向新的master發起複製操作的slave個數。儘管複製操作通常不會阻塞主節點,但是同時向master發起複製,必然會對master所在機器造成網絡和磁盤IO開銷。
sentinel failover-timeout <master-name> <times>
故障轉移超時時間。作用於故障轉移的各個階段:
1) 選出合適slave;
2) 晉升選出的slave爲master;
3) 命令其餘slave複製新的master;
4) 等待原master恢復後命令它去複製新的master;
sentinel notification-script <master-name> <script-path>
在故障轉移期間,當一些警告級別的sentinel事件發生(比如-sdown客觀下線,-odown主觀下線)時,會觸發對應路徑下的腳本，並向腳本發送相應的事件參數。
sentinel client-reconfig-script <master-name> <script-path>
在故障轉移結束後，會觸發對應路徑下的腳本，並向腳本發送故障轉移結果的相關參數。
如何監控多個master
略
API
redis-cli中支持的sentinel相關命令:
sentinel masters #顯示所有被監控的master狀態以及相關的統計信息
sentinel master <master-name> #顯示指定<master-name>的master狀態以及相關的統計信息
sentinel slaves <master-name> #顯示指定<master-name>的slave狀態以及相關的統計信息
sentinel sentinels <master-name> #顯示指定<master-name>的sentinel節點集合(不包含當前sentinel節點)。
sentinel get-master-addr-by-name <master-name> #顯示指定<master-name>的master的ip和端口
...
還有很多。。。不列了。。。
redis sentinel實現原理
三個定時監控任務
主觀下線和客觀下線
sentinel leader選舉
故障轉移
sentinel模式的一些注意點
故障轉移日誌分析
節點運維
高可用讀寫分離
參考
《redis開發與運維》