redis集群的方法

這篇文章將為大家詳細講解有關redis集群的方法，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

Redis Sharding集群

Redis Sharding是一種客戶端Sharding分片技術。

Redis Sharding可以說是Redis Cluster出來之前，業界普遍使用的多Redis實例集群方法。主要思想是采用哈希算法將Redis數據的key進行散列，通過hash函數，特定的key會映射到特定的Redis節點上。

這樣，客戶端就知道該向哪個Redis節點操作數據,需要說明的是，這是在客戶端完成的。

java redis客戶端jedis，已支持Redis Sharding功能，即ShardedJedis以及結合緩存池的ShardedJedisPool。Jedis的Redis Sharding實現具有如下特點:

1、采用一致性哈希算法(consistent hashing)

將key和節點name同時哈希，然后進行映射匹配，采用的算法是MURMUR_HASH。一致性哈希主要原因是當增加或減少節點時，不會產生由于重新匹配造成的rehashing。一致性哈希只影響相鄰節點key分配，影響量小。更多一致性哈希算法介紹，可以參考：http://blog.csdn.net/cywosp/article/details/23397179/

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監控下，還可以保障節點故障的自動監測。

關于redis集群的方法就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。