redis集群的方法

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

Redis Sharding集群

Redis Sharding是一種客戶端Sharding分片技術(shù)。

Redis Sharding可以說是Redis Cluster出來之前，業(yè)界普遍使用的多Redis實(shí)例集群方法。主要思想是采用哈希算法將Redis數(shù)據(jù)的key進(jìn)行散列，通過hash函數(shù)，特定的key會(huì)映射到特定的Redis節(jié)點(diǎn)上。

這樣，客戶端就知道該向哪個(gè)Redis節(jié)點(diǎn)操作數(shù)據(jù),需要說明的是，這是在客戶端完成的。

java redis客戶端jedis，已支持Redis Sharding功能，即ShardedJedis以及結(jié)合緩存池的ShardedJedisPool。Jedis的Redis Sharding實(shí)現(xiàn)具有如下特點(diǎn):

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

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

2、虛擬節(jié)點(diǎn)

ShardedJedis會(huì)對(duì)每個(gè)Redis節(jié)點(diǎn)，根據(jù)名字虛擬化出160個(gè)虛擬節(jié)點(diǎn)進(jìn)行散列。用虛擬節(jié)點(diǎn)做映射匹配，可以在增加或減少Redis節(jié)點(diǎn)時(shí)，key在各Redis節(jié)點(diǎn)移動(dòng)更分配更均勻，而不是只有相鄰節(jié)點(diǎn)受影響。如圖，Redis節(jié)點(diǎn)1虛擬化成NODE1-1和NODE1-2,散列中哈希環(huán)上。這樣當(dāng)object1、object2散列時(shí)，選取最近節(jié)點(diǎn)NODE1-1和NODE1-2,而NODE1-1和NODE1-2又是NODE節(jié)點(diǎn)的虛擬節(jié)點(diǎn)，即實(shí)際存儲(chǔ)在NODE節(jié)點(diǎn)上。

增加虛擬節(jié)點(diǎn)，可以保證平衡性，即每臺(tái)Redis機(jī)器，存儲(chǔ)的數(shù)據(jù)都差不多，而不是一臺(tái)機(jī)器存儲(chǔ)的數(shù)據(jù)較多，其它的少。

3、ShardedJedis支持keyTagPattern模式

抽取key的一部分keyTag做sharding，這樣通過合理命名key,可以將一組相關(guān)聯(lián)的key放入同一Redis節(jié)點(diǎn)，避免跨節(jié)點(diǎn)訪問。即客戶端將相同規(guī)則的key值，指定存儲(chǔ)在同一Redis節(jié)點(diǎn)上。

添加或減少節(jié)點(diǎn)時(shí)？

Redis Sharding采用客戶端Sharding方式，服務(wù)端的Redis還是一個(gè)個(gè)相對(duì)獨(dú)立的Redis實(shí)例節(jié)點(diǎn)。同時(shí)，我們也不需要增加額外的中間處理組件，這是一種非常輕量、靈活的Redis多實(shí)例集群方案。

當(dāng)然，這種輕量靈活方式必然在集群其它能力方面做出妥協(xié)。比如擴(kuò)容，當(dāng)想要增加Redis節(jié)點(diǎn)時(shí)，盡管采用一致性哈希，那么不同的key分布到不同的Redis節(jié)點(diǎn)上。

當(dāng)我們需要擴(kuò)容時(shí)，增加機(jī)器到分片列表中。這時(shí)候客戶端根據(jù)key算出來落到跟原來不同的機(jī)器上，這樣如果要取某一個(gè)值，會(huì)出現(xiàn)取不到的情況。

對(duì)于這一種情況，一般的作法是取不到后，直接從后端數(shù)據(jù)庫重新加載數(shù)據(jù)，但有些時(shí)候，擊穿緩存層，直接訪問數(shù)據(jù)庫層，會(huì)對(duì)系統(tǒng)訪問造成很大壓力。

Redis作者給出了一個(gè)辦法--presharding。

是一種在線擴(kuò)容的方法，原理是將每一臺(tái)物理機(jī)上，運(yùn)行多個(gè)不同端口的Redis實(shí)例，假如三個(gè)物理機(jī)，每個(gè)物理機(jī)運(yùn)行三個(gè)Redis實(shí)例，那么我們的分片列表中實(shí)際有9個(gè)Redis實(shí)例，當(dāng)我們需要擴(kuò)容時(shí)，增加一臺(tái)物理機(jī)，步驟如下：

1、在新的物理機(jī)上運(yùn)行Redis-server

2、該Redis-server從屬于（slaveof）分片列表中的某一Redis-Server(假設(shè)叫RedisA)。

3、主從復(fù)制(Replication)完成后，將客戶端分片列表中RedisA的IP和端口改為新物理機(jī)上Redis-Server的IP和端口。

4、停止RedisA

這樣相當(dāng)于將某一Redis-Server轉(zhuǎn)移到了一臺(tái)新機(jī)器上。但還是很依賴Redis本身的復(fù)制功能，如果主庫快照數(shù)據(jù)文件過大，這個(gè)復(fù)制的過程也會(huì)很久，同時(shí)也會(huì)給主Redis帶來壓力，所以做這個(gè)拆分的過程最好選擇業(yè)務(wù)訪問低峰時(shí)段進(jìn)行。

節(jié)點(diǎn)發(fā)生故障時(shí)

并不是只有增刪Redis節(jié)點(diǎn)引起鍵值丟失問題，更大的障礙來自Redis節(jié)點(diǎn)突然宕機(jī)。

為不影響Redis性能，盡量不開啟AOF和RDB文件保存功能，因此需架構(gòu)Redis主備模式，主Redis宕機(jī)，備Redis留有備份，數(shù)據(jù)不會(huì)丟失。

Sharding演變成如下：

這樣，我們的架構(gòu)模式變成一個(gè)Redis節(jié)點(diǎn)切片包含一個(gè)主Redis和一個(gè)備Redis，主備共同組成一個(gè)Redis節(jié)點(diǎn)，通過自動(dòng)故障轉(zhuǎn)移，保證了節(jié)點(diǎn)的高可用性.

Redis Sentinel哨兵

提供了主備模式下Redis監(jiān)控、故障轉(zhuǎn)移等功能，達(dá)到系統(tǒng)的高可用性。

讀寫分離

高訪問時(shí)量下，即使采用Sharding分片，一個(gè)單獨(dú)節(jié)點(diǎn)還是承擔(dān)了很大的訪問壓力，這時(shí)我們還需要進(jìn)一步分解。

通常情況下，讀常常是寫的數(shù)倍，這時(shí)我們可以將讀寫分離，讀提供更多的實(shí)例數(shù)。利用主從模式實(shí)現(xiàn)讀寫分離，主負(fù)責(zé)寫，從負(fù)責(zé)只讀，同時(shí)一主掛多個(gè)從。在Redis Sentinel監(jiān)控下，還可以保障節(jié)點(diǎn)故障的自動(dòng)監(jiān)測。

關(guān)于redis集群的方法就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。