### 從節點的作用 * **從節點一般可以起到兩個作用：** * **第一，**當主節點出現故障時，作為主節點的后備“頂”上來實現故障轉移，Redis Sentinel已經實現了該功能的自動化，實現了真正的高可用 * **第二，**擴展主節點的讀能力，尤其是在讀多寫少的場景非常適用，通常的模型如下圖所示  **但上述模型中，從節點不是高可用的：** * 如果slave-1節點出現故障，首先客戶端client-1將與其失聯，其次Sentinel節點只會對該節點做主觀下線，因為Redis Sentinel的故障轉移是針對主節點的 * 所以很多時候，Redis Sentinel中的從節點僅僅是作為主節點一個熱備，不讓它參與客戶端的讀操作，就是為了保證整體高可用性，但實際上這種使用方法還是有一些浪費，尤其是在有很多從節點或者確實需要讀寫分離的場景，所以如何實現從節點的高可用是非常有必要的; ### Redis Sentinel讀寫分離設計思路 * Redis Sentinel在**對各個節點的監控中，如果有對應事件的發生，都會發出相應的事件消息**（詳情見上面“Sentinel發布訂閱頻道”圖片），**其中和從節點變動的事件有以下幾個：** * **+switch-master：**切換主節點（原來的從節點晉升為主節點），說明減少了某個從節點 * **+convert-to-slave：**切換從節點（原來的主節點降級為從節點），說明添加了某個從節點 * **+sdown：**主觀下線，說明可能某個從節點可能不可用（因為對從節點不會做客觀下線），所以在實現客戶端時可以采用自身策略來實現類似主觀 下線的功能 * **+reboot：**重新啟動了某個節點，如果它的角色是slave，那么說明添加了某個從節點 * **所以在設計Redis Sentinel的從節點高可用時，只要能夠實時掌握所有從節點的狀態，把所有從節點看做一個資源池**（如下圖所示），無論是上線還是下線從節點，客戶端都能及時感知到（將其從資源池中添加或者刪除），這樣從節點的高可用目標就達到了;