---

Pre

Redis-入門到精通

Redis進階系列

Redis進階 - Redis主從工作原理詳解

Redis-18Redis主從同步

Redis-19Redis哨兵Sentinel模式-Centos6.5上3臺主機1主2從3哨兵的配置及通過代碼訪問哨兵

---

概述

為了提升對高并發實時數據訪問的性能，數據緩存組件應運而生，其中比較常見的就是Memcache和Redis。

Memcache是經典的內存緩存技術，對相關領域的支持比較豐富，各種框架都支持使用該技術。應用系統中經常用到的會話信息可以非常方便地保存到Memcache中，每個鍵保存的數據量最大為1 MB，支持的數據類型比較單一，僅支持字符串類型（string），不支持持久化操作。

Redis支持比較多的數據類型（string、list、set、sortset、hash），也支持集合計算（set類型），每個鍵的最大數據量為1 GB，支持持久化操作。Redis一般配合后端數據庫使用，其存放的一般是用戶當前頻繁使用的數據。

組件	優點	缺點
Memcache	1. 支持客戶端式分布式集群 2. 一致性哈希多核結構 3. 多線程讀寫性能高 4. 內存分配效率高	1. 不支持持久化 2. 僅支持字符串類型 3. 節點故障可能引發緩存穿透 4. 分布式需客戶端實現 5. 單鍵最大1MB 6. 擴容復雜度高
Redis	1. 支持5種數據類型（String/List/Set/ZSet/Hash） 2. 支持持久化（RDB/AOF） 3. 高可用架構（主從+哨兵） 4. 支持分布式分片集群 5. 單線程無鎖高性能 6. 單鍵最大1GB	1. 多線程并發讀寫性能低于Memcache 2. 內存碎片問題需定期清理 3. 集群模式下部分命令受限（如跨節點事務） 4. 持久化可能影響瞬時性能

---

Redis 高可用實現方案

Redis 實現高可用主要依靠兩大機制：主從復制與哨兵監控。

---

一、主從復制機制

Redis通過主從復制實現數據冗余與讀寫分離，支持全量同步和增量同步兩種模式。

1.1 全量同步流程

當從服務器首次連接主服務器或數據差異過大時觸發全量同步：

全量同步流程：

1. 從服務器發送 SYNC 命令：從服務器請求與主服務器建立復制關系。
2. 主服務器生成 RDB 快照：接收到 SYNC 命令后，主服務器調用 BGSAVE 命令生成 RDB 文件，同時啟動緩沖區記錄后續所有的增量命令。
3. 傳輸 RDB 文件：主服務器將 RDB 快照發送給從服務器。
4. 從服務器加載 RDB 文件：從服務器加載快照文件，完成數據初步同步。
5. 增量命令同步：主服務器從緩沖區讀取斷線期間的命令，發送給從服務器，從服務器執行后續寫入操作。

---

1.2 增量同步（PSYNC）流程

在理解增量同步之前需要了解下面幾個概念

• 復制偏移量：執行復制的主從服務器會以字節為單位維護一個復制的偏移量（offset）。
• 復制緩沖區：一個先進先出（first in first out，FIFO）的隊列，用于存儲服務器執行過的命令，每次執行命令時主服務器都會將命令記錄下來，并存儲在復制緩沖區。命令存儲的僅僅是數據變更的操作，復制緩沖區的大小是1 MB。
• 服務器運行ID：每個Redis服務器會在啟動時生成自己的服務器運行ID（runid），主服務器會將自己的運行ID發送給從服務器，從服務器將其保存起來，當主從服務器斷線重連之后就可依據這一ID來判斷當前主服務器是否是之前的主服務器，如果是，則啟動增量同步，否則啟動全量同步。

Redis 2.8+版本引入PSYNC命令優化斷線重連場景：

核心邏輯：

• 通過runid驗證主服務器身份
• 通過offset判斷數據差異是否超出緩沖區容量（默認1MB）
• 增量同步僅傳輸丟失的命令，避免全量復制

PSYNC命令的執行流程。

• （1）客戶端向服務器發送SLAVEOF命令，讓當前服務器成為從服務器。
• （2）從服務器根據自己是否保存主服務器的運行ID來判斷是否是第一次復制，如果是第一次復制，則繼續執行第3步，否則跳轉到第4步。
• （3）從服務器向主服務器發送PSYNC ? -1命令進行全量同步。
• （4）從服務器向主服務器發送PSYNC runid offset命令進行增量同步。
• （5）主服務器接收到PSYNC 命令后，先判斷runid是否與本機ID一致，如果一致，則會再次判斷offset和本機的偏移量差距有沒有超過復制緩沖區大小，如果沒有，就給從服務器發送CONTINUE命令，此時從服務器只需要等待主服務器傳回失去連接期間丟失的命令。
• （6）如果runid和本機ID不一致或者雙方偏移量差距超過復制緩沖區大小，就會發送FULLRESYNC runid offset命令，從服務器將runid保存起來，并進行全量同步。

---

二、哨兵監控機制

主從復制雖然實現了數據同步，但主服務器宕機后寫操作將無法進行。為解決此問題，Redis 提供了哨兵（Sentinel）機制，主要功能包括：

• 監控（Monitoring）：持續檢查主從服務器的運行狀態。
• 通知（Notification）：在檢測到故障時，通過 API 向管理員或其他應用程序發送通知。
• 自動故障遷移（Automatic Failover）：當主服務器失效時，從剩余從服務器中選舉出一個新主服務器，并指示其他從服務器切換復制目標，同時向客戶端返回新主服務器的地址。

---

2.1 故障轉移時序流程

核心功能：

1. 監控：多哨兵節點協同檢測主服務器狀態
2. 選舉：基于Raft算法選舉領頭哨兵
3. 故障轉移：
   • 提升從服務器為新主節點
   • 修改其他從服務器復制目標
   • 更新客戶端連接地址

---

三、方案對比與選型建議

方案	適用場景	限制條件
主從復制	數據冷備份、讀寫分離	主節點故障需手動切換
哨兵模式	自動故障轉移的高可用場景	需要至少3個哨兵節點保障決策

推薦組合：主從復制+哨兵模式，兼顧數據冗余與自動容災。

---

四、生產環境實踐建議

1. 網絡優化：主從節點盡量部署在同機房
2. 內存配置：主節點內存建議為最大數據量的1.5倍
3. 監控指標：
   • 主從復制延遲（master_repl_offset）
   • 哨兵節點的ping響應時間
4. 避免使用KEYS *等阻塞命令影響同步性能

通過合理配置主從復制與哨兵監控，可構建秒級故障恢復的高可用Redis集群。