在現代應用架構中，Redis憑藉其驚人的性能和豐富的數據結構，早已成為緩存、會話存儲和消息隊列等場景的基石。然而，當我們享受其帶來的速度與便利時，一個核心一個核心問題無法迴避：如果這台Redis服務器宕機了，怎麼辦？
單個節點的故障足以導致整個應用的雪崩。因此，因此，構建一個高可用（High Availability） 的Redis環境，確保服務在部分節點失敗時依然能夠持續對外提供服務，是每個嚴肅的技術團隊必須面對的課題。
本文將帶你從理論到實踐，徹底搞懂Redis的高可用方案。
一、高可用的基石：複製（Replication）
任何Redis高可用方案都始於數據冗餘，而實現冗餘的核心就是主從複製。
- 異步或半同步地複製主節點的數據。
優點： 數據
數據備份：從節點是主節點的完美熱備。
讀寫分離：通過將讀請求分發到多個從節點，可以極大地提升系統的讀吞吐量，減輕主節點壓力。
缺點： 故障不自動切換：如果主如果主節點宕機，需要人工干預*將從節點提升為主節點，並修改客户端配置，會帶來顯著的服務中斷時間。
單純的主從複製實現了數據冗餘，但未實現自動故障轉移，因此還算不上真正的高可用。
二、經典的守護者：Redis Sentinel（哨兵）
Sentinel是Redis官方提供的高可用解決方案。它本質上是一個分佈式系統，由多個Sentinel進程inel進程組成，用於監控Redis實例，並在主節點發生故障時，自動進行故障轉移。
哨兵架構是如何工作的？
假設你有一個主節點、兩個從節點從節點和三個Sentinel進程。
1.監控（Monitoring）：每個Sentinel會以每秒一次的頻率，向所有主、從節點以及其他Sentinel發送PING命令。通過回覆來判斷來判斷實例是否“主觀下線”。
2.判斷下線（Detection）：
主觀下線（Subjectively Down, SDOWN）：如果一個實例在配置的時間內沒有有效回覆PING，某個Sent某個Sentinel就會將其標記為“主觀下線”。
客觀下線（Objectively Down, ODOWN）：當足夠數量（通常需要超過半數，如3個Sentinel中的2個）的Sentinel都將一個主一個主節點報告為“主觀下線”時，該主節點就會被標記為“客觀下線”，此時故障轉移的條件被觸發。
3.選舉與故障轉移（Election & Failover）：
Sentinel集羣會通過Raft算法選舉出一個領導者（Leader） Sentinel來負責本次故障轉移。
領導者Sentinel會從剩餘的從節點中，根據優先級、複製偏移量等規則選出一個最合適的從節點。
向其發送 SLAVEOF NO ONE 命令，將其提升為新的主節點。
然後，通過發佈訂閲功能通知其他從節點修改配置文件，開始從新的主節點複製數據。 *最後，它會將舊的主節點更新為新的主節點的從節點，當其恢復後，會自動成為新主的副本。
優點： 官方原生，成熟穩定。
全自動故障轉移，大大縮短了服務中斷時間。 *客户端通過與Sentinel交互，可以動態獲取當前的主節點地址。
不足：
部署和配置稍顯複雜。
故障轉移期間可能存在數據丟失（異步複製的固有缺陷）。
寫操作仍然集中在單個主節點，無法水平擴展寫能力。
三、面向未來的方案：Redis：Redis Cluster（集羣）
如果你需要的不僅僅是高可用，還包括海量數據存儲和水平擴展寫能力，那麼Redis Cluster是你的終極選擇。
Redis Cluster採用無中心架構，數據被分片（Sharding） 到16384個槽（slot）中，每個節點負責一部分槽。
集羣如何保證高可用？
它同樣採用了主從複製模型，但理念不同：
數據分片：假設你有三個主節點（A, B, C），每個節點負責大約5461個槽。你的數據會根據key的CRC16校驗和映射到這16384個槽中的一個，從而決定存儲在哪個主節點上。
主從冗餘：為每個主節點（如A）配置一個或多個從節點（A1）。從節點複製對應主節點的全部數據。
故障檢測與轉移： *集羣中的每個節點都會與其他所有節點定期通信（Gossip協議）。
當某個主節點被其大多數主節點認為失聯時，它將被標記為FAIL狀態*狀態。 *此時，該主節點對應的從節點會發起投票競選，獲勝者將接管原主節點負責的所有槽，晉升為新的主節點。
優點： 無縫水平擴展：可以通過增加節點輕鬆擴容數據和讀寫性能。
內置高可用：具備Sentinel類似的自動故障轉移能力。
無需代理，客户端可以直接連接到正確的節點。
挑戰： 客户端需要支持集羣協議（大多數主流客户端都已支持）。 *操作和維護相對複雜，特別是擴縮容時的槽遷移。 *不支持跨多個鍵的操作（除非這些鍵在同一個槽），這限制了某些命令的使用。
四、如何選擇？一張圖看懂
|
特性 |
主從複製 |
Redis Sentinel |
Redis Cluster |
|
--- |
|
|
|
|
數據備份 |
✅ |
✅ |
✅ |
|
讀擴展 |
✅ |
✅ |
✅ |
|
自動故障轉移 |
❌ |
✅ |
✅ |
|
寫擴展 |
❌ |
❌ |
✅ |
|
數據分片 |
❌ |
❌ |
✅ |
|
複雜度 |
低 |
中 |
高 |
|
適用場景 |
數據備份、讀寫分離 |
絕大多數業務場景下的高可用需求 |
海量數據、高性能要求的緩存/存儲 |
結論與實踐建議
對於絕大多數追求高可用的場景，Redis Sentinel是當下最平衡和最推薦的選擇。它在提供自動化保障的同時，保持了相對簡單的架構。
而在構建你的高可用Redis時，請牢記以下最佳實踐：
1.至少三節點：無論是Sentinel還是Cluster，部署至少3個節點（且分佈在不同的物理機/虛擬機），以防止腦裂並提供可靠的仲裁。
2.持久化策略：即使有從節點，也請確保主節點開啓了appendonly yes（AOF持久化），並結合appendfsync everysec，在性能和可靠性間取得平衡。
3.資源隔離：不要讓Sentinel進程與Redis實例爭奪資源，最好將它們分開部署。
4.客户端兼容性：確認你的客户端庫完全支持Sentinel或Cluster協議，並進行充分的故障演練。
高可用不是一項功能，而是一個貫穿設計、部署和運維始終的體系。理解了Redis提供的這些武器，你就能根據自己業務的規模和重要性，構建出堅如磐石的數據服務層。
希望這篇文章能幫助你係統地理解Redis的高可用方案。如果有任何疑問，歡迎在評論區討論！
