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

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

| 正文

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

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

分區(qū)

> 概述

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

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

或者假設(shè)手中有N臺(tái)機(jī)器可以作為Redis服務(wù)器，所有機(jī)器內(nèi)存總和有256G, 而客戶端正好也需要一個(gè)大內(nèi)存的存儲(chǔ)空間。

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

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

> 使用方式

客戶端處理

和傳統(tǒng)的數(shù)據(jù)庫分庫分表一樣，可以從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等操作，找到對(duì)應(yīng)的實(shí)例進(jìn)行操作

使用代理中間件

我們可以開發(fā)獨(dú)立的代理中間件，屏蔽掉處理數(shù)據(jù)分片的邏輯，獨(dú)立運(yùn)行。當(dāng)然也有他人已經(jīng)造好的輪子，Redis也有優(yōu)秀的代理中間件，譬如Twemproxy，或者codis，可以結(jié)合場(chǎng)景選擇是否使用。

> 缺點(diǎn)

無緣多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ù)遷移，這就非常麻煩了。

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

主從

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

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

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

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

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

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

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

> 使用方式

高手云集的時(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”沒動(dòng)，我去“抱大腿”。這樣一個(gè)主從最小配置就完成了，主從實(shí)例即可對(duì)外提供服務(wù)。命令里的“主節(jié)點(diǎn)”是相對(duì)的，slave也可以抱slave大腿，也就是上文提到的結(jié)構(gòu)靈活。

> 缺點(diǎn)

slave節(jié)點(diǎn)都是只讀的，如果寫流量大的場(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)掛掉后，寫處理就無處安放，需要手工的設(shè)定新的主節(jié)點(diǎn)，如使用REPLICAOF no one(誰大腿我都不抱了) 晉升為主節(jié)點(diǎn)，再梳理其他slave節(jié)點(diǎn)的新主配置，相對(duì)來說比較麻煩。

哨兵

> 概述

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

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

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

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

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

其實(shí)實(shí)際使用起來是很便捷的。

> 使用方式

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

1sentinel monitor <主節(jié)點(diǎn)別名> <主節(jié)點(diǎn)host> <主節(jié)點(diǎn)端口> <票數(shù)>
只需要配置master即可，然后用redis-sentinel <配置文件> 命令即可啟用。

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

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

這是因?yàn)楣倬W(wǎng)加了一個(gè)修飾詞，是“典型的最小配置”，把重要參數(shù)和多主的例子都寫出來了

，照顧大家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)也提到了各種情況的“布陣”方式，非常值得參考。

> 更多

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

故障轉(zhuǎn)移期間短暫的不可用，但其實(shí)官網(wǎng)的例子也給出了parallel-syncs參數(shù)來指定并行的同步實(shí)例數(shù)量，以免全部實(shí)例都在同步出現(xiàn)整體不可用的情況，相對(duì)來說要比手工的故障轉(zhuǎn)移更加方便。

分區(qū)邏輯需要自定義處理，雖然解決了主從下的高可用問題，但是Sentinel并沒有提供分區(qū)解決方案，還需開發(fā)者考慮如何建設(shè)。

既然是還是主從，如果異常的寫流量搞垮了主節(jié)點(diǎn)，那么自動(dòng)的“故障轉(zhuǎn)移”會(huì)不會(huì)變成自動(dòng)“災(zāi)難傳遞”，即slave提升為Master之后掛掉，又進(jìn)行提升又被掛掉。

不過最后這點(diǎn)也是筆者猜測(cè)，并沒有聽說過出現(xiàn)這種案例，可不必深究。

集群

> 概述

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

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

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

Cluster不同于哨兵，是支持分區(qū)的。有說法Cluster是哨兵的升級(jí)，這是不嚴(yán)謹(jǐn)?shù)摹?/span>二者緯度不一樣，如果因?yàn)镃luster也有故障轉(zhuǎn)移的功能，就說它是哨兵的升級(jí)款，略顯牽強(qiáng)。

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

雖然在節(jié)點(diǎn)和key二者中又引入了槽的概念，看起來不易理解，實(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ù)”在跑。

> 使用方式

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

1cluster-enabled yes
2cluster-config-file "redis-node.conf"
關(guān)鍵配置簡(jiǎn)潔明了，有兩步

開啟集群
指定集群配置文件

集群配置文件(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)然還沒完事。接下來的步驟筆者稱為“牽線搭橋分配槽”，聽起來還算順口。

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

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

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

分配槽的操作。

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

1redis-cli --cluster check 127.0.0.1:7001

> 更多

雖然是對(duì)分區(qū)良好支持，但也有一些分區(qū)的老問題，譬如：如果不在同一個(gè)“槽”的數(shù)據(jù)，是沒法使用類似mset的多鍵操作。

在select命令頁有提到, 集群模式下只能使用一個(gè)庫，雖然平時(shí)一般也是這么用的，但是要了解一下。

運(yùn)維上也要謹(jǐn)慎，俗話說得好，“使用越簡(jiǎn)單底層越復(fù)雜”，啟動(dòng)搭建是很方便，使用時(shí)面對(duì)帶寬消耗，數(shù)據(jù)傾斜等等具體問題時(shí)，還需人工介入，或者研究合適的配置參數(shù)。

| 結(jié)尾

趣談

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

筆者開始是記得主從的關(guān)鍵命令是SLAVEOF，后來查閱官方的時(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è)樂呵就行。

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

入骨相思知不知

玲瓏骰子安紅豆

入我相思門，知我相思苦，長(zhǎng)相思兮長(zhǎng)相憶，短相思兮無窮極。

Redis 的這些拓展方案

| 正文

分區(qū)

> 概述

> 使用方式

> 缺點(diǎn)

主從

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

> 使用方式

> 缺點(diǎn)

哨兵

> 概述

> 使用方式

> 更多

集群

> 概述

> 使用方式

| 結(jié)尾

趣談