Redis的集羣方案都有哪些？

Redis集羣有以下三種方式，分別進行詳細說明。

1 Redis Cluster

官方3.0版本提供的集羣解決方案。分片採用slot概念，整個集羣共分成16384個slot，對於每個進入Redis的鍵值對根據key進行散列，分配到這16384個slot中某一個。散列演算法是CRC16後16384取模。

客戶端在訪問時可以連接到集羣中任意一個節點，如果這個節點沒有數據，則會轉到含有該數據的節點（類比Elasticsearch協調節點）。

若某個node發生故障，那它負責的slots也就失效，整個集羣將不能工作。所以官方推薦部署為主從模式，即每個主節點有一個從節點。

2 客戶端分片（推薦）

在官方3.0版本之前這是最通用的方法。首先Redis伺服器分別獨立部署，然後客戶端採用一致性Hash演算法將數據KEY和Redis伺服器地址進行散列，特定KEY會映射到特定Redis節點上。同理為了保證高可用性也可以採用主從模式。

Java Redis客戶端驅動Jedis提供了Redis Sharding功能，注意配置文件需要配置Redis伺服器地址。

3 代理方式

上述客戶端方式有一個問題：連接不能共享導致資源浪費。所謂代理方式就是在客戶端和Redis服務端之間，設置了一個代理，所有請求先經過代理，通過代理轉發至Redis服務端。業界比較流行的代理中間件有twemproxy和Codis，其中Codis由豌豆莢團隊開源。

敬請關注

請點擊關注按鈕【IT徐胖子】會持續為大家奉獻互聯網和技術乾貨內容，感謝支持

Redis在3.0之前，是隻支持單實例模式的，雖然現在伺服器的內存也可以達到幾百G的規模，但是考慮到成本問題，大多數公司都會採用集羣方案，把數據分片存到多個Redis實例中。

客戶端分片

這個方案比較簡單，也就是在客戶端中，通過定義好的路由規則，把不同的key存儲（路由）到不同的Redis實例中；比如hash(key)%N，根據結果把key路由到Redis1-RedisN中。

優點：不依賴第三方中間件，完全自己實現，能夠自我掌控。
缺點：增加或者減少Redis實例的時候，需要調整程序，而且在調整之後的一段時間，大部分緩存會失效（路由結果改變了）；

Redis中間件

客戶端把請求發送到Redis中間件，中間件根據路由規則發送請求到正確的Redis實例，然後中間件再把結果返回給客戶端。常用的幾個：

Twemproxy：由Twitter開源；客戶端可以像連接Redis實例一樣連接Twemproxy，不需要修改代碼邏輯；Twemproxy可以自動地Redis保持連接（可以看成資料庫連接池），而且可以自動刪除無效Redis實例；缺點也是有的，客戶端和Redis中增加了一層，性能方面多少會有一些損耗，更大的問題，是Twemproxy無法平滑地增加Redis實例。
Codis：豌豆莢開源；它最大的優勢在於可以平滑增加或減少Redis實例，可以透明地遷移數據。

Redis3.0集羣

Redis3.0集羣採用無中心節點方式實現，無需proxy代理，Redis把所有的Key分成了16384個slot，每個Redis實例負責其中一部分slot；客戶端直接與redis集羣的每個節點連接，根據同樣的hash演算法計算出key對應的slot，然後直接在slot對應的redis上執行命令（集羣中的所有信息通過節點之間定期的數據交換而更新）。

Redis客戶端在任意一個Redis實例發出請求，如果所需數據不在該實例中，通過重定向命令引導客戶端訪問所需的實例。