一、基本概念
- 由於對Redis的許多概念都有不同的名詞解釋，所以在介紹Redis Sentinel之前，先對幾個名詞進行說明，這樣便於在後面的介紹中達成一 致，如下圖所示
- Redis Sentinel是Redis的高可用實現方案，在實際的生產環境中，對提高整個系統的高可用性是非常有幫助的
二、主從複製的問題
- Redis的主從複製模式可以將主節點的數據改變同步給從節點，這樣從節點就可以起到兩個作用：
- 第一，作爲主節點的一個備份，一旦主節點出了故障不可達的情況，從節點可以作爲後備“頂”上來，並且保證數據儘量不丟 失（主從複製是最終一致性）
- 第二，從節點可以擴展主節點的讀能力，一 旦主節點不能支撐住大併發量的讀操作，從節點可以在一定程度上幫助主節點分擔讀壓力
- 但是主從複製也帶來了以下問題：
- 一旦主節點出現故障，需要手動將一個從節點晉升爲主節點，同時需要修改應用方的主節點地址，還需要命令其他從節點去複製新的主節點，整個過程都需要人工干預
- 主節點的寫能力受到單機的限制
- 主節點的存儲能力受到單機的限制
- 其中第一個問題就是Redis的高可用問題，是屬於Redis Sentinel的範疇。 第二、三個問題屬於Redis的分佈式問題，在後面“Redis分佈式”文章中再介紹
三、故障轉移演示
- Redis主從複製模式下，一旦主節點出現了故障不可達，需要人工干預進行故障轉移，無論對於Redis的應用方還是運維方都帶來了很大的不便
- 對於應用方來說無法及時感知到主節點的變化，必然會造成一定的寫數據丟失和讀數據錯誤，甚至可能造成應用方服務不可用
- 對於Redis的運維方來說，整個故障轉移的過程是需要人工來介入的，故障轉移實時性和準確性上 都無法得到保障
故障轉移演示
- 下面展示了一個1主2從的Redis主從複製模式下的 主節點出現故障後，是如何進行故障轉移的，過程如下所示
- ①如下圖所示，主節點發生故障後，客戶端（client）連接主節點失敗，兩個從節點與主節點連接失敗造成複製中斷
- ②如下圖所示，如果主節點無法正常啓動，需要選出一個從節點 （slave-1），對其執行slaveof no one命令使其成爲新的主節點
- ③如下圖所示，原來的從節點（slave-1）成爲新的主節點後，更新應 用方的主節點信息，重新啓動應用方
- ④如下圖所示，客戶端命令另一個從節點（slave-2）去複製新的主節 點（new-master）
- ⑤如下圖所示，待原來的主節點（old master）恢復後，讓它去複製新的主節點
- 上述處理過程就可以認爲整個服務或者架構的設計不是高可用的，因爲整個故障轉移的過程需要人介入。考慮到這點，有些公司把上述流程自動化了，但是仍然存在如下問題：
- 第一，判斷節點不可達的機制是否健全和標準
- 第二，如果有多個從節點，怎樣保證只有一個被晉升爲主節點
- 第三， 通知客戶端新的主節點機制是否足夠健壯
- Redis Sentinel正是用於解決這些問題
四、Redis Sentinel的高可用性
- 當主節點出現故障時，Redis Sentinel能自動完成故障發現和故障轉移， 並通知應用方，從而實現真正的高可用
- 注意：Redis2.6版本提供Redis Sentinel v1版本，但是功能性和健壯性都有一些問題，如果想使用Redis Sentinel的話，建議使用2.8以上版本，也就是v2版本的Redis Sentinel
- 工作原理：
- Redis Sentinel是一個分佈式架構，其中包含若干個Sentinel節點和Redis數據節點，每個Sentinel節點會對數據節點和其餘Sentinel節點進行監控，當它發現節點不可達時，會對節點做下線標識
- 如果被標識的是主節點，它還會和其他Sentinel節點進行“協商”，當大多數Sentinel節點都認爲主節點不可達時，它們會選舉出一個Sentinel節點來完成自動故障轉移的工作，同時會將這個變化實時通知給Redis應用方
- 整個過程完全是自動的，不需要人工來介入，所以這套方案很有效地解決了Redis的高可用問題
- 注意：這裏的分佈式是指：Redis數據節點、Sentinel節點集合、客戶端分佈在多個物理節點的架構，不要與後面文章要介紹的“Redis Cluster分佈式”混淆
- 如下圖所示，Redis Sentinel與Redis主從複製模式只是多了若干Sentinel 節點，所以Redis Sentinel並沒有針對Redis節點做了特殊處理，這裏是很多開發和運維人員容易混淆的
- 從邏輯架構上看，Sentinel節點集合會定期對所有節點進行監控，特別是對主節點的故障實現自動轉移
Redis Sentinel故障轉移演示
- 下面以1個主節點、2個從節點、3個Sentinel節點組成的Redis Sentinel爲例子進行說明，拓撲結構如下圖所示：
- 整個故障轉移的處理邏輯有下面4個步驟：
- ①如下圖所示，主節點出現故障，此時兩個從節點與主節點失去連接，主從複製失敗
- ②如下圖所示，每個Sentinel節點通過定期監控發現主節點出現了故 障
- ③如下圖所示，多個Sentinel節點對主節點的故障達成一致，假設此處選舉出sentinel-3節點作爲領導者負責故障轉移
- ④如下圖所示，Sentinel領導者節點執行了故障轉移，整個過程和上面“三”中介紹的是完全一致的，只不過是自動化完成的
- 故障轉移後整個Redis Sentinel的拓撲圖如下所示
五、Redis Sentinel的幾個功能
- 通過上面介紹的Redis Sentinel邏輯架構以及故障轉移的處理，可以看出Redis Sentinel具有以下幾個功能：
- 監控：Sentinel節點會定期檢測Redis數據節點、其餘Sentinel節點是否 可達
- 通知：Sentinel節點會將故障轉移的結果通知給應用方
- 主節點故障轉移：實現從節點晉升爲主節點並維護後續正確的主從關係
- 配置提供者：在Redis Sentinel結構中，客戶端在初始化的時候連接的 是Sentinel節點集合，從中獲取主節點信息
- 同時看到，Redis Sentinel包含了若個Sentinel節點，這樣做也帶來了兩個好處：
- 對於節點的故障判斷是由多個Sentinel節點共同完成，這樣可以有效地防止誤判
- Sentinel節點集合是由若干個Sentinel節點組成的，這樣即使個別Sentinel節點不可用，整個Sentinel節點集合依然是健壯的
- 但是Sentinel節點本身就是獨立的Redis節點，只不過它們有一些特殊， 它們不存儲數據，只支持部分命令。下一篇將完整介紹Redis Sentinel的部署過程，相信在安裝和部署完Redis Sentinel後，讀者能更清晰地瞭解Redis Sentinel的整體架構