| 前言

Redis大家都不陌生，就算是沒用過，也都聽說過了。

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

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

| 正文

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

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

分區(qū)

> 概述

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

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

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

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

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

> 使用方式

• 客戶端處理
  和傳統(tǒng)的數(shù)據(jù)庫分庫分表一樣，可以從key入手，先進(jìn)行計算，找到對應(yīng)數(shù)據(jù)存儲的實(shí)例在進(jìn)行操作。范圍角度，比如orderId:1~orderId:1000放入實(shí)例1，orderId:1001~orderId:2000放入實(shí)例2。
  哈希計算，就像我們的hashmap一樣，用hash函數(shù)加上位運(yùn)算或者取模，高級玩法還有一致性Hash等操作，找到對應(yīng)的實(shí)例進(jìn)行操作

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

> 缺點(diǎn)

• 無緣多key操作，key都不一定在一個實(shí)例上，那么多key操作或者多key事務(wù)自然是不支持。

• 維護(hù)成本，由于每個實(shí)例在物理和邏輯上，都屬于單獨(dú)的一個節(jié)點(diǎn)，缺乏統(tǒng)一管理。

• 靈活性有限，范圍分片還好，比如hash MOD這種方式，如果想動態(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ǔ)，新手可能會誤以為這類基礎(chǔ)模式即是“高可用”，這并不是十分正確的。

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

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

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

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

> 使用方式

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

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

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

是不是和表情包一樣，“dalao”沒動，我去“抱大腿”。

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

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

> 缺點(diǎn)

• slave節(jié)點(diǎn)都是只讀的，如果寫流量大的場景，就有些力不從心了。
  那我把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)的新主配置，相對來說比較麻煩。

哨兵

> 概述

主從的手工故障轉(zhuǎn)移，肯定讓人很難接受，自然就出現(xiàn)了高可用方案-哨兵（Sentinel）。我們可以在主從架構(gòu)不變的場景，直接加入Redis Sentinel，對節(jié)點(diǎn)進(jìn)行監(jiān)控，來完成自動的故障發(fā)現(xiàn)與轉(zhuǎn)移。并且還能夠充當(dāng)配置提供者，提供主節(jié)點(diǎn)的信息，就算發(fā)生了故障轉(zhuǎn)移，也能提供正確的地址。哨兵本身也是Redis實(shí)例的一種，但不作為數(shù)據(jù)存儲方使用，啟動命令也是不一樣的。

雖然圖有些復(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)加了一個修飾詞，是“典型的最小配置”，把重要參數(shù)和多主的例子都寫出來了，照顧大家CV大法的時候，不要忘記重要參數(shù)，其實(shí)都是有默認(rèn)值的。

正如該例所示，設(shè)置主節(jié)點(diǎn)別名就是為了監(jiān)控多主的時候，與其額外配置項(xiàng)能夠與其對應(yīng), 以及sentinel一些命令，如SENTINEL get-master-addr-by-name就要用到別名了。哨兵數(shù)量建議在三個以上且為奇數(shù)，在Redis官網(wǎng)也提到了各種情況的“布陣”方式，非常值得參考。

> 更多

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

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

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

集群

> 概述

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

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

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

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

Cluster在分區(qū)管理上，使用了“哈希槽”(hash slot)這么一個概念，一共有16384個槽位，每個實(shí)例負(fù)責(zé)一部分槽，通過CRC16（key）