黃晴清
公司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集群具體的使用過程中，如果有問題，可以私信我進行交流！更多的技術分享，敬請關注。。。
此生唯一
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實例發出請求，如果所需數據不在該實例中，通過重定向命令引導客戶端訪問所需的實例。
我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。
會點代碼的大叔
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徐胖子】會持續為大家奉獻互聯網和技術乾貨內容，感謝支持
