前言

Redis大家都不陌生，就算是沒(méi)用過(guò)，也都聽(tīng)說(shuō)過(guò)了。

作為最廣泛使用的KV內(nèi)存數(shù)據(jù)庫(kù)之一，在當(dāng)今的大流量時(shí)代，單機(jī)模式略顯單薄，免不了要有一些拓展的方案。

筆者下文會(huì)對(duì)各種方案進(jìn)行介紹，并且給出_場(chǎng)景_，實(shí)現(xiàn) 等等概述，還會(huì)提到一些新手常見(jiàn)的誤區(qū)。

[[423547]]

正文

先從基礎(chǔ)的拓展方式開(kāi)始，這樣更便于理解較高級(jí)的模式。

ps: 本文背景是以筆者落筆時(shí)官網(wǎng)最新穩(wěn)定版5.0.8為準(zhǔn)，雖然還沒(méi)寫(xiě)完就變成了6.0.1。

分區(qū)

概述

分區(qū)(Partitioning)是一種最為簡(jiǎn)單的拓展方式。

在我們面臨單機(jī)的存儲(chǔ)空間瓶頸時(shí)，第一點(diǎn)就能想到像傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)一樣，進(jìn)行數(shù)據(jù)分區(qū)。

或者假設(shè)手中有N臺(tái)機(jī)器可以作為Redis服務(wù)器

所有機(jī)器內(nèi)存總和有256G, 而客戶(hù)端正好也需要一個(gè)大內(nèi)存的存儲(chǔ)空間。

我們除了可以把內(nèi)存條都拆下來(lái)焊到一個(gè)機(jī)器上，也可以選擇分區(qū)使用，這樣又拓展了計(jì)算能力。

單指分區(qū)來(lái)講，即將全部數(shù)據(jù)分散在多個(gè)Redis實(shí)例中，每個(gè)實(shí)例不需要關(guān)聯(lián)，可以是完全獨(dú)立的。

使用方式

•  客戶(hù)端處理

 和傳統(tǒng)的數(shù)據(jù)庫(kù)分庫(kù)分表一樣，可以從key入手，先進(jìn)行計(jì)算，找到對(duì)應(yīng)數(shù)據(jù)存儲(chǔ)的實(shí)例在進(jìn)行操作。

 范圍角度，比如orderId:1~orderId:1000放入實(shí)例1，orderId:1001~orderId:2000放入實(shí)例2...

 哈希計(jì)算，就像我們的hashmap一樣，用hash函數(shù)加上位運(yùn)算或者取模，高級(jí)玩法還有一致性Hash[1]等操作，找到對(duì)應(yīng)的實(shí)例進(jìn)行操作

•  使用代理中間件

我們可以開(kāi)發(fā)獨(dú)立的代理中間件，屏蔽掉處理數(shù)據(jù)分片的邏輯，獨(dú)立運(yùn)行。

 當(dāng)然也有他人已經(jīng)造好的輪子，Redis也有優(yōu)秀的代理中間件，譬如Twemproxy[2]，或者codis[3]，可以結(jié)合場(chǎng)景選擇是否使用。

缺點(diǎn)

•  無(wú)緣多key操作，key都不一定在一個(gè)實(shí)例上，那么多key操作或者多key事務(wù)自然是不支持。
•  維護(hù)成本，由于每個(gè)實(shí)例在物理和邏輯上，都屬于單獨(dú)的一個(gè)節(jié)點(diǎn)，缺乏統(tǒng)一管理。
•  靈活性有限，范圍分片還好，比如hash+MOD這種方式，如果想動(dòng)態(tài)調(diào)整Redis實(shí)例的數(shù)量，就要考慮大量數(shù)據(jù)遷移，這就非常麻煩了。

同為開(kāi)發(fā)者，深知我們雖然總能“曲線(xiàn)救國(guó)”的完成一些當(dāng)前環(huán)境不支持的功能，但是總歸要麻煩一些。

主從

概述數(shù)據(jù)遷移

常說(shuō)的主從(Master-Slave)，也就是復(fù)制(Replication)方式，怎么稱(chēng)呼都可以。

同上面的分區(qū)一樣，也是Redis高可用架構(gòu)的基礎(chǔ)，新手可能會(huì)誤以為這類(lèi)基礎(chǔ)模式即是“高可用”，這并不是十分正確的。

分區(qū)暫時(shí)能解決單點(diǎn)無(wú)法容納的數(shù)據(jù)量問(wèn)題，但是一個(gè)Key還是只在一個(gè)實(shí)例上，在大流量時(shí)代顯得不那么可靠。

主從就是另一個(gè)緯度的拓展，節(jié)點(diǎn)將數(shù)據(jù)同步到從節(jié)點(diǎn)，就像將實(shí)例“分身”了一樣，可靠性又提高了不少。

圖畫(huà)的有些夸張了，主要還是想體現(xiàn)結(jié)構(gòu)靈活，是一主一從，還是一主多從，還是一主多從多從... 看你心情

有了“實(shí)例分身”，自然就可以做讀寫(xiě)分離，將讀流量均攤在各個(gè)從節(jié)點(diǎn)。

使用方式

[[423548]]

高手云集的時(shí)代，聊天軟件難免要備上這么一張表情包。

這表情包和使用方式有什么關(guān)系呢？首先看看使用方式：

1.  作為主節(jié)點(diǎn)的Redis實(shí)例，并不要求配置任何參數(shù)，只需要正常啟動(dòng)
2.  作為從節(jié)點(diǎn)的實(shí)例，使用配置文件或命令方式REPLICAOF 主節(jié)點(diǎn)Host 主節(jié)點(diǎn)port即可完成主從配置

是不是和表情包一樣，“dalao”沒(méi)動(dòng)，我去“抱大腿”。

這樣一個(gè)主從最小配置就完成了，主從實(shí)例即可對(duì)外提供服務(wù)。

命令里的“主節(jié)點(diǎn)”是相對(duì)的，slave也可以抱slave大腿，也就是上文提到的結(jié)構(gòu)靈活。

學(xué)習(xí)資料：Java進(jìn)階視頻資源

缺點(diǎn)

•  slave節(jié)點(diǎn)都是只讀的，如果寫(xiě)流量大的場(chǎng)景，就有些力不從心了。

 那我把slave節(jié)點(diǎn)只讀關(guān)掉不就行了？當(dāng)然不行，數(shù)據(jù)復(fù)制是由主到從，從節(jié)點(diǎn)獨(dú)有數(shù)據(jù)同步不到主節(jié)點(diǎn)，數(shù)據(jù)就不一致了。

•  故障轉(zhuǎn)移不友好，主節(jié)點(diǎn)掛掉后，寫(xiě)處理就無(wú)處安放，需要手工的設(shè)定新的主節(jié)點(diǎn)，如使用REPLICAOF no one(誰(shuí)大腿我都不抱了) 晉升為主節(jié)點(diǎn)，再梳理其他slave節(jié)點(diǎn)的新主配置，相對(duì)來(lái)說(shuō)比較麻煩。

哨兵

概述

主從的手工故障轉(zhuǎn)移，肯定讓人很難接受，自然就出現(xiàn)了高可用方案-哨兵（Sentinel）。

我們可以在主從架構(gòu)不變的場(chǎng)景，直接加入Redis Sentinel，對(duì)節(jié)點(diǎn)進(jìn)行監(jiān)控，來(lái)完成自動(dòng)的故障發(fā)現(xiàn)與轉(zhuǎn)移。

并且還能夠充當(dāng)配置提供者，提供主節(jié)點(diǎn)的信息，就算發(fā)生了故障轉(zhuǎn)移，也能提供正確的地址。

哨兵本身也是Redis實(shí)例的一種，但不作為數(shù)據(jù)存儲(chǔ)方使用，啟動(dòng)命令也是不一樣的。

雖然圖有些復(fù)雜，看起來(lái)像要召喚光能使者。

[[423550]]

其實(shí)實(shí)際使用起來(lái)是很便捷的。學(xué)習(xí)資料：Java進(jìn)階視頻資源

使用方式

Sentinel的最小配置，一行即可：

sentinel monitor <主節(jié)點(diǎn)別名> <主節(jié)點(diǎn)host> <主節(jié)點(diǎn)端口> <票數(shù)> 

只需要配置master即可，然后用redis-sentinel <配置文件> 命令即可啟用。

Redis官網(wǎng)[4]提到的“最小配置”是如下所示，除了上面提到的一行，還有其它的一些配置： 

sentinel monitor mymaster 127.0.0.1 6379 2  
sentinel down-after-milliseconds mymaster 60000  
sentinel failover-timeout mymaster 180000  
sentinel parallel-syncs mymaster 1  
sentinel monitor resque 192.168.1.3 6380 4  
sentinel down-after-milliseconds resque 10000  
sentinel failover-timeout resque 180000  
sentinel parallel-syncs resque 5 

這是因?yàn)楣倬W(wǎng)加了一個(gè)修飾詞，是“典型的最小配置”，把重要參數(shù)和多主的例子都寫(xiě)出來(lái)了，照顧大家CV大法的時(shí)候，不要忘記重要參數(shù)，其實(shí)都是有默認(rèn)值的。

正如該例所示，設(shè)置主節(jié)點(diǎn)別名就是為了監(jiān)控多主的時(shí)候，與其額外配置項(xiàng)能夠與其對(duì)應(yīng), 以及sentinel一些命令，如SENTINEL get-master-addr-by-name就要用到別名了。

哨兵數(shù)量建議在三個(gè)以上且為奇數(shù)，在Redis官網(wǎng)[5]也提到了各種情況的“布陣”方式，非常值得參考。

更多

既然是高可用方案，并非有嚴(yán)格意義上的“缺點(diǎn)”，還需配合使用場(chǎng)景進(jìn)行考量。

•  故障轉(zhuǎn)移期間短暫的不可用，但其實(shí)官網(wǎng)的例子也給出了parallel-syncs參數(shù)來(lái)指定并行的同步實(shí)例數(shù)量，以免全部實(shí)例都在同步出現(xiàn)整體不可用的情況，相對(duì)來(lái)說(shuō)要比手工的故障轉(zhuǎn)移更加方便。
•  分區(qū)邏輯需要自定義處理，雖然解決了主從下的高可用問(wèn)題，但是Sentinel并沒(méi)有提供分區(qū)解決方案，還需開(kāi)發(fā)者考慮如何建設(shè)。
•  既然是還是主從，如果異常的寫(xiě)流量搞垮了主節(jié)點(diǎn)，那么自動(dòng)的“故障轉(zhuǎn)移”會(huì)不會(huì)變成自動(dòng)“災(zāi)難傳遞”，即slave提升為Master之后掛掉，又進(jìn)行提升又被掛掉。
•  不過(guò)最后這點(diǎn)也是筆者猜測(cè)，并沒(méi)有聽(tīng)說(shuō)過(guò)出現(xiàn)這種案例，可不必深究。

集群

概述

Redis Cluster是官方在3.0版本后推出的分布式方案。

對(duì)開(kāi)發(fā)者而言，“官方支持”一詞是大概率非常美好的，小到issue，大到feature。自定義去解決問(wèn)題，成本總是要高一些。

有了官方的正式集群方案，從請(qǐng)求路由、故障轉(zhuǎn)移、彈性伸縮幾個(gè)緯度的使用上，將更為容易。

Cluster不同于哨兵，是支持分區(qū)的。有說(shuō)法Cluster是哨兵的升級(jí)，這是不嚴(yán)謹(jǐn)?shù)摹?/p>

二者緯度不一樣，如果因?yàn)镃luster也有故障轉(zhuǎn)移的功能，就說(shuō)它是哨兵的升級(jí)款，略顯牽強(qiáng)。

Cluster在分區(qū)管理上，使用了“哈希槽”(hash slot)這么一個(gè)概念，一共有16384個(gè)槽位，每個(gè)實(shí)例負(fù)責(zé)一部分槽，通過(guò)CRC16（key）&16383這樣的公式，計(jì)算出來(lái)key所對(duì)應(yīng)的槽位。

雖然在節(jié)點(diǎn)和key二者中又引入了槽的概念，看起來(lái)不易理解，實(shí)際上因?yàn)轭w粒度更細(xì)了，減少了節(jié)點(diǎn)的擴(kuò)容和收縮難度，相比傳統(tǒng)策略還是很有優(yōu)勢(shì)。

當(dāng)然，“槽”是虛擬的概念，節(jié)點(diǎn)自身去維護(hù)“槽”的關(guān)系，并不是要真正下載啟動(dòng)個(gè)“槽服務(wù)”在跑。

學(xué)習(xí)資料：Java進(jìn)階視頻資源

使用方式

Redis的各種玩法，都是從配置文件著手，集群也不例外。 

cluster-enabled yes  
cluster-config-file "redis-node.conf" 

關(guān)鍵配置簡(jiǎn)潔明了，有兩步

•  開(kāi)啟集群
•  指定集群配置文件

集群配置文件(cluster-config-file)為內(nèi)部使用，可以不去指定，Redis會(huì)幫助創(chuàng)建一個(gè)。啟動(dòng)還是普通的方式redis-server redis.conf

首先以集群方式啟動(dòng)了N臺(tái)Redis實(shí)例，這當(dāng)然還沒(méi)完事。

接下來(lái)的步驟筆者稱(chēng)為“牽線(xiàn)搭橋分配槽”，聽(tīng)起來(lái)還算順口。

“牽線(xiàn)搭橋分配槽”的方式也在不斷升級(jí)，從直接用原始命令來(lái)處理，到使用腳本，以及現(xiàn)在的Redis-cli官方支持，使用哪種方式都可以。 

redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 \  
127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 \  
--cluster-replicas 1 

上方的命令即是Redis官網(wǎng)給出的redis-cli的方式用法，一行命令完成“三主三從”以及自動(dòng)分配槽的操作。

這樣集群就搭建完成了，當(dāng)然，使用官方提供的check命令檢查一下，也是有必要的。 

redis-cli --cluster check 127.0.0.1:7001 

更多

•  雖然是對(duì)分區(qū)良好支持，但也有一些分區(qū)的老問(wèn)題，譬如：如果不在同一個(gè)“槽”的數(shù)據(jù)，是沒(méi)法使用類(lèi)似mset的多鍵操作。
•  在select命令頁(yè)[6]有提到, 集群模式下只能使用一個(gè)庫(kù)，雖然平時(shí)一般也是這么用的，但是要了解一下。
•  運(yùn)維上也要謹(jǐn)慎，俗話(huà)說(shuō)得好，“使用越簡(jiǎn)單底層越復(fù)雜”，啟動(dòng)搭建是很方便，使用時(shí)面對(duì)帶寬消耗，數(shù)據(jù)傾斜等等具體問(wèn)題時(shí)，還需人工介入，或者研究合適的配置參數(shù)。

結(jié)尾

趣談

在寫(xiě)“主從”方案的時(shí)候，發(fā)現(xiàn)有一個(gè)有趣的事情：

筆者開(kāi)始是記得主從的關(guān)鍵命令是SLAVEOF，后來(lái)查閱官方的時(shí)候，發(fā)現(xiàn)命令已經(jīng)更改為REPLICAOF，雖然SLAVEOF還能用。

官網(wǎng)的一些描述詞匯，有的地方還是Slave，也有些是用Replication。

好奇的筆者查了一下相關(guān)的資料，并看了些Redis作者antirez的有關(guān)此時(shí)博客，發(fā)現(xiàn)已經(jīng)是兩年前的事情了。

其實(shí)就是“Slave”這個(gè)變量名給了一些人機(jī)會(huì)，借此“噴”了一波作者，作者也做出了一部分妥協(xié)。

有興趣的盆友可以自己搜搜看，技術(shù)外的東西就不做評(píng)價(jià)了，看個(gè)樂(lè)呵就行。

筆者的主要目的還是：看官方文檔的時(shí)候，別讓不同的“詞匯”迷惑了。

END

本文對(duì)Redis這些拓展方案都作出了大致描述。

具體使用上，還需留意詳細(xì)配置，以及客戶(hù)端支持等綜合情況來(lái)考量。