Redis Sentinel
一、Redis Sentinel的由來，普通主從複製高可用？
首先我們複習下主從複製的作用：
1、數據備份 ===》 當主節點掛了的時候，因爲有從節點的備份保證了數據的安全性。
2、請求分流 ===》 通過讀寫分離的方式將客戶端的請求分流減輕單節點模式下的壓力。
但是這樣也存在着問題：
1、當主節點掛了的時候得手動轉移，將從節點的其中一個設爲主節點。（redis-sentinel 可以解決）
2、主節點只能一臺，限制了寫入的效率。（分佈式解決，redis-cluster 解決）
爲什麼要用 Redis-Sentinel，我們再說下手動轉移有什麼問題：
1、怎麼判定主節點的故障？
2、如何通知之前連接老主節點的客戶端改爲現在的客戶端？
3、如何保證這裏手動轉移一整套流程的事務性？
上述雖然可以用腳本實現，但是要把整個故障轉移腳本各個方面都考慮完美的話還是不容易。
那現在 Redis-Sentinel 就能解決這些問題。
二、實現原理
我們可以通過上圖看到Redis Sentinel 是怎麼實現高可用的：
首先 監控主從：Redis sentinel 通過 3 個定時任務完成對 主節點，從節點，sentinel （對的，實際上所有都監控）的監控。
1、每隔10秒，通過向主節點發送 info 命令， 從節點的信息。 （意義：實時維護主從節點的拓撲關係）
2、每隔2秒，sentinel 會向主節點的 __sentinel__:hello 頻道 推送 當前sentinel 對主節點的判斷 並訂閱 這個頻道獲取其他sentinel對於主節點的判斷信息。（意義：發現新的sentinel節點信息 和 sentinel 節點間交換節點信息爲選取領導者做準備）
3、每隔1秒，sentinel 會對其餘sentinel，master，slave 節點發送ping命令 來進行心跳檢測，檢查這些節點是否正常（主觀下線的依據）。
前兩個定時任務都是爲了維護主從節點關係和sentinel節點關係做準備，真正發現問題的是 第三個定時任務。
接着是發現故障：sentinel 在執行ping 心跳檢測的時候，如果被檢測節點超過 down-after-milliseconds 時間都沒回復，則當前sentinel認爲這個被檢測節點 主觀下線（sdown），主觀下線是一家之言，可能存在誤判。
當這個sentinel 節點發現這個被檢查是主節點的時候，會通知其他sentinel 去檢查這個主節點是否下線，當所有sentinel節點中超過 <quorum> 個任務主節點主觀下線的時候這個主節點才被當做真正下線，也就是客觀下線（odown）。
注意：這裏如果檢查到出問題的節點是從節點或者sentienl 節點時，sentinel 進行主觀下線後即不存在後續的操作。
最後是解決故障：解決故障有兩個步驟：
1、因爲去真正去處理故障只需一個sentinel即可，所以這時需要選一個sentinel 領導人，Redis 採用 Raft算法實現，大致步驟可以參考《Redis開發與運維》p259 ：
2、故障轉移：
a：發現最合適的從節點。先過濾不健康（主觀下線，斷線，超時等）的slave節點，選擇slave-priority（從節點優先級）最高的，不存在最高的優先級的時候返回複製偏移量最大的從節點（複製的最完整）。複製偏移量模糊的可以看我的 redis學習日記（三）：Redis 主從複製
b：先執行 slavof no one 成爲主節點。
c：再將這個新的主節點成爲剩餘從節點的主節點。
d：將原來的主節點更新爲從節點，並保持關注，等其恢復後去複製新的主節點。