公司redis叢集有了蠻大的規模，權且來分享下redis叢集！

首先，不可否認的是，redis的單機效能相當高，但是就算把記憶體大量擴大(垂直擴充套件)，也不可能滿足大業務需要的效能和可維護性！所以，叢集是很好的一個選擇，透過叢集可以實現水平擴充套件，提升整體的效能！

叢集方案1:使用客戶端分片的方式，增加多臺redis伺服器之後，在業務端使用某種路由規則(hash演算法等)，將不同key對應的資料放在不同的redis伺服器中，實現內容分發！

但是這樣的方式有很多缺點，比如業務程式碼和redis資料路由程式碼嚴重耦合，可擴充套件性也十分底下，需要增加redis例項的同時，修改原先的分發規則，而一旦出現問題，排查難度大(因為運維和程式碼端都要查)！

叢集方案2:使用開源產品twemproxy作為redis代理！中介軟體twemcache負責接收業務端的請求，然後從不同的redis例項中收集資料傳送給業務方，起到一箇中間代理的作用！業務端像連線一個redis例項一樣連線twemproxy，實現了業務程式碼和redis之間的解耦合！同時，對於失效的redis會被自動踢出，防止資料的丟失，不過twemproxy作為一箇中間件，肯定會對需要實時性強的系統造成效能損失，動態無痕跡的增加redis例項也是很困難的！！

叢集方案3:使用codis叢集，類似於twemproxy，客戶端也不需要去連線redis例項，而使用codis作為中介軟體，讓codis底層自己去獲取資料，增加的codis dashboard可以對codis proxy和codis server進行統一管理，對例項節點的改變可以有效應對！

叢集方案4:redis自主叢集，使用純redis實現叢集，完全的去中心化！redis叢集把所有的key放在16384個slot中，各個redis可以透過重定向引導客戶端訪問資料所在的叢集點，比如client訪問redis2，redis2發現數據的key在redis1中，就引導客戶端重定向去redis1中取資料，這樣不需要別的中介軟體就能很好的實現資料獲取，而且這樣的純redis方式，部署起來也是十分方便的！

叢集方案5:直接買阿里，騰訊的叢集吧，想要啥樣的給你啥樣的。。

我們公司現在使用的是基於codis的redis叢集，管理相對來說比較簡單，算是比較不錯的集監控，代理於一身的元件！

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

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

優點：不依賴第三方中介軟體，完全自己實現，能夠自我掌控。

缺點：增加或者減少Redis例項的時候，需要調整程式，而且在調整之後的一段時間，大部分快取會失效（路由結果改變了）；

客戶端把請求傳送到Redis中介軟體，中介軟體根據路由規則傳送請求到正確的Redis例項，然後中介軟體再把結果返回給客戶端。常用的幾個：

Twemproxy：由Twitter開源；客戶端可以像連線Redis例項一樣連線Twemproxy，不需要修改程式碼邏輯；Twemproxy可以自動地Redis保持連線（可以看成資料庫連線池），而且可以自動刪除無效Redis例項；缺點也是有的，客戶端和Redis中增加了一層，效能方面多少會有一些損耗，更大的問題，是Twemproxy無法平滑地增加Redis例項。

Codis：豌豆莢開源；它最大的優勢在於可以平滑增加或減少Redis例項，可以透明地遷移資料。

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

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