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

一、Redis Sentinel模式

1. 什么是Redis Sentinel?

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

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

Redis Sentinel核心結構如下圖：

2. Sentinel的工作原理

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

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

3. Sentinel的優(yōu)勢

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

4. Sentinel的限制

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

二、Redis Cluster模式

1. 什么是Redis Cluster?

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

Redis Cluster核心結構如下圖：

2. Cluster的核心特性

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

3. Cluster的工作原理

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

(1) 數(shù)據(jù)分片與哈希槽

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

(2) 節(jié)點通信

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

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

當一個主節(jié)點出現(xiàn)故障時，Cluster 的從節(jié)點會檢測到主節(jié)點的不可達狀態(tài)，并通過多數(shù)節(jié)點的共識決定是否執(zhí)行故障轉移。選舉出一個從節(jié)點作為新的主節(jié)點，并重新配置槽的所有權，確保數(shù)據(jù)的持續(xù)可用。

4. Cluster 的優(yōu)勢

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

5. Cluster 的限制

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

三、兩者對比

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

1. 架構設計

Redis Sentinel：

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

Redis Cluster：

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

2. 數(shù)據(jù)分片與擴展性

Redis Sentinel：

• 無內(nèi)建分片： Sentinel 主要關注高可用性，不提供數(shù)據(jù)分片功能。
• 擴展性限制： 通過增加從節(jié)點主要實現(xiàn)讀擴展，寫擴展受限于主節(jié)點的性能。

Redis Cluster：

• 內(nèi)建分片： 使用哈希槽實現(xiàn)數(shù)據(jù)的自動分片，支持水平擴展。
• 易于擴展： 添加新節(jié)點后，Cluster 自動重新分配哈希槽，平衡數(shù)據(jù)分布。

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

Redis Sentinel：

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

Redis Cluster：

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

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

Redis Sentinel：

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

Redis Cluster：

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

3.5 配置與管理復雜度

Redis Sentinel：

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

Redis Cluster：

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

6. 數(shù)據(jù)一致性與持久性

Redis Sentinel：

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

Redis Cluster：

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

7. 性能表現(xiàn)

Redis Sentinel：

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

Redis Cluster：

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

四、適用場景分析

1. Redis Sentinel 適用場景

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

2. Redis Cluster 適用場景

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

五、優(yōu)缺點總結

1. Redis Sentinel

優(yōu)點：

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

缺點：

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

2. Redis Cluster

優(yōu)點：

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

缺點：

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

六、總結

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

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

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