這篇文章，分享自己職業生涯經歷的五種 Redis 部署模式，希望對大家有所啟發。

1.單實例

這是 Redis 最簡單、最基礎的部署方式，即：整個 Redis 服務運行在單個服務器和單個進程中。

筆者第一次在生產環境使用 Redis ，是在藝龍紅包系統中，使用 Redis 實現分布式鎖。

圖片

因為上線時間要求比較著急，運維說有一個實例可以不用申請，可以直接用，于是就采用了單實例的模式。筆者還特意和運維說假如 Redis 掛了，就通過  Linux 定時任務重新啟動 。

單實例模式的優點顯而易見：簡單（部署、配置、維護），但缺點同樣突出：服務器宕機，服務將完全不可用，同時內存大小受限于服務器。

2.主從 + 哨兵

在藝龍紅包系統初版上線后，團隊架構師向我介紹了Redis的高可用方案——主從復制+哨兵集群模式。這種部署模式通過主從數據同步實現數據備份，配合哨兵集群的自動故障檢測與主從切換能力，能夠有效保障服務的高可用性。

如圖所示的架構中：

圖片

• 主節點負責處理所有寫請求
• 從節點實時同步主節點數據，可分擔讀請求
• 哨兵集群持續監控節點健康狀態
• 當主節點故障時，哨兵會自動選舉新的主節點

通過這種改造，紅包系統的緩存架構獲得了質的提升：不僅避免了單點故障風險，還實現了讀寫分離，整體系統的穩定性和可用性都得到了顯著增強。即便在突發故障情況下，也能保證紅包業務持續穩定運行。

3.分片集群 + 一致性 Hash

「主從 + 哨兵」模式非常健壯，但假如緩存數據量非常大，這種模式就有瓶頸了，于是需要多組 Redis 實例才能滿足業務需求。

藝龍的流式計算服務的計算過程大量依賴存這種多 Redis 實例模式 ，如下圖：

圖片

我們可以采用一致性哈希算法實現數據分片：

圖片

• 哈希環構建：將整個哈?？臻g（0~2^32-1）組織成環形結構 。
• 節點映射：對每個Redis節點計算多個虛擬節點（通常200-300個）的哈希值，均勻分布在環上 。
• 數據路由：對每個key計算哈希值，在環上順時針找到最近的節點 。

流式計算的 Redis 集群都僅僅采用單主集群模式，存在一定的高可用風險，比如某個分片掛掉了，整個系統就會出現問題。

解決方案其實也很簡單：

• 每個分片都是主從模式
• 哨兵集群監控(自動切換主從)

架構圖就變成下圖的緩存部署架構（神州專車訂單緩存部署架構）：

圖片

4.分片集群 + 預分配

當我們再來看「分片集群 + 一致性 Hash」 這種模式時，雖然看起來很完美，但是有一個隱形的缺點：

當新增分片時，如何做到數據可以平滑遷移到新的分片節點 ？

解決這種問題最有效的方案是：預分配槽位 。

筆者曾經介紹過專車的分庫分表算法，假設現在需要將訂單表平均拆分到 4 個分庫 shard0 ，shard1 ，shard2 ，shard3 。

首先將 [0-1023] 平均分為4個區段：[0-255]，[256-511]，[512-767]，[768-1023]，然后對字符串（或子串，由用戶自定義）做 hash， hash 結果對 1024 取模，最終得出的結果 slot 落入哪個區段，便路由到哪個分庫。

圖片

我們可以將分庫分表的預分配理論應用到 Redis 分片集群中，見下圖：

圖片

大名鼎鼎的開源項目 Codis 也是使用預分配的技巧，「分片集群 + 預分配」既可以保留分片集群的可擴展的優勢，也可以通過預分配槽位的技巧實現較為平滑的數據遷移，但數據遷移還是非?？简灱軜嫀煹墓Φ?。

有沒有一種方案可以支持所有的特性呢 ？

有的，它來了，它就是：官方 Redis Cluster 。

5.官方 Redis Cluster

筆者在花生好車和科大訊飛都使用過 Redis Cluster 這種模式。

1

Redis Cluster 集群具有如下幾個特點：

• 集群完全去中心化，采用多主多從；
• 每一個分區都是由一個Redis主機和多個從機組成，分片和分片之間是相互平行的。
• Redis Cluster 無需部署哨兵集群，集群內 Redis 節點通過 Gossip 協議互相探測健康狀態，在故障時可發起自動切換。
• Redis Cluster將數據分為16384個槽位，每個節點負責管理一部分槽位。
• 當客戶端向 Redis Cluster 發送請求時，Cluster 會根據鍵的哈希值將請求路由到相應的節點。具體來說，Redis Cluste r使用 CRC16 算法計算鍵的哈希值，然后對16384 取模，得到槽位編號。
• Redis Cluster 提供了「配套」的 SDK，只要客戶端升級 SDK，就可以和 Redis Cluster 集成，SDK 會幫你找到 key 對應的 Redis 節點進行讀寫，還能自動適配 Redis 節點的增加和刪除，業務側無感知。

Redis Cluster 從功能來講，已經趨近于完美，在提供高可用性的同時，實現了數據分片和負載均衡，適用于大規模數據存儲和高性能要求的場景。但是配置和運維相對復雜，以及一些復雜的多鍵操作可能受到限制。

6.真的有銀彈嗎

在 Redis 的部署模式演進過程中，從單實例到 Redis Cluster，我們看到了不同架構的優缺點。

但沒有一種方案是完美的銀彈，每種模式都有其適用場景和局限性。

圖片

所以，我們需要理解業務需求，權衡性能、擴展性和運維成本，才能做出最佳的選擇。