通過前面的三個篇章的認知學習與實踐，相信大家搭建自己的docker redis主從應該是沒有任何問題了。普通的主從複制到此就結束了，下面我們要來分析講解，普通主從複制的更新版“哨兵叢集”。哨兵叢集一共分為“理論”、“配置”、“實踐”和“日常問題的解決方案”四個次元的篇章來講解。本篇文章就是第一個階段“理論”。
回顧下主從複制的問題：
先看一張圖：
我們可以很清楚的發現主從複制的一個緻命的缺點，當主機Master節點當機了以後，我們就需要人工解決切換。
由此可見我們的普通主從複制并沒有達到我們預期中的“高可用”，其對高可用的了解是側重于備份機器，是利用叢集中系統的備援，當系統中某台機器損壞的時候，其他後備的機器可以迅速的來做替換，為平台繼續提供服務的一種機制。一旦主機當機，寫服務将無法使用，就需要我們手動去切換，選取某個節點為主節點并手動配置我們的主從關系來繼續提供服務，如果對于龐大的網站來說，這不光光是崩潰簡直就是災難性的，況且誰又能大半夜的去看着主機是否正常運作而沒有當機呢？對此，我們又該如何去解決呢？那就是我們今天要講的“哨兵叢集”強勢來襲。
哨兵機制的原理及實作
Redis Sentinel 是一個分布式架構，其中包含若幹個 Sentinel 節點和 Redis 資料節點，每個 Sentinel 節點會對資料節點和其餘 Sentinel 節點進行監控，當它發現節點不可達時，會對節點做下線辨別。如果被辨別的是主節點，它還會和其他 Sentinel 節點進行“協商”，當大多數 Sentinel 節點都認為主節點不可達時，它們會選舉出一個 Sentinel 節點來完成自動故障轉移的工作，同時會将這個變化實時通知給 Redis 應用方。整個過程完全是自動的，不需要人工來介入，是以這套方案很有效地解決了 Redis 的高可用問題。
如圖所示：
基本的故障轉移流程圖如下：
- 主節點出現故障，此時兩個從節點與主節點失去連接配接，主從複制失敗。
- 每個 哨兵Sentinel 節點通過定期監控發現主節點出現了故障
- 多個 哨兵Sentinel 節點對主節點的故障達成一緻會選舉出其中一個節點作為上司者負責故障轉移。
- 哨兵Sentinel 上司者節點執行了故障轉移，整個過程基本是跟我們手動調整一緻的，隻不過是自動化完成的。
- 故障轉移後整個 Redis Sentinel 哨兵叢集的結構,重新選舉了新的主節點，并且曾經的主節點變成從節點
Redis Sentinel哨兵叢集 具有以下幾個功能
- 監控：哨兵Sentinel 節點會定期檢測 Redis 資料節點、其餘 哨兵Sentinel 節點是否可達。
- 通知：哨兵Sentinel 節點會将故障轉移的結果通知給應用方。
- 主節點故障轉移：實作從節點晉升為主節點并維護後續正确的主從關系。
- 配置提供者：在 Redis Sentinel 結構中，用戶端在初始化的時候連接配接的是 Sentinel 節點集合，從中擷取主節點資訊。
- 同時Redis Sentinel 包含了若等個 哨兵Sentinel 節點，這樣做也帶來了兩個好處：
- 對于節點的故障判斷是由多個 哨兵Sentinel 節點共同完成，這樣可以有效地防止誤判。
- 哨兵Sentinel 節點集合是由若幹個 Sentinel 節點組成的，這樣即使個别 Sentinel 節點不可用，整個 Sentinel 節點集合依然是健壯的。
- Sentinel 節點本身就是獨立的 Redis 節點，隻不過它們有一些特殊，它們不存儲資料，隻支援部分指令哨兵
通過本文篇章，我們了解到了哨兵叢集的機制和工作方式，讓我們看到了最大化的優勢，有沒有一點小激動呢？我們下個篇章就開始搭建我們的redis的哨兵Sentinel叢集，一起見證 哨兵叢集的強大之處。
======歡迎大家關注的專欄=========同時也謝謝大家的支援，我們一起努力，敬請期待下一篇章。