Redis04——五分鐘明白Redis的哨兵模式

和全部的數據庫同樣，Redis也支持集羣化，Redis的集羣分爲分佈式集羣和主從集羣。大部分公司採起的都是主從集羣。因此在本篇文章內，咱們將着重介紹Redis的主從集羣及哨兵機制。

因爲Redis的主從同步是異步進行的，因此Redis主從集羣不知足事務的一致性，同時Redis在主從網絡不可用的狀況下，主節點依舊能夠提供服務，因此Redis主從集羣知足事物的可用性。Redis只能保證數據的最終一致性。

主從同步

Redis的主從同步主要是經過如下幾種方式來進行同步的。

增量同步

增量同步，本質上是同步的主節點的修改指令。即Redis主節點將全部key的修改指令寫入到一段定長的內存緩衝區中，而後將修改指令同步到從節點，同時從節點將指令執行狀況（偏移量）反饋到主機節點，以此來進行主從同步。

注意：因爲主節點的指令緩衝區是定長的，因此當緩衝區寫滿後，又會緩衝區起始位置開始覆蓋寫入新的指令。

快照同步

當某種緣由（如主從網絡延遲、從節點執行指令效率太低等）致使增量同步的數據不一致的時候，就須要快照同步來修復數據。快照同步首先須要將主節點上的數據進行一次bgsave，將內存數據所有持久化到磁盤，而後同過網絡傳輸到從節點，寫入從節點磁盤。從節點再使用快照加載數據，當數據加載完成後，從節點反饋給主節點，繼續進行增量同步。

注意：當主節點的指令緩衝區設置太小時，會致使快照同步陷入死循環，所以主機節點的指令緩衝區必定要設置合理。

無盤複製

本質上至關於快照同步，只不過少了主節點數據寫入磁盤的步驟，換成主節點內存數據直接寫入從節點的磁盤，而後繼續快照同步的後續操做 。

哨兵模式

什麼是哨兵

在傳統的Redis主從集羣中，主節點一旦出現故障，須要人工介入干預，切換集羣的主從節點，同時通知應用方，這無疑是沒法接受的。使人高興的是Redis從2.8版本以後，開始支持哨兵模式了，改變了傳統的人肉運維方式。

哨兵的做用是什麼

Sentinel（哨兵）主要負責持續監控Redis主從集羣的健康，並負責實現主從集羣的自動選主過程，同時將選主結果通知到客戶端。

哨兵是如何完成主從集羣選主的

哨兵模式主要分爲哨兵節點和數據節點（圖中的Master 和 Slave節點），一次完整的選主流程以下：

1. 在該模式下，客戶端首先會遍歷全部的哨兵，獲取主節點信息，而後鏈接到主節點；

2. 在主從集羣內部其運轉以下：

2.1. 每一個哨兵節點向全部數據節點發送每十秒鐘一次的ping信息；

2.2. 若一個數據節點距離最後一次ping成功的時間超過預設值，則該節點被哨兵認爲是主觀下線；

2.3. 當Master節點被標記爲主觀下線時，全部哨兵節點都會以每秒一次的頻率確認Master是否真的進入了主觀下線；

2.4. 當超過必定數量的哨兵都確認Master進入了主觀下線後，Master會被標記爲客觀下線；

2.5. 若在此過程當中Master恢復了對哨兵ping請求的響應，Master會被移除主觀下線標記；

2.6. 當Master被客觀下線後，哨兵會重新選擇合適的從節點升級爲主節點；

2.7. 新的選主完成後，將從新全部節點的主從配置文件，同時全部從節點將重新的主節點同步數據；

2.8. 若選主流程的時間超過預設值後，選主將會失敗；

3. 主從集羣內部選主完成後，哨兵會利用Redis是Pub/Sub（發佈/訂閱）功能，通知客戶端從新初始化鏈接池，鏈接到新的主節點。

Redis系列推薦

Redis03——Redis是如何刪除你的數據的

Redis02——Redis內存數據如何保存到磁盤

Redis01——Redis究竟支持哪些數據結構