Redis集群方案應該怎麼做？

12-27

目前Redis server端還沒有出集群方案。客戶端的集群方案，有沒有一種方案，可以做sharding，同時也可以做主備，主機掛了，slave能自動頂上。有沒有這樣的方案呢？現在在使用redis集群的公司，一般是怎麼做的呢？謝謝

為什麼集群？

通常，為了提高網站響應速度，總是把熱點數據保存在內存中而不是直接從後端資料庫中讀取。Redis是一個很好的Cache工具。大型網站應用，熱點數據量往往巨大，幾十G上百G是很正常的事兒，在這種情況下，如何正確架構Redis呢？

首先，無論我們是使用自己的物理主機，還是使用雲服務主機，內存資源往往是有限制的，scale up不是一個好辦法，我們需要scale out橫向可伸縮擴展，這需要由多台主機協同提供服務，即分散式多個Redis實例協同運行。

其次，目前硬體資源成本降低，多核CPU，幾十G內存的主機很普遍，對於主進程是單線程工作的Redis，只運行一個實例就顯得有些浪費。同時，管理一個巨大內存不如管理相對較小的內存高效。因此，實際使用中，通常一台機器上同時跑多個Redis實例。

方案

1.Redis官方集群方案 Redis Cluster

Redis Cluster是一種伺服器Sharding技術，3.0版本開始正式提供。

Redis Cluster中，Sharding採用slot(槽)的概念，一共分成16384個槽，這有點兒類pre sharding思路。對於每個進入Redis的鍵值對，根據key進行散列，分配到這16384個slot中的某一個中。使用的hash演算法也比較簡單，就是CRC16後16384取模。

Redis集群中的每個node(節點)負責分攤這16384個slot中的一部分，也就是說，每個slot都對應一個node負責處理。當動態添加或減少node節點時，需要將16384個槽做個再分配，槽中的鍵值也要遷移。當然，這一過程，在目前實現中，還處於半自動狀態，需要人工介入。

Redis集群，要保證16384個槽對應的node都正常工作，如果某個node發生故障，那它負責的slots也就失效，整個集群將不能工作。

為了增加集群的可訪問性，官方推薦的方案是將node配置成主從結構，即一個master主節點，掛n個slave從節點。這時，如果主節點失效，Redis Cluster會根據選舉演算法從slave節點中選擇一個上升為主節點，整個集群繼續對外提供服務。這非常類似前篇文章提到的Redis Sharding場景下伺服器節點通過Sentinel監控架構成主從結構，只是Redis Cluster本身提供了故障轉移容錯的能力。

Redis Cluster的新節點識別能力、故障判斷及故障轉移能力是通過集群中的每個node都在和其它nodes進行通信，這被稱為集群匯流排(cluster bus)。它們使用特殊的埠號，即對外服務埠號加10000。例如如果某個node的埠號是6379，那麼它與其它nodes通信的埠號是16379。nodes之間的通信採用特殊的二進位協議。

對客戶端來說，整個cluster被看做是一個整體，客戶端可以連接任意一個node進行操作，就像操作單一Redis實例一樣，當客戶端操作的key沒有分配到該node上時，Redis會返迴轉向指令，指向正確的node，這有點兒像瀏覽器頁面的302 redirect跳轉。

Redis Cluster是Redis 3.0以後才正式推出，時間較晚，目前能證明在大規模生產環境下成功的案例還不是很多，需要時間檢驗。

2.Redis Sharding集群

Redis 3正式推出了官方集群技術，解決了多Redis實例協同服務問題。Redis Cluster可以說是服務端Sharding分片技術的體現，即將鍵值按照一定演算法合理分配到各個實例分片上，同時各個實例節點協調溝通，共同對外承擔一致服務。

多Redis實例服務，比單Redis實例要複雜的多，這涉及到定位、協同、容錯、擴容等技術難題。這裡，我們介紹一種輕量級的客戶端Redis Sharding技術。

Redis Sharding可以說是Redis Cluster出來之前，業界普遍使用的多Redis實例集群方法。其主要思想是採用哈希演算法將Redis數據的key進行散列，通過hash函數，特定的key會映射到特定的Redis節點上。這樣，客戶端就知道該向哪個Redis節點操作數據。Sharding架構如圖：

慶幸的是，java redis客戶端驅動jedis，已支持Redis Sharding功能，即ShardedJedis以及結合緩存池的ShardedJedisPool。

Jedis的Redis Sharding實現具有如下特點：

採用一致性哈希演算法(consistent hashing)，將key和節點name同時hashing，然後進行映射匹配，採用的演算法是MURMUR_HASH。採用一致性哈希而不是採用簡單類似哈希求模映射的主要原因是當增加或減少節點時，不會產生由於重新匹配造成的rehashing。一致性哈希隻影響相鄰節點key分配，影響量小。

2.為了避免一致性哈希隻影響相鄰節點造成節點分配壓力，ShardedJedis會對每個Redis節點根據名字(沒有，Jedis會賦予預設名字)會虛擬化出160個虛擬節點進行散列。根據權重weight，也可虛擬化出160倍數的虛擬節點。用虛擬節點做映射匹配，可以在增加或減少Redis節點時，key在各Redis節點移動再分配更均勻，而不是只有相鄰節點受影響。

3.ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，這樣通過合理命名key，可以將一組相關聯的key放入同一個Redis節點，這在避免跨節點訪問相關數據時很重要。

Redis Sharding採用客戶端Sharding方式，服務端Redis還是一個個相對獨立的Redis實例節點，沒有做任何變動。同時，我們也不需要增加額外的中間處理組件，這是一種非常輕量、靈活的Redis多實例集群方法。

當然，Redis Sharding這種輕量靈活方式必然在集群其它能力方面做出妥協。比如擴容，當想要增加Redis節點時，儘管採用一致性哈希，畢竟還是會有key匹配不到而丟失，這時需要鍵值遷移。

作為輕量級客戶端sharding，處理Redis鍵值遷移是不現實的，這就要求應用層面允許Redis中數據丟失或從後端資料庫重新載入數據。但有些時候，擊穿緩存層，直接訪問資料庫層，會對系統訪問造成很大壓力。有沒有其它手段改善這種情況？

Redis作者給出了一個比較討巧的辦法--presharding，即預先根據系統規模盡量部署好多個Redis實例，這些實例佔用系統資源很小，一台物理機可部署多個，讓他們都參與sharding，當需要擴容時，選中一個實例作為主節點，新加入的Redis節點作為從節點進行數據複製。數據同步後，修改sharding配置，讓指向原實例的Shard指向新機器上擴容後的Redis節點，同時調整新Redis節點為主節點，原實例可不再使用。

presharding是預先分配好足夠的分片，擴容時只是將屬於某一分片的原Redis實例替換成新的容量更大的Redis實例。參與sharding的分片沒有改變，所以也就不存在key值從一個區轉移到另一個分片區的現象，只是將屬於同分片區的鍵值從原Redis實例同步到新Redis實例。

並不是只有增刪Redis節點引起鍵值丟失問題，更大的障礙來自Redis節點突然宕機。在《Redis持久化》一文中已提到，為不影響Redis性能，盡量不開啟AOF和RDB文件保存功能，可架構Redis主備模式，主Redis宕機，數據不會丟失，備Redis留有備份。

這樣，我們的架構模式變成一個Redis節點切片包含一個主Redis和一個備Redis。在主Redis宕機時，備Redis接管過來，上升為主Redis，繼續提供服務。主備共同組成一個Redis節點，通過自動故障轉移，保證了節點的高可用性。則Sharding架構演變成：

Redis Sentinel提供了主備模式下Redis監控、故障轉移功能達到系統的高可用性。

高訪問量下，即使採用Sharding分片，一個單獨節點還是承擔了很大的訪問壓力，這時我們還需要進一步分解。通常情況下，應用訪問Redis讀操作量和寫操作量差異很大，讀常常是寫的數倍，這時我們可以將讀寫分離，而且讀提供更多的實例數。

可以利用主從模式實現讀寫分離，主負責寫，從負責只讀，同時一主掛多個從。在Sentinel監控下，還可以保障節點故障的自動監測。

3.利用代理中間件實現大規模Redis集群

上面分別介紹了多Redis伺服器集群的兩種方式，它們是基於客戶端sharding的Redis Sharding和基於服務端sharding的Redis Cluster。

客戶端sharding技術其優勢在於服務端的Redis實例彼此獨立，相互無關聯，每個Redis實例像單伺服器一樣運行，非常容易線性擴展，系統的靈活性很強。其不足之處在於：

由於sharding處理放到客戶端，規模進步擴大時給運維帶來挑戰。
服務端Redis實例群拓撲結構有變化時，每個客戶端都需要更新調整。
連接不能共享，當應用規模增大時，資源浪費制約優化。

服務端sharding的Redis Cluster其優勢在於服務端Redis集群拓撲結構變化時，客戶端不需要感知，客戶端像使用單Redis伺服器一樣使用Redis集群，運維管理也比較方便。

不過Redis Cluster正式版推出時間不長，系統穩定性、性能等都需要時間檢驗，尤其在大規模使用場合。

能不能結合二者優勢？即能使服務端各實例彼此獨立，支持線性可伸縮，同時sharding又能集中處理，方便統一管理？本篇介紹的Redis代理中間件twemproxy就是這樣一種利用中間件做sharding的技術。

twemproxy處於客戶端和伺服器的中間，將客戶端發來的請求，進行一定的處理後(如sharding)，再轉發給後端真正的Redis伺服器。也就是說，客戶端不直接訪問Redis伺服器，而是通過twemproxy代理中間件間接訪問。

參照Redis Sharding架構，增加代理中間件的Redis集群架構如下：

twemproxy中間件的內部處理是無狀態的，它本身可以很輕鬆地集群，這樣可避免單點壓力或故障。

twemproxy又叫nutcracker，起源於twitter系統中redis/memcached集群開發實踐，運行效果良好，後代碼奉獻給開源社區。其輕量高效，採用C語言開發，工程網址是：GitHub - twitter/twemproxy: A fast, light-weight proxy for memcached and redis

twemproxy後端不僅支持redis，同時也支持memcached，這是twitter系統具體環境造成的。

由於使用了中間件，twemproxy可以通過共享與後端系統的連接，降低客戶端直接連接後端伺服器的連接數量。同時，它也提供sharding功能，支持後端伺服器集群水平擴展。統一運維管理也帶來了方便。

當然，也是由於使用了中間件代理，相比客戶端直連伺服器方式，性能上會有所損耗，實測結果大約降低了20%左右。

twitter 開源的 twemproxy是個不錯的選擇《Twemproxy – Twitter 開源的 Redis proxy》

大致四個方向：
1. twemproxy，大概概念是，它類似於一個代理方式，使用方法和普通redis無任何區別，設置好它下屬的多個redis實例後，使用時在本需要連接redis的地方改為連接twemproxy，它會以一個代理的身份接收請求並使用一致性hash演算法，將請求轉接到具體redis，將結果再返回twemproxy。
使用方式簡便(相對redis只需修改連接埠)，對舊項目擴展的首選，
問題：twemproxy自身單埠實例的壓力，
使用一致性hash後，對redis節點數量改變時候的計算值的改變，數據無法自動移動到新的節點。

2.codis，沒用過基本和twemproxy一致的效果，但它支持在節點數量改變情況下，舊節點數據可恢復到新hash節點。

3. redis cluster 3.0自帶的集群，特點在於他的分散式演算法不是一致性hash，而是hash槽的概念，以及自身支持節點設置從節點。具體看官方文檔介紹。

4.在業務代碼層實現，起幾個毫無關聯的redis實例，在代碼層，對key 進行hash計算，然後去對應的redis實例操作數據。這種方式對hash層代碼要求比較高，考慮部分包括，節點失效後的替代演算法方案，數據震蕩後的自動腳本恢復，實例的監控，等等。

查看全文： redis4.0、codis、阿里雲redis 3種redis集群對比分析

本文對redis4.0版本的cluster，codis，以及阿里雲redis 3種集群進行了對比分析。

1、架構對比

1.1、redis 4.0 cluster

redis 4.0版本的集群是去中心化的結構，集群元數據信息分布在每個節點上，主備切換依賴於多個節點協商選主。
redis 提供了redis-trib 工具做部署集群及運維等操作。
客戶端訪問散列的db節點需依賴smart client，也就是客戶端需要對redis返回的節點信息做判斷選擇路由等操作。例如客戶端請求一個節點，如果所請求的key不在該節點上，客戶端需要判斷返回的move或ask等指令，重定向請求到對應的節點。

1.2、codis

codis由3大組件構成：

codis-server : 修改過源碼的redis, 支持slot，擴容遷移等
codis-proxy : 支持多線程，go語言實現的內核
codis Dashboard : 集群管理工具

提供web圖形界面管理集群。
集群元數據存在在zookeeper或etcd。
提供獨立的組件codis-ha負責redis節點主備切換。
基於proxy的codis，客戶端對路由表變化無感知。客戶端需要從codis dashhoard調用list proxy命令獲取所有proxy列表，並根據自身的輪詢策略決定訪問哪個proxy節點以實現負載均衡。

1.3、阿里雲redis

阿里雲的redis集群版由3大組件構成：

redis-config : 集群管理工具
redis-server : 優化過源碼的redis，支持slot, 擴容遷移等
redis-proxy : 單線程，c++14語言實現的內核

redis-proxy 無狀態，一個集群根據集群規格可掛多個proxy節點。
redis-config 雙節點，支持容災。
集群元數據存儲在rds db上。
提供獨立的組件HA負責集群的主備切換等。
阿里雲的redis集群同樣基於proxy，用戶對路由信息無感知，同時提供vip給客戶端訪問，客戶端只需一個連接地址即可，無須關心proxy訪問的負載均衡等。

2、性能對比

2.1、壓測環境

在3台物理機上分別搭建了以上3種redis集群。每台物理機千兆網卡，24核cpu，內存189G。3台物理機分別跑壓測工具memtier_benchmark、codis proxy/阿里雲proxy、redis server。redis server使用各種集群配套的redis內核。
固定key size 32個位元組，set/get 操作比例為1:10。每個線程16個客戶端。連續壓測5分鐘，分8個， 16個， 32個， 48個， 64個線程壓測。
因為redis4.0集群需要額外的客戶端選擇節點，而memtier_benchmark不支持，所以使用了hashtag 來壓測redis4.0。
每個集群有8個master db， 8個slave db， aof打開。aof rewrite的最小buffer為64MB。
壓測的對象分別為單個redis 4.0 節點，單個阿里雲redis-proxy，單核的codis-proxy， 8核的codis-proxy。
codis 使用的go版本為1.7.4。

壓測結果圖如下：

可看出，單核的codis-proxy性能最弱。8核的codis-proxy壓測沒有對key使用hashtag，如此相當於將請求分散到後端8個db節點上，也可以說相當於8個阿里雲的redis-proxy。自然性能數據就比較高了。
單核的阿里雲redis-proxy在壓力夠大的情況下性能逼近原生的redis db節點。
在實際生產環境中，使用原生的redis cluster，客戶端需要實現cluster protocol，解析move, ask等指令並重定向節點，隨意訪問key可能需要兩次訪問操作才能完成，性能上並不能完全如單節點一樣。

3、支持特性對比

3.1、主要不同協議的支持對比

redis 4.0阿里雲rediscodis事務支持相同slot支持相同的slot不支持sub/pub支持相同slot支持不支持flushall支持支持不支持select不支持不支持不支持mset/mget支持相同slot支持支持

更多命令請參考各自的集群版本說明。

3.2、水平擴展對比

redis4.0 cluster，codis，阿里雲redis 分散式集群均實現了面對slot的管理，擴展的最小單元是slot。
分散式集群中水平擴展的本質是對集群節點的路由信息管理以及數據的遷移。這3種集群遷移數據的最小單位均是key。

3.2.1 redis cluster 水平擴展原理

redis4.0 cluster支持指定slot在節點中移動，也支持加入空節點後根據集群節點中已存在的slot分布自動進行再分布。以redis-trib的move_slot為例解析slot移動的過程：

步驟1): 調用setslot命令修改源、目標節點slot的狀態
步驟2): 獲取源節點上slot的key列表
步驟3): 調migrate命令遷移key，遷移過程中redis屬於阻塞狀態，只有目標節點restore成功後才返回
步驟4): 調用setslot命令修改源、目標節點slot的狀態

在遷移過程中，如何保證數據的一致性呢？
redis cluster提供遷移狀態中的重定向機制，向客戶端返回ASK，客戶端收到後需先發送asking指令到目標節點上，然後再發請求到目標節點上才可以訪問。當訪問的key滿足以下全部條件時會出現重定向返回：

key所屬slot在該節點上，如不在，返回的是MOVE
slot處於遷移狀態中
key不存在

如上所述，migrate 是一個同步阻塞型的操作，如果key並不為空，即使slot處於遷移狀態，key依然能被讀寫，以此保證數據的一致性。

3.2.2 codis 水平擴展原理

codis對slot的再分布策略與redis cluster相同。codis-server內核並沒有存儲slot的信息，也不解析key所在的slot，只有在dbadd等操作時將對應的key記錄到以slot為key的dict中，如果key帶有tag，則將tag做crc32運算後將key插入到以crc32值為key的skiplist中。
codis Dashboard 後台起遷移狀態機程序，先確保通知到所有proxy開始遷移，即prepare階段，如有一台以上proxy失敗，則遷移任務失敗。遷移步驟與redis cluster類似，不同點是：

slot狀態信息存儲在zookeeper/etcd
發送slotsmgrttagslot而非migrate指令，slotsmgrttagslot執行時會隨機獲取一個key遷移，如key帶有tag，則從上文中的skiplist獲取所有key批量遷移

codis同樣也是同步阻塞型的遷移操作。
在保持數據一致性方面，因為codis-server內核不維護slot的狀態，所以一致性的保證落在了proxy組件上。codis-proxy在處理請求時，先判斷key所在slot的狀態，如slot處於遷移中，則向codis-server發起指定key遷移的命令，等key遷移完成後，codis-proxy轉向目標的codis-server請求。做法簡單，對redis內核修改較少，但同時也導致遷移慢，客戶端卡住的時間較久。

3.2.3 阿里雲redis 水平擴展原理

阿里雲redis除了提供指定源、節點、slot外，還提供按節點的容量、slot的大小等考量參數動態分配slot，以最小粒度影響集群可用性作為分配原則。遷移大體步驟如下：

步驟1): 由redis-config計算源、目標節點、slot
步驟2): redis-config向redis-server發送遷移slot指令
步驟3): redis-server啟動狀態機，分批量遷移key
步驟4): redis-config定時檢查redis-server並更新slot狀態

與codis不同，阿里雲redis在內核上同樣維護了slot的信息，並且拋棄了codis遷移整個slot和redis cluster遷移單個key的做法，從內核上支持批量遷移，加快遷移速度。
阿里雲redis遷移數據是非同步的流程，不等待目標節點是否restore成功，由目標節點通知和源節點定時檢查來驗證是否成功。以此縮小同步阻塞對其他slot訪問的影響。
同時也是因為遷移非同步化，所以在保證數據一致性時，判斷請求如果是寫請求並且key存在且不在遷移的key列表中，走正常的寫請求流程。其他數據一致性保證與redis4.0 cluster相同。
阿里雲redis-server優化了遷移大key的流程，詳情可見https://yq.aliyun.com/articles/64884?spm=5176.8091938.0.0.fF3UZH

3.3、其他

redis 4.0阿里雲rediscodis內核熱升級不支持支持不支持proxy熱升級無proxy支持不支持slots槽數16384163841024密碼不支持，需改redis-trib腳本支持支持，所有組件密碼必須一致

阿里雲的redis內核和proxy的熱升級過程中均不斷連接，對客戶端無影響。

4、結束語

雲資料庫Redis版（ApsaraDB for Redis）是一種穩定可靠、性能卓越、可彈性伸縮的資料庫服務。基於飛天分散式系統和全SSD盤高性能存儲，支持主備版和集群版兩套高可用架構。提供了全套的容災切換、故障遷移、在線擴容、性能優化的資料庫解決方案。歡迎各位購買使用:雲資料庫 Redis 版

阿里雲有分散式緩存服務Tair也有NOSQL資料庫服務OTShttp://www.aliyun.com/product/ots/?spm=5176.383338.201.20.LI5Szc，SSD盤，讀性能10ms以內，如果合適，會節省一些開發時間精力。

可以用我們開源的分散式redis解決方案，見wandoulabs/codis · GitHub

高可用的話其他題主已經說了可以用sentinel去做比如通過sentinel做節點切換並且通知一些協調服務(例如zookeeper) 告訴所有使用者切換節點之類的很容易
至於 sharding 分兩類一類是proxy 有一些成熟實現比如codis、twemproxy 另一類就是在客戶端做

codis的作者本尊出現在上面了建議題主把codis/FAQ_zh.md at master · wandoulabs/codis · GitHub 看完然後管作者要一份演講的PPT 就能知道為啥不用其他的代理以及smart client了
codis唯一的瑕疵是需要更改redis的源代碼(為了加入slot信息) 以及代理實現本身會有的問題所以如果集群規模不大的話沒必要用proxy 做客戶端sharding即可

使用Redis-Sentinel主從切換，twemproxy做proxy和key sharding，redis-twemproxy-agent 在主從切換後自動更新twemproxy配置並重啟twemproxy，redis-monitor監控。

支持 Partition 的 Redis 集群方案大致有幾類：

1，客戶端實現分片
分區的邏輯在客戶端實現，由客戶端自己選擇請求到哪個節點。方案可參考一致性哈希，基於 Memcached 的 cache 集群一般是這麼做，而這種方案通常適用於用戶對客戶端的行為有完全控制能力的場景。

2，中間件實現分片
有名的例子是 Twitter 的 Twemproxy，Redis 作者對其評價較高。一篇較舊的博客如下：Twemproxy, a Redis proxy from Twitter
另一個知名度較高的實現是 Codis，由豌豆莢的團隊開發，作者 @go routine 劉老師已經在前面的答案中推薦過了。

3，客戶端服務端協作
官方的 Redis Cluster 實現就是採用這種方式，在這種方案下，客戶端請求到達錯誤節點後不會被錯誤節點代理執行，而是被錯誤節點重定向至正確的節點。

那麼，上面幾種方案如何選擇？

顯然在客戶端做分片是自定義能力最高的，優勢在於，在不需要客戶端服務端協作，以及沒有中間層的條件下，每個請求的 roundtrip 時間是相對更小的，搭配良好的客戶端分片策略，可以讓整個集群獲得很好的擴展性。當然劣勢也很明顯，用戶需要自己對付 Redis 節點宕機的情況，需要採用更複雜的策略來做 replica，以及需要保證每個客戶端看到的集群「視圖」是一致的。

中間件的方案對客戶端實現的要求是最低的，客戶端只要支持基本的 Redis 通信協議即可，至於擴容、多副本、主從切換等機制客戶端都不必操心，因此這種方案也很適合用來做「緩存服務」。

官方推出的協作方案也完整地支持了分片和多副本，相對於各種 proxy，這種方案假設了客戶端實現是可以與服務端「協作」的，事實上主流語言的 SDK 都已經支持了。

所以，對於大部分使用場景來說，官方方案和代理方案都夠用了，其實沒必要太糾結誰更勝一籌，每種方案都有很多靠譜的公司在用。而官方方案具備詳細的文檔和QA，作者本人也在博客中寫了很多設計思路，再加上比較成熟的實踐經驗，我想從這些方面考慮，無論是站在運維還是學習的角度，都是值得選擇的。

早先考慮過codis

後來2.8官方支持sentinel（我們在用的方式）

看消息說3.0支持cluster

用2.x的話就用客戶端預分片，網上資料大把。

用3.x的話自帶集群功能，網上資料大把。

自己寫個proxy，加上一層做key的sharding（目前最簡單的方案）。但是不能解決redis集群複製同步的功能，sharding還是得等3.0發布吧，

Redis-Sentinel，master掛了可以用slave頂上，備用master再掛了，仍然能自動用slave頂上，就是有個問題，master的地址一致在變的說，客戶端會很困惑的。twemproxy對redis性能影響有些大了，接近20%～～～

官方的cluser方案；
twemproxy代理方案；
codis；
哨兵；

用Redis Cluster，緊跟社區走。但是Redis Cluster需要客戶端特別支持，這樣很不友好，所以需要再加一層代理，代理不僅可以屏蔽後端的實現，更重要的是加了代理之後，redis服務更好維護，無論是擴容、遷移什麼的都可以做到對客戶端無感知。

推薦一款代理joyieldInc/predixy

可以看看性能評測：

predixy 一款吊打眾對手的redis代理，你喜歡嗎？

在一個系統裡面，redis是搭建集群還是主從複製，還是都搭建

還是用codis吧，看了看，這幾個月還在更新著。小體量的開發團隊，還是選擇用的多的，持續維護的這種開源方案來的實在。

看看我寫的這個songbin/frc 使用一致性hash實現的Redis集群管理工具，支持redis集群節點的動態縮容和擴容。

參看 http://www.jambr.co.uk/Article/redis-twemproxy-agent

用我司的吧

owt5008137/hiredis-happ · GitHub

codis目前是個不錯的替代方案吧！

很好

3.0好使，不推薦3.0.7。推薦3.0.4