在實際工作中，我們使用的 Redis 高可用模式有兩種：Redis Cluster 和 Redis Sentinel，那么，這兩種模式有什么區別？我們該如何選擇？這篇文章，我們將深入分析。

一、Redis Sentinel模式

1. 什么是Redis Sentinel?

Redis Sentinel是 Redis 官方提供的高可用性解決方案，旨在監控 Redis 主從復制集群，檢測故障并執行自動故障轉移。Sentinel 主要負責以下幾個方面：

• 監控（Monitoring）： 持續監控主節點和從節點的運行狀態。
• 通知（Notification）： 在發現問題時，通過 API 或腳本通知管理員或其他系統。
• 自動故障轉移（Automatic Failover）： 當主節點發生故障時，自動將一個從節點提升為新的主節點，并重新配置剩余的從節點。
• 配置提供者（Configuration Provider）： 提供客戶端獲取當前主節點的信息，確保客戶端能夠連接到正確的主節點。

Redis Sentinel核心結構如下圖：

2. Sentinel的工作原理

Sentinel 以分布式的方式運行，通常部署多個 Sentinel 實例（推薦至少三個），以避免單一 Sentinel 實例的故障影響整個系統。Sentinel 通過選舉機制選出領導者，負責協調故障檢測和故障轉移的過程。主要包含以下 5個步驟：

• 監控： Sentinel 實例定期向主節點和從節點發送心跳，檢查它們的可達性和健康狀態。
• 故障檢測： 當 Sentinel 發現某個節點連續多次未響應心跳，就將其標記為疑似故障（S_DOWN，Subjectively Down）。
• 達成共識： 多個 Sentinel 實例需要達成一致，確認該節點確實故障（O_DOWN，Objectively Down）。
• 故障轉移： 選舉一臺從節點作為新的主節點，并將其余從節點指向新的主節點。
• 通知客戶端： 更新客戶端的連接信息，使其連接到新的主節點。

3. Sentinel的優勢

• 簡單易用： 配置和部署相對簡單，適合中小規模的 Redis 部署。
• 故障轉移自動化： 提供自動的主從切換，減少了人工干預的需求。
• 客戶端通知支持： 通過 Sentinel APIs，客戶端可以動態獲取主節點信息，適應故障轉移后的變化。

4. Sentinel的限制

• 單一數據存儲： Sentinel 并不支持數據的分片和擴展，只能在單一 Redis 實例上進行主從復制。
• 擴展性有限： 隨著數據量和請求量的增加，無法通過增加節點來水平擴展系統容量。
• 配置復雜度： 在多種場景下，配置和管理 Sentinel 集群可能較為復雜，尤其是在大規模部署中。

二、Redis Cluster模式

1. 什么是Redis Cluster?

Redis Cluster 也是 Redis 官方提供的分布式數據存儲方案，旨在實現數據的自動分片和高可用性。通過將數據分布到多個主節點上，Redis Cluster 提供了線性的擴展能力，并結合了主從復制機制，確保數據的冗余和容錯能力。

Redis Cluster核心結構如下圖：

2. Cluster的核心特性

• 數據分片（Sharding）： Redis Cluster 將數據按照哈希槽（Hash Slots）分布到多個主節點，每個主節點管理一定范圍的槽。
• 高可用性： 每個主節點可以配置多個從節點，確保在主節點故障時能夠自動進行故障轉移。
• 無中心化管理： Cluster 采用分布式架構，沒有單點故障，所有節點在運行時通過 Gossip 協議互相通信和維護狀態。
• 動態擴容與收縮： 支持在運行時動態添加或移除節點，自動重新分配哈希槽，實現靈活的資源管理。

3. Cluster的工作原理

Cluster的工作原理主要可以從下面 3個點來進行分析：

(1) 數據分片與哈希槽

Redis Cluster 使用一致性哈希（Consistent Hashing）將數據鍵映射到 16384 個哈希槽中。每個主節點負責管理一部分哈希槽，通過調整槽的分配，可以實現數據的均衡分布。

(2) 節點通信

Cluster 中的節點通過 Gossip 協議進行通信，定期交換狀態信息，包括節點的健康狀況、槽的分配情況等。Cluster 節點之間能夠快速響應節點的增減和故障事件。

(3) 故障檢測與故障轉移

當一個主節點出現故障時，Cluster 的從節點會檢測到主節點的不可達狀態，并通過多數節點的共識決定是否執行故障轉移。選舉出一個從節點作為新的主節點，并重新配置槽的所有權，確保數據的持續可用。

4. Cluster 的優勢

• 高可擴展性： 通過數據分片，實現水平擴展，適應大規模數據和高并發請求。
• 無單點故障： 分布式架構設計，避免了單點故障的風險，提高了系統的可靠性。
• 自動化管理： 支持動態擴容與收縮，簡化了運維管理的復雜性。
• 高可用性與數據冗余： 結合主從復制機制，確保數據的高可用性和容錯能力。

5. Cluster 的限制

• 操作復雜性： 相比 Sentinel，Cluster 的配置和管理更為復雜，需要更高的維護成本。
• 不支持全局事務： Cluster 不支持跨槽操作的事務，某些復雜的業務場景可能受到限制。
• 客戶端支持要求高： 客戶端需要支持 Cluster 模式，能夠處理命令重定向和哈希槽的分布情況。
• 資源消耗較大： 由于分片和復制的存在，整體資源消耗較單節點部署更高。

三、兩者對比

在了解了 Redis Sentinel 和 Redis Cluster 的基本概念后，接下來我們將從多個維度對兩者進行詳細的比較。

1. 架構設計

Redis Sentinel：

• 主從復制架構： 單一主節點，多個從節點。
• Sentinel 監控： 部署多個 Sentinel 實例，分布在不同的機器上以避免單點故障。
• 客戶端連接： 客戶端直接連接到主節點和從節點，或者通過 Sentinel API 動態獲取主節點信息。

Redis Cluster：

• 分布式架構： 多個主節點組成集群，每個主節點負責管理一定范圍的哈希槽。
• 數據分片： 數據自動分布到不同的主節點，實現水平擴展。
• 主從復制： 每個主節點可以配置多個從節點，提供數據的冗余和故障轉移能力。
• 無中心化管理： 所有節點通過 Gossip 協議進行通信和狀態維護。

2. 數據分片與擴展性

Redis Sentinel：

• 無內建分片： Sentinel 主要關注高可用性，不提供數據分片功能。
• 擴展性限制： 通過增加從節點主要實現讀擴展，寫擴展受限于主節點的性能。

Redis Cluster：

• 內建分片： 使用哈希槽實現數據的自動分片，支持水平擴展。
• 易于擴展： 添加新節點后，Cluster 自動重新分配哈希槽，平衡數據分布。

3. 故障檢測與自動故障轉移

Redis Sentinel：

• 集中式故障檢測： 通過多個 Sentinel 實例共同監控集群狀態，依靠多數 Sentinel 的共識決定故障事件。
• 自動故障轉移： 在主節點故障時，自動提升從節點為新的主節點，并重新配置其余從節點。
• 簡單的拓撲： 主要針對主從拓撲，故障轉移過程相對簡單。

Redis Cluster：

• 分布式故障檢測： 每個節點通過 Gossip 協議監控集群狀態，分布式決策故障事件。
• 自動故障轉移： 同時支持主節點和從節點的故障檢測與轉移，具有更高的容錯能力。
• 復雜的拓撲： 支持多主從架構，故障轉移過程更為復雜，但提供更高的可用性。

4. 客戶端支持與路由機制

Redis Sentinel：

• 客戶端要求： 客戶端需要支持 Sentinel 協議，能夠動態獲取主節點信息，適應故障轉移后的變化。
• 簡單路由： 客戶端直接連接到主節點或從節點，不涉及數據分片。
• 適用范圍： 適合單實例或簡單主從復制的場景。

Redis Cluster：

• 客戶端要求： 客戶端必須支持 Cluster 協議，能夠處理命令重定向，了解哈希槽分布。
• 智能路由： 客戶端根據鍵的哈希槽決定連接到哪個主節點，支持跨主節點的操作。
• 復雜操作支持： 支持部分復雜命令，但跨槽操作存在限制。

3.5 配置與管理復雜度

Redis Sentinel：

• 配置簡單： 只需配置主從復制和 Sentinel 監控，無需考慮數據分片。
• 管理相對簡單： 增加從節點或進行故障轉移較為容易，適合中小規模部署。
• 監控工具支持： 有豐富的監控和管理工具支持 Sentinel 集群。

Redis Cluster：

• 配置復雜： 需要配置多個主節點和從節點，指定哈希槽范圍，涉及更多的部署細節。
• 管理復雜： 動態擴展、縮減需要重新分配哈希槽，涉及數據遷移和重新平衡。
• 工具支持： 提供 redis-trib（現已集成到 redis-cli）等工具，但仍需專業運維技能。

6. 數據一致性與持久性

Redis Sentinel：

• 強一致性： 主從復制一般采用異步方式，存在短暫的數據不一致風險。
• 持久化選項： 支持 RDB 和 AOF 持久化，但需手動配置和管理。
• 數據丟失風險： 在主節點故障后，可能會丟失部分未同步到從節點的數據。

Redis Cluster：

• 最終一致性： 數據分片后，各主節點保持獨立，主從復制同樣采用異步方式。
• 持久化選項： 支持 RDB 和 AOF，同樣需要合理配置以保證數據安全。
• 數據丟失風險： 取決于復制延遲和故障轉移策略，多從節點配置可以降低數據丟失風險。

7. 性能表現

Redis Sentinel：

• 讀性能提升： 通過增加從節點，可以分擔讀請求，提升整體讀性能。
• 寫性能受限： 寫請求集中在主節點，寫性能受限于單節點的處理能力。
• 延遲較低： 單實例或少量從節點時，延遲表現良好。

Redis Cluster：

• 讀寫性能提升： 通過數據分片，多個主節點可以并行處理讀寫請求，提升整體性能。
• 網絡開銷： 數據分片和節點間通信可能增加一定的網絡開銷。
• 延遲影響： 跨節點操作或重定向可能增加請求延遲，但在大規模部署中仍具有較高性能。

四、適用場景分析

1. Redis Sentinel 適用場景

• 中小規模部署： 適用于數據量和請求量較小，主從復制足以滿足需求的場景。
• 單數據中心： 在單一數據中心內實現高可用性，容錯能力足夠。
• 簡化架構需求： 不需要數據分片和水平擴展，架構相對簡單。
• 讀多寫少的應用： 通過增加從節點提升讀性能，適合讀密集型應用。

2. Redis Cluster 適用場景

• 大規模部署： 需要處理海量數據和高并發請求，通過數據分片實現水平擴展。
• 多數據中心分布： 支持跨數據中心部署，提高全球可用性和容災能力。
• 高可用與高性能并重： 需要在高可用性和性能之間取得平衡，適用于對可靠性和響應時間要求高的應用。
• 復雜業務場景： 需要支持復雜的數據模型和查詢操作，雖有一定限制，但仍適用多數場景。

五、優缺點總結

1. Redis Sentinel

優點：

• 部署簡單： 適合快速搭建高可用環境。
• 配置靈活： 可根據需求調整主從節點數量，滿足讀擴展需求。
• 維護成本低： 簡單的架構減少了維護的復雜性。
• 兼容性強： 支持大部分 Redis 命令和功能，不受分片限制。

缺點：

• 擴展性有限： 無法實現數據的水平分片，面對大規模數據時能力受限。
• 單點寫入： 寫請求集中在主節點，可能成為性能瓶頸。
• 數據一致性風險： 異步復制可能導致數據不一致，存在數據丟失的風險。

2. Redis Cluster

優點：

• 高擴展性： 支持數據的自動分片，適應大規模數據和高并發請求。
• 高可用性： 結合主從復制，實現更高的容錯能力和故障轉移。
• 去中心化管理： 無單點故障，提升系統整體可靠性。
• 性能優勢： 通過并行處理提高讀寫性能，滿足高性能需求。

缺點：

• 配置與管理復雜： 需要合理規劃哈希槽分配和節點配置，增加運維難度。
• 客戶端要求高： 客戶端需支持 Cluster 協議，處理命令重定向和哈希槽路由。
• 數據遷移成本： 動態擴展或縮減時，數據遷移可能涉及較高的資源消耗和延遲。
• 操作限制： 某些 Redis 命令和事務在 Cluster 模式下存在限制，需要調整業務邏輯。

六、總結

Redis Sentinel 和 Redis Cluster 都是 Redis官方提供的高可用性解決方案，但它們在架構設計、功能特性、適用場景等方面存在顯著差異。

Redis Sentinel 適用于中小規模、單數據中心、高可用性優先的場景，部署和管理相對簡單；而 Redis Cluster 則更適用于需要水平擴展、大規模、分布式高可用的應用，具備更高的靈活性和擴展性，但同時也帶來了更高的配置和管理復雜度。

在大廠中，兩種高可用方式都會提供，作為一名技術人員，我們不能完全黑盒使用，應該更多地了解它們的工作原理以及優缺點，這樣才能更好地幫助我們做好技術選型，出現問題時也能快速地去解決問題。