http://www.open-open.com/lib/view/open1481005363568.html
方案一：Redis官方集群方案 Redis Cluster
Redis Cluster是一種服務器sharding分片技術。
Redis3.0版本開始正式提供，解決了多Redis實例協同服務問題，時間較晚，目前能證明在大規模生產環境下成功的案例還不是很多，需要時間檢驗。
Redis Cluster中，Sharding采slot(槽)的概念，一共分成16384個槽。對于每個進入Redis的鍵值對，根據key進行散列，分配到這16384個slot中的某一個中。使用的hash算法也比較簡單，CRC16后16384取模。
Redis Cluster中的每個node負責分攤這16384個slot中的一部分，也就是說，每個slot都對應一個node負責處理。例如三臺node組成的cluster，分配的slot分別是0-5460,5461-10922,10923-16383，
M: 434e5ee5cf198626e32d71a4aee27bc4058b4e45 127.0.0.1:7000 slots:0-5460 (5461 slots) master M: 048a0c9631c87e5ecc97a4ce5834d935f2f938b6 127.0.0.1:7001 slots:5461-10922 (5462 slots) master M: 04ae4184b2853afb8122d15b5b2efa471d4ca251 127.0.0.1:7002 slots:10923-16383 (5461 slots) master
添加或減少節點時？
當動態添加或減少node節點時，需要將16384個slot重新分配，因此槽中的鍵值也要遷移。這一過程，目前處于半自動狀態，需要人工介入。
節點發生故障時
如果某個node發生故障，那它負責的slots也就失效，整個Redis Cluster將不能工作。因此官方推薦的方案是將node都配置成主從結構，即一個master主節點，掛n個slave從節點。
這非常類似Redis Sharding場景下服務器節點通過Sentinel(哨兵)監控架構主從結構，只是Redis Cluster本身提供了故障轉移容錯的能力。
通信端口
Redis Cluster的新節點識別能力、故障判斷及故障轉移能力是通過集群中的每個node和其它的nodes進行通信，這被稱為集群總線(cluster bus)。
通信端口號一般是該node端口號加10000。如某node節點端口號是6379，那么它開放的通信端口是16379。nodes之間的通信采用特殊的二進制協議。
對客戶端來說，整個cluster被看重是一個整體，客戶端可以連接任意一個node進行操作，就像操作單一Redis實例一樣，當客戶端操作的key沒有分配到該node上時，Redis會返回轉向指令，指向正確的node。
如下。在127.0.0.1上部署了三臺Redis實例，組成Redis cluster，端口號分別是7000,7001,7002。在端口號為7000的Redis node上設置<foo,hello>，foo對應的key值重定向到端口號為7002的node節點上。get foo命令時，也會重定向到7002上的node節點上去取數據，返回給客戶端。
[root@centos1 create-cluster]# redis-cli -c -p 7000 127.0.0.1:7000> set foo hello -> Redirected to slot [12182] located at 127.0.0.1:7002 OK 127.0.0.1:7000> get foo -> Redirected to slot [12182] located at 127.0.0.1:7002 "hello"
方案2：Redis Sharding集群
Redis Sharding是一種客戶端Sharding分片技術。
Redis Sharding可以說是Redis Cluster出來之前，業界普遍使用的多Redis實例集群方法。主要思想是采用哈希算法將Redis數據的key進行散列，通過hash函數，特定的key會映射到特定的Redis節點上。
這樣，客戶端就知道該向哪個Redis節點操作數據,需要說明的是，這是在客戶端完成的。Sharding架構如圖所示:
java redis客戶端jedis，已支持Redis Sharding功能，即ShardedJedis以及結合緩存池的ShardedJedisPool。Jedis的Redis Sharding實現具有如下特點:
1、采用一致性哈希算法(consistent hashing)
將key和節點name同時哈希，然后進行映射匹配，采用的算法是MURMUR_HASH。一致性哈希主要原因是當增加或減少節點時，不會產生由于重新匹配造成的rehashing。一致性哈希只影響相鄰節點key分配，影響量小。
2、虛擬節點
ShardedJedis會對每個Redis節點，根據名字虛擬化出160個虛擬節點進行散列。用虛擬節點做映射匹配，可以在增加或減少Redis節點時，key在各Redis節點移動更分配更均勻，而不是只有相鄰節點受影響。如圖，Redis節點1虛擬化成NODE1-1和NODE1-2,散列中哈希環上。這樣當object1、object2散列時，選取最近節點NODE1-1和NODE1-2,而NODE1-1和NODE1-2又是NODE節點的虛擬節點，即實際存儲在NODE節點上。
增加虛擬節點，可以保證平衡性，即每臺Redis機器，存儲的數據都差不多，而不是一臺機器存儲的數據較多，其它的少。
3、ShardedJedis支持keyTagPattern模式
抽取key的一部分keyTag做sharding，這樣通過合理命名key,可以將一組相關聯的key放入同一Redis節點，避免跨節點訪問。即客戶端將相同規則的key值，指定存儲在同一Redis節點上。
添加或減少節點時？
Redis Sharding采用客戶端Sharding方式，服務端的Redis還是一個個相對獨立的Redis實例節點。同時，我們也不需要增加額外的中間處理組件，這是一種非常輕量、靈活的Redis多實例集群方案。
當然，這種輕量靈活方式必然在集群其它能力方面做出妥協。比如擴容，當想要增加Redis節點時，盡管采用一致性哈希，那么不同的key分布到不同的Redis節點上。
當我們需要擴容時，增加機器到分片列表中。這時候客戶端根據key算出來落到跟原來不同的機器上，這樣如果要取某一個值，會出現取不到的情況。
對于這一種情況，一般的作法是取不到后，直接從后端數據庫重新加載數據，但有些時候，擊穿緩存層，直接訪問數據庫層，會對系統訪問造成很大壓力。
Redis作者給出了一個辦法--presharding。
是一種在線擴容的方法，原理是將每一臺物理機上，運行多個不同端口的Redis實例，假如三個物理機，每個物理機運行三個Redis實例，那么我們的分片列表中實際有9個Redis實例，當我們需要擴容時，增加一臺物理機，步驟如下：
1、在新的物理機上運行Redis-server
2、該Redis-server從屬于（slaveof）分片列表中的某一Redis-Server(假設叫RedisA)。
3、主從復制(Replication)完成后，將客戶端分片列表中RedisA的IP和端口改為新物理機上Redis-Server的IP和端口。
4、停止RedisA
這樣相當于將某一Redis-Server轉移到了一臺新機器上。但還是很依賴Redis本身的復制功能，如果主庫快照數據文件過大，這個復制的過程也會很久，同時也會給主Redis帶來壓力，所以做這個拆分的過程最好選擇業務訪問低峰時段進行。
節點發生故障時
并不是只有增刪Redis節點引起鍵值丟失問題，更大的障礙來自Redis節點突然宕機。
為不影響Redis性能，盡量不開啟AOF和RDB文件保存功能，因此需架構Redis主備模式，主Redis宕機，備Redis留有備份，數據不會丟失。
Sharding演變成如下：
這樣，我們的架構模式變成一個Redis節點切片包含一個主Redis和一個備Redis，主備共同組成一個Redis節點，通過自動故障轉移，保證了節點的高可用性.
Redis Sentinel哨兵
提供了主備模式下Redis監控、故障轉移等功能，達到系統的高可用性。
讀寫分離
高訪問時量下，即使采用Sharding分片，一個單獨節點還是承擔了很大的訪問壓力，這時我們還需要進一步分解。
通常情況下，讀常常是寫的數倍，這時我們可以將讀寫分離，讀提供更多的實例數。利用主從模式實現讀寫分離，主負責寫，從負責只讀，同時一主掛多個從。在Redis Sentinel監控下，還可以保障節點故障的自動監測。
方案3：利用代理中間件實現大規劃Redis集群
上面分別介紹了基于客戶端Sharding的Redis Sharding和基于服務端sharding的Redis Cluster。
客戶端Sharding技術
優勢：服務端的Redis實例彼此獨立，相互無關聯，非常容易線性擴展，系統靈活性很強。
不足：1、由于sharding處理放到客戶端，規模擴大時給運維帶來挑戰。
2、服務端Redis實例群拓撲結構有變化時，每個客戶端都需要更新調整。
3、連接不能共享，當應用規模增大時，資源浪費制約優化。
服務端Sharding技術
優勢：服務端Redis集群拓撲結構變化時，客戶端不需要感知，客戶端像使用單Redis服務器一樣使用Redis Cluster，運維管理也比較方便。
不足：Redis Cluster正式版推出時間不長，系統穩定性、性能等需要時間檢驗，尤其中大規模使用場景。
能不能結合二者優勢?既能使服務端各實例彼此獨立，支持線性可伸縮，同時sharding又能集中處理，方便統一管理？
中間件sharding分片技術
twemproxy就是一種中間件sharding分片的技術，處于客戶端和服務器的中間，將客戶端發來的請求，進行一定的處理后（如sharding），再轉發給后端真正的Redis服務器。
也就是說，客戶端不直接訪問Redis服務器，而是通過twemproxy代理中間件間接訪問。
tweproxy中間件的內部處理是無狀態的，起源于twitter，不僅支持redis，同時支持memcached。
使用了中間件，twemproxy可以通過共享與后端系統的連接，降低客戶端直接連接后端服務器的連接數量。同時，它也提供sharding功能，支持后端服務器集群水平擴展。統一運維管理也帶來了方便。
當然，由于使用了中間件，相比客戶端直轄服務器方式，性能上肯定會有損耗，大約降低20%左右。
另一個知名度較高的實現是 Codis，由豌豆莢的團隊開發。感興趣的讀者可以搜索相關資料。
總結：幾種方案如何選擇。
上面大致講了三種集群方案，主要根據sharding在哪個環節進行區分
1、服務端實現分片
官方的 Redis Cluster 實現就是采用這種方式，在這種方案下，客戶端請求到達錯誤節點后不會被錯誤節點代理執行，而是被錯誤節點重定向至正確的節點。
2、客戶端實現分片
分區的邏輯在客戶端實現，由客戶端自己選擇請求到哪個節點。方案可參考一致性哈希，基于 Memcached 的 cache 集群一般是這么做，而這種方案通常適用于用戶對客戶端的行為有完全控制能力的場景。
3、中間件實現分片
有名的例子是 Twitter 的 Twemproxy，Redis 作者對其評價較高。
那么，如何選擇呢？
顯然在客戶端做分片是自定義能力最高的。
優勢在于，在不需要客戶端服務端協作，以及沒有中間層的條件下，每個請求的 roundtrip 時間是相對更小的，搭配良好的客戶端分片策略，可以讓整個集群獲得很好的擴展性。
當然劣勢也很明顯，用戶需要自己對付 Redis 節點宕機的情況，需要采用更復雜的策略來做 replica，以及需要保證每個客戶端看到的集群“視圖”是一致的。
中間件的方案對客戶端實現的要求是最低的，客戶端只要支持基本的 Redis 通信協議即可，至于擴容、多副本、主從切換等機制客戶端都不必操心，因此這種方案也很適合用來做“緩存服務”。
官方推出的協作方案也完整地支持了分片和多副本，相對于各種 proxy，這種方案假設了客戶端實現是可以與服務端“協作”的，事實上主流語言的 SDK 都已經支持了。
所以，對于大部分使用場景來說，官方方案和代理方案都夠用了，其實沒必要太糾結誰更勝一籌，每種方案都有很多靠譜的公司在用。