首先，無論我們使用自己的物理主機還是雲服務主機，內存資源往往是有限的。擴大規模不是壹個好辦法。我們需要橫向擴展，橫向擴展需要多個主機協同提供服務，也就是分布式多個Redis實例協同運行。
其次，目前硬件資源成本降低，多核CPU和幾十千兆內存的主機非常普遍。對於主進程是單線程的Redis來說，只運行壹個實例似乎有點浪費。同時，管理壹個巨大的內存不如管理壹個相對較小的內存效率高。所以在實際使用中，通常壹臺機器同時運行多個Redis實例。
計劃
1.Redis官方集群方案
Rediscoluster是壹種服務器分片技術，在3.0版本中正式提供。
雷迪斯
在集群中，分片采用槽的概念，壹個* * *分成16384個槽，有點類似前面說的pre。
切分思維。對於進入Redis的每個鍵-值對，它根據鍵被散列，並被分配給這些16384槽中的壹個。使用的哈希算法也相對簡單
單，也就是CRC16之後，16384取模。
Redis集群中的每個節點負責共享這些16384槽的壹部分，即每個
插槽負責處理對應的壹個節點。動態添加或刪除節點節點時，需要重新分配16384個槽位，槽位中的鍵值也要遷移。當然，這個過程，目前。
目前還處於半自動狀態，需要人工幹預。
Redis集群，保證16384槽位對應的節點正常工作，如果壹個節點失效，那麽它所負責的槽位將失效，整個集群將無法工作。
為
為了增加集群的可訪問性，官方推薦的方案是將節點配置成主從結構，即壹個主主節點帶N個從節點。此時，如果主節點丟失。
有效，Redis集群會根據選舉算法選擇壹個從節點作為主節點，整個集群繼續對外提供服務。這和上壹篇文章提到的Redis很像。
在分片場景中，服務器節點通過Sentinel監控構建成主從結構，但Rediscoluster本身提供了故障轉移和容錯能力。
雷迪斯
集群的新的節點識別能力、故障判斷能力和故障轉移能力是集群中的每個節點都在與其他節點進行通信，這被稱為集群總線(Cluster
公共汽車).他們使用壹個特殊的端口號，即國外服務端口號加10000。例如，如果壹個節點的端口號是6379，那麽它與其他節點通信的端口號是
16379。節點間的通信采用特殊的二進制協議。
對於客戶端來說，整個集群被視為壹個整體，客戶端可以連接任意壹個。
節點進行操作，就像操作單個Redis實例壹樣，當客戶端操作的鍵沒有分配給節點時，Redis會返回壹個指向正確節點的轉向指令，
有點像瀏覽器頁面上的302重定向跳轉。
Redis集群是在Redis 3.0之後正式推出的，時間較晚。目前能在大規模生產環境下證明成功的案例並不多，需要時間來檢驗。
2.雷迪斯·哈丁星團
Redis 3正式推出官方集群技術，解決了多個Redis實例的協同服務問題。Rediscoluster可以說是服務器端分片技術的體現，即按照壹定的算法將鍵值合理分配給各個實例碎片，同時各個實例節點進行協調和通信，* * *承擔與外界壹致的服務。
多Redis實例業務比單Redis實例復雜得多，涉及定位、協調、容錯、擴容等技術問題。這裏，我們介紹壹種輕量級的客戶端Redis分片技術。
雷迪斯
分片可以說是Redis
在Cluster問世之前，業界普遍采用的是多Redis實例聚類方法。其主要思想是利用哈希算法對Redis數據的密鑰進行哈希，並通過哈希函數，具體
的鍵將被映射到特定的Redis節點。這樣，客戶機就知道將數據操作到哪個Redis節點。分片架構如圖所示:
好在java redis客戶端驅動jedis已經支持redis分片功能，即ShardedJedis和ShardedJedisPool結合緩存池。
Jedis的Redis分片實現具有以下特征:
挑選
使用壹致的哈希算法(壹致
Hashing)，同時散列鍵和節點名，然後映射匹配，采用的算法是mur burn _ hash。使用壹致的散列而不是簡單的類
類似哈希的模塊化映射的主要原因是當節點增加或減少時，不會出現重新匹配導致的重新哈希。壹致哈希只影響相鄰節點的密鑰分發，影響較小。
2.
為了避免壹致性哈希只影響鄰居節點所帶來的節點分配壓力，ShardedJedis會根據每個Redis節點的名稱(不，Jedis會給它壹個默認的名稱)對其進行虛擬化。
160個虛擬節點被散列。根據權重，也可以虛擬化160倍數的虛擬節點。使用虛擬節點進行映射和匹配可以增加或減少Redis節點。
當為時，密鑰在每個Redis節點中更均勻地重新分布，而不是僅影響相鄰節點。
3.ShardedJedis支持keyTagPattern模式，即提取keyTag的壹部分進行分片，通過合理命名鍵，將壹組相關的鍵放入同壹個Redis節點，這對於避免跨節點訪問相關數據非常重要。
Redis分片采用客戶端harding模式，服務器端Redis仍然是壹個相對獨立的Redis實例節點，沒有任何變化。同時，我們不需要增加額外的中間處理組件，這是壹種非常輕量級和靈活的Redis多實例聚類方法。
當然，Redis分片的輕量級和靈活的方式必然會損害集群的其他功能。比如在擴容中，當妳要添加Redis節點時，即使使用了壹致哈希，仍然會有鍵無法匹配而丟失，這時就需要進行鍵值遷移。
作為壹個輕量級客戶端，分片，處理Redis鍵值遷移是不現實的，需要應用層允許Redis中的數據丟失或者從後端數據庫重新加載數據。但有時候，突破緩存層，直接訪問數據庫層，會對系統訪問造成很大壓力。有沒有其他方法可以改善這種情況？
雷迪斯
作者給出了壹個更方便的方法——預harding，即預先根據系統規模部署盡可能多的Redis實例，這些實例占用的系統資源非常少，可以供壹臺物理機使用。
多個部門，讓他們都參與分片，當需要擴展時，選擇壹個實例作為主節點，新添加的Redis節點作為從節點進行數據復制。數據同步後，修改
分片配置，讓指向原實例的分片指向新機器上擴展的Redis節點，將新的Redis節點調整為主節點，這樣原實例就不能再用了。
預硬化
就是提前分配足夠的碎片，在擴展的時候只把原來屬於壹個碎片的Redis實例替換成容量更大的新Redis實例。參與分片的分片沒有改變，所以它們也
不存在鍵值從壹個區域轉移到另壹個分區，但是屬於同壹個分區的鍵值從原來的Redis實例同步到新的Redis實例的現象。
不僅增加
刪除Redis節點導致鍵值丟失，更大的障礙來自Redis節點的突然宕機。《Redis的持久性》壹文中提到，為了不影響Redis的性能，盡量不要打開。
AOF和RDB的文件保存功能可以構成Redis的主要備用模式。當主Redis宕機時，數據不會丟失，備用Redis有備份。
這樣，我們的架構模式就改變了。
Redis節點片包含壹個主Redis和壹個備用Redis。當主Redis宕機時，備用Redis接管，上升到主Redis繼續提供服務。物主
備用* * *形成Redis節點，通過自動故障轉移保證節點的高可用性。然後，分片架構演變為:
Redis Sentinel提供Redis監控和主備模式下的故障轉移功能，實現系統的高可用性。
在高流量下，即使有分片碎片化，單個節點仍然承受著很大的訪問壓力。這時候就需要進壹步分解了。壹般來說，應用程序訪問Redis時的讀操作和寫操作有很大的區別，讀往往是寫的好幾倍。這時候我們可以把閱讀和寫作分開，閱讀提供了更多的實例。
您可以使用主從模式將讀寫分開。主人負責寫，奴隸負責讀。壹個主同時掛多個從。在哨兵監控下，也能保證節點故障的自動監控。
3.利用代理中間件實現大規模Redis集群
以上介紹了兩種多Redis服務器集群的方式，即基於客戶端的Redis分片和基於服務器的Redis集群。
客戶端分片技術的優勢在於服務器上的Redis實例相互獨立，互不關聯，每個Redis實例都像單臺服務器壹樣運行，非常容易線性擴展，系統非常靈活。它的缺點是:
由於分片處理放在客戶端，規模進度擴大時會給運維帶來挑戰。
當服務器Redis實例組的拓撲結構發生變化時，每個客戶端都需要進行更新和調整。
連接無法享受，應用規模增大，資源浪費制約優化。
sharding的Redis集群的優勢在於，當服務器的Redis集群拓撲結構發生變化時，客戶端無需知曉，客戶端像使用單臺Redis服務器壹樣使用Redis集群，運維管理更加方便。
但Redis集群正式版發布時間不長，系統的穩定性和性能都需要時間來檢驗，尤其是在大規模使用場合。
能不能結合兩者的優點？即可以使服務器實例相互獨立，支持線性伸縮，同時分片可以集中處理，便於統壹管理？本文介紹的Redis代理中間件Twemproxy就是這樣壹種利用中間件進行分片的技術。
Twemproxy位於客戶端和服務器的中間，將客戶端發來的請求經過壹些處理(比如分片)後轉發給真正的Redis服務器。換句話說，客戶端不直接訪問Redis服務器，而是通過twemproxy代理中間件間接訪問。
參考Redis分片架構，添加代理中間件的Redis集群架構如下:
twemproxy中間件的內部處理是無狀態的，它可以很容易地自己集群，從而避免單點壓力或故障。
Twemproxy又稱胡桃夾子，源於twitter系統中redis/memcached集群的開發實踐，運行良好，代碼專用於開源社區。輕量高效，C語言開發，項目網址為:github-Twitter/twemproxy: Afast，memcached和redis的輕量級代理。
Twemproxy後端不僅支持redis，還支持memcached，這是twitter系統的特定環境造成的。
由於中間件的使用，twemproxy可以通過* *，享受與後端系統的連接，減少了客戶端直接連接到後端服務器的連接數。同時還提供了分片功能，支持後端服務器集群的橫向擴展。統壹的運維管理也帶來了便利。
當然，也是由於使用了中間件代理，相比客戶端直接連接服務器的方法，性能會有所損失，實測結果會降低20%左右。