Redis 常見的集群架構
以下是 Redis 常見的集群架構及其核心模式詳解，結合其設計原理、適用場景和優缺點進行綜合說明：
一、主從復制模式
架構原理
- 角色劃分：包含一個主節點（Master）和多個從節點（Slave）。主節點處理所有寫操作，從節點通過異步復制同步主節點數據，僅支持讀操作。
- 數據同步：首次連接時從節點觸發全量同步（RDB快照），后續通過增量命令（AOF）保持數據一致性。
- 手動故障恢復：主節點宕機時需人工干預將從節點提升為新主節點。
優缺點
- 優點：讀寫分離提升讀性能；部署簡單，適合小規模場景。
- 缺點：無自動故障轉移；數據量受單機內存限制；主節點宕機導致寫服務中斷。
適用場景：數據備份、讀請求遠多于寫的場景（如緩存系統）。
架構圖 ：
二、哨兵模式（Sentinel）
架構原理
- 哨兵集群：由多個哨兵節點組成，監控主從節點狀態，通過 Raft 算法選舉 Leader 哨兵主導故障轉移。
- 自動故障切換：主節點客觀下線后，根據優先級、復制偏移量等規則選舉新主節點，并通知客戶端更新配置。
- 弱一致性：數據同步異步進行，故障轉移期間可能出現短暫數據不一致。
優缺點
- 優點：高可用性，自動容錯；支持讀寫分離。
- 缺點：數據存儲未分片，內存和寫入性能受單節點限制；需額外維護哨兵集群。
適用場景：中小規模系統，需高可用但無需分片的場景（如核心業務緩存）。
架構圖 ：
?
三、Cluster 模式（官方分布式方案）
架構原理
- 數據分片：通過哈希槽（16384個槽位）將數據分布到多個主節點，客戶端請求由節點自動路由。
- 多主多從：每個主節點對應一至多個從節點，支持自動故障轉移。默認情況下 從節點只是做為熱備節點，不參與讀。從而保證數據一致性
- 去中心化：節點間通過 Gossip 協議通信，無需依賴外部代理。
優缺點
- 優點：支持橫向擴展；高可用性與高性能結合；數據分散存儲突破單機內存限制。
- 缺點：不支持跨節點事務和多鍵操作（如 MGET）；配置復雜度較高。
適用場景：大規模數據存儲和高并發場景（如電商庫存系統）。
架構圖：
?
四、 代理模式 （第三方擴展方案）
1. Codis
-
架構：通過代理層（Codis-Proxy）實現數據分片，依賴 ZooKeeper 管理元數據。
-
特點：支持平滑擴容；兼容 Redis 協議，客戶端無感知。
-
缺點：需修改 Redis 源碼（codis-server）；依賴外部組件（如 ZooKeeper）。
-
架構圖 ：
2. Twemproxy
- 架構：輕量級代理，支持多 Redis 實例分片和負載均衡。
- 特點：部署簡單；性能損失約 20%。
- 缺點：代理層單點故障；不支持動態擴縮容。
適用場景：需快速實現分片但暫不遷移至 Cluster 的過渡方案。
五、模式對比與選型建議
| 模式 | 數據分片 | 自動容錯 | 擴展性 | 適用規模 |
|---|---|---|---|---|
| 主從復制 | ? | ? | 低（垂直擴展） | 小數據量、低并發 |
| 哨兵模式 | ? | ? | 中（主從復制） | 中小規模高可用場景 |
| Cluster 模式 | ? | ? | 高（水平擴展） | 海量數據、高并發 |
| Codis/Twemproxy | ?（代理層） | ? | 中（依賴代理配置） | 過渡或特定分片需求 |
選型建議：
- 優先選擇 Redis Cluster：適用于大規模分布式場景，兼顧分片與高可用。
- 慎用主從/哨兵模式：僅適合數據量小且無分片需求的場景。
- 代理模式的妥協：在無法升級到 Cluster 時選擇，但需權衡運維成本。
-01)
)
)
