前言 Redis哨兵模式，用現在流行的話可以說就是一個“哨兵機器人”，給“哨兵機器人”進行相應的配置之後，這個"機器人"可以7*24小時工作，它能能夠自動幫助你做一些事情，如監控，提醒，自動處理故障等。 Redis-sentinel簡介 Redis-sentinel是Redis的作者antirez， ...
前言 Redis哨兵模式，用現在流行的話可以說就是一個“哨兵機器人”，給“哨兵機器人”進行相應的配置之後，這個"機器人"可以7*24小時工作，它能能夠自動幫助你做一些事情，如監控，提醒，自動處理故障等。 Redis-sentinel簡介 Redis-sentinel是Redis的作者antirez，因為Redis集群的被各大公司使用，每個公司要寫自己的集群管理工具，於是antirez花了幾個星期寫出了Redis-sentinel。 Redis 的 Sentinel 系統用於管理多個 Redis 伺服器（instance），Redis 的 Sentinel 為Redis提供了高可用性。使用哨兵模式創建一個可以不用人為干預而應對各種故障的Redis部署。 該系統執行以下三個任務： 監控（Monitoring）：Sentinel會不斷地檢查你的主伺服器和從伺服器是否允許正常。 提醒（Notification）：當被監控的某個Redis伺服器出現問題時，Sentinel可以通過API向管理員或者其他應用程式發送通知。 自動故障遷移（Automatic failover）：
（1）當一個主伺服器不能正常工作時，Sentinel會開始一次自動故障遷移操作，他會將失效主伺服器的其中一個從伺服器升級為新的主伺服器，並讓失效主伺服器的其他從伺服器改為複製新的主伺服器； （2）客戶端試圖連接失敗的主伺服器時，集群也會向客服端返回新主伺服器的地址，是的集群可以使用新主伺服器代替失效伺服器。
sentinel的分散式特性 Redis Sentinel 是一個分散式系統， 你可以在一個架構中運行多個 Sentinel 進程（progress）， 這些進程使用流言協議（gossip protocols)來接收關於主伺服器是否下線的信息， 並使用投票協議（agreement protocols）來決定是否執行自動故障遷移， 以及選擇哪個從伺服器作為新的主伺服器。 單個sentinel進程來監控redis集群是不可靠的，當sentinel進程宕掉後(sentinel本身也有單點問題，single-point-of-failure)整個集群系統將無法按照預期的方式運行。所以有必要將sentinel集群，這樣有幾個好處： 有一些sentinel進程宕掉了，依然可以進行redis集群的主備切換； 如果只有一個sentinel進程，如果這個進程運行出錯，或者是網路堵塞，那麼將無法實現redis集群的主備切換（單點問題）; 如果有多個sentinel，redis的客戶端可以隨意地連接任意一個sentinel來獲得關於redis集群中的信息 一個健壯的部署至少需要三個哨兵實例。 三個哨兵實例應該放置在客戶使用獨立方式確認故障的電腦或虛擬機中。例如不同的物理機或不同可用區域的虛擬機。
Redis-Sentinel高可用場景演示 場景1：主伺服器master宕機 當主伺服器master宕機，那麼Sentinel會通過選舉（演算法）機制，從Salve中選出一個作為新Master。 大概原理是當選出一個Slave要作為Master的時候，會發送命令slaveofno one來取消選中的這個slave，使其成為Master。哨兵會發送給其他從伺服器Slave配置選中的這個為新主伺服器Master，並刪除監聽列表中出現故障的Master伺服器。 (1)關閉掉 6379主伺服器
(2)查看觀察選舉新的master的過程和顯示了failover的過程，整個日誌信息還是比較完整的。最後選舉了6381為主伺服器！
(3)查看6381伺服器信息,角色為主，從伺服器6380！
場景2：之前故障的6379 master重新啟動
（1）啟動6379服務，發現6379成為6381的從伺服器！
（2）查看6381伺服器狀態信息：原來的master自動切換成slave，不會自動恢覆成master。
場景3：從伺服器Slave宕機和重啟
（1）關閉6380從伺服器
（2）Sentinel日誌
（3）查看住伺服器6381狀態信息
（4）啟動從伺服器6380
（5）查看住伺服器6381狀態信息：6380又回來了！
