Redis的這些拓展方案
前言
Redis大家都不陌生，就算是沒用過，也都聽說過了。
作為最廣泛使用的KV內(nèi)存數(shù)據(jù)庫之一，在當(dāng)今的大流量時代，單機(jī)模式略顯單薄，免不了要有一些拓展的方案。
筆者下文會對各種方案進(jìn)行介紹，并且給出場景，實現(xiàn) 等等概述，還會提到一些新手常見的誤區(qū)。
正文
先從基礎(chǔ)的拓展方式開始，這樣更便于理解較高級的模式。
ps: 本文背景是以筆者落筆時官網(wǎng)最新穩(wěn)定版5.0.8為準(zhǔn)，雖然還沒寫完就變成了6.0.1。
分區(qū)
概述
分區(qū)(Partitioning)是一種最為簡單的拓展方式。
在我們面臨單機(jī)的存儲空間瓶頸時，第一點就能想到像傳統(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實例中，每個實例不需要關(guān)聯(lián)，可以是完全獨立的。
使用方式
客戶端處理 和傳統(tǒng)的數(shù)據(jù)庫分庫分表一樣，可以從key入手，先進(jìn)行計算，找到對應(yīng)數(shù)據(jù)存儲的實例在進(jìn)行操作。范圍角度，比如orderId:1~orderId:1000放入實例1，orderId:1001~orderId:2000放入實例2...哈希計算，就像我們的hashmap一樣，用hash函數(shù)加上位運算或者取模，高級玩法還有[一致性Hash]等操作，找到對應(yīng)的實例進(jìn)行操作 使用代理中間件 我們可以開發(fā)獨立的代理中間件，屏蔽掉處理數(shù)據(jù)分片的邏輯，獨立運行。當(dāng)然也有他人已經(jīng)造好的輪子，Redis也有優(yōu)秀的代理中間件，譬如[Twemproxy]，或者[codis]，可以結(jié)合場景選擇是否使用。
缺點
無緣多key操作，key都不一定在一個實例上，那么多key操作或者多key事務(wù)自然是不支持。 維護(hù)成本，由于每個實例在物理和邏輯上，都屬于單獨的一個節(jié)點，缺乏統(tǒng)一管理。 靈活性有限，范圍分片還好，比如hash+MOD這種方式，如果想動態(tài)調(diào)整Redis實例的數(shù)量，就要考慮大量數(shù)據(jù)遷移，這就非常麻煩了。
同為開發(fā)者，深知我們雖然總能“曲線救國”的完成一些當(dāng)前環(huán)境不支持的功能，但是總歸要麻煩一些。
主從
概述數(shù)據(jù)遷移
常說的主從(Master-Slave)，也就是復(fù)制(Replication)方式，怎么稱呼都可以。
同上面的分區(qū)一樣，也是Redis高可用架構(gòu)的基礎(chǔ)，新手可能會誤以為這類基礎(chǔ)模式即是“高可用”，這并不是十分正確的。
分區(qū)暫時能解決單點無法容納的數(shù)據(jù)量問題，但是一個Key還是只在一個實例上，在大流量時代顯得不那么可靠。
主從就是另一個緯度的拓展，節(jié)點將數(shù)據(jù)同步到從節(jié)點，就像將實例“分身”了一樣，可靠性又提高了不少。
圖畫的有些夸張了，主要還是想體現(xiàn)結(jié)構(gòu)靈活，是一主一從，還是一主多從，還是一主多從多從... 看你心情
有了“實例分身”，自然就可以做讀寫分離，將讀流量均攤在各個從節(jié)點。
使用方式
高手云集的時代，聊天軟件難免要備上這么一張表情包。
這表情包和使用方式有什么關(guān)系呢？首先看看使用方式：
作為主節(jié)點的Redis實例，并不要求配置任何參數(shù)，只需要正常啟動 作為從節(jié)點的實例，使用配置文件或命令方式 REPLICAOF 主節(jié)點Host 主節(jié)點port即可完成主從配置
是不是和表情包一樣，“dalao”沒動，我去“抱大腿”。
這樣一個主從最小配置就完成了，主從實例即可對外提供服務(wù)。
命令里的“主節(jié)點”是相對的，slave也可以抱slave大腿，也就是上文提到的結(jié)構(gòu)靈活。
缺點
slave節(jié)點都是只讀的，如果寫流量大的場景，就有些力不從心了。那我把slave節(jié)點只讀關(guān)掉不就行了？當(dāng)然不行，數(shù)據(jù)復(fù)制是由主到從，從節(jié)點獨有數(shù)據(jù)同步不到主節(jié)點，數(shù)據(jù)就不一致了。 故障轉(zhuǎn)移不友好，主節(jié)點掛掉后，寫處理就無處安放，需要手工的設(shè)定新的主節(jié)點，如使用 REPLICAOF no one(誰大腿我都不抱了) 晉升為主節(jié)點，再梳理其他slave節(jié)點的新主配置，相對來說比較麻煩。
哨兵
概述
主從的手工故障轉(zhuǎn)移，肯定讓人很難接受，自然就出現(xiàn)了高可用方案-哨兵（Sentinel）。
我們可以在主從架構(gòu)不變的場景，直接加入Redis Sentinel，對節(jié)點進(jìn)行監(jiān)控，來完成自動的故障發(fā)現(xiàn)與轉(zhuǎn)移。
并且還能夠充當(dāng)配置提供者，提供主節(jié)點的信息，就算發(fā)生了故障轉(zhuǎn)移，也能提供正確的地址。
哨兵本身也是Redis實例的一種，但不作為數(shù)據(jù)存儲方使用，啟動命令也是不一樣的。
雖然圖有些復(fù)雜，看起來像要召喚光能使者。
其實實際使用起來是很便捷的。
使用方式
Sentinel的最小配置，一行即可：
sentinel monitor <主節(jié)點別名> <主節(jié)點host> <主節(jié)點端口> <票數(shù)>
只需要配置master即可，然后用redis-sentinel <配置文件> 命令即可啟用。
Redis官網(wǎng)提到的“最小配置”是如下所示，除了上面提到的一行，還有其它的一些配置：
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
復(fù)制代碼
這是因為官網(wǎng)加了一個修飾詞，是“典型的最小配置”，把重要參數(shù)和多主的例子都寫出來了，照顧大家CV大法的時候，不要忘記重要參數(shù)，其實都是有默認(rèn)值的。
正如該例所示，設(shè)置主節(jié)點別名就是為了監(jiān)控多主的時候，與其額外配置項能夠與其對應(yīng), 以及sentinel一些命令，如SENTINEL get-master-addr-by-name就要用到別名了。
哨兵數(shù)量建議在三個以上且為奇數(shù)，在[Redis官網(wǎng)]也提到了各種情況的“布陣”方式，非常值得參考。
更多
既然是高可用方案，并非有嚴(yán)格意義上的“缺點”，還需配合使用場景進(jìn)行考量。
故障轉(zhuǎn)移期間短暫的不可用，但其實官網(wǎng)的例子也給出了 parallel-syncs參數(shù)來指定并行的同步實例數(shù)量，以免全部實例都在同步出現(xiàn)整體不可用的情況，相對來說要比手工的故障轉(zhuǎn)移更加方便。分區(qū)邏輯需要自定義處理，雖然解決了主從下的高可用問題，但是Sentinel并沒有提供分區(qū)解決方案，還需開發(fā)者考慮如何建設(shè)。 既然是還是主從，如果異常的寫流量搞垮了主節(jié)點，那么自動的“故障轉(zhuǎn)移”會不會變成自動“災(zāi)難傳遞”，即slave提升為Master之后掛掉，又進(jìn)行提升又被掛掉。不過最后這點也是筆者猜測，并沒有聽說過出現(xiàn)這種案例，可不必深究。
集群
概述
Redis Cluster是官方在3.0版本后推出的分布式方案。
對開發(fā)者而言，“官方支持”一詞是大概率非常美好的，小到issue，大到feature。自定義去解決問題，成本總是要高一些。
有了官方的正式集群方案，從請求路由、故障轉(zhuǎn)移、彈性伸縮幾個緯度的使用上，將更為容易。
Cluster不同于哨兵，是支持分區(qū)的。有說法Cluster是哨兵的升級，這是不嚴(yán)謹(jǐn)?shù)摹?/p>
二者緯度不一樣，如果因為Cluster也有故障轉(zhuǎn)移的功能，就說它是哨兵的升級款，略顯牽強(qiáng)。
Cluster在分區(qū)管理上，使用了“哈希槽”(hash slot)這么一個概念，一共有16384個槽位，每個實例負(fù)責(zé)一部分槽，通過CRC16（key）&16383這樣的公式，計算出來key所對應(yīng)的槽位。
雖然在節(jié)點和key二者中又引入了槽的概念，看起來不易理解，實際上因為顆粒度更細(xì)了，減少了節(jié)點的擴(kuò)容和收縮難度，相比傳統(tǒng)策略還是很有優(yōu)勢。
當(dāng)然，“槽”是虛擬的概念，節(jié)點自身去維護(hù)“槽”的關(guān)系，并不是要真正下載啟動個“槽服務(wù)”在跑。
使用方式
Redis的各種玩法，都是從配置文件著手，集群也不例外。
cluster-enabled yes
cluster-config-file "redis-node.conf"
復(fù)制代碼
關(guān)鍵配置簡潔明了，有兩步
開啟集群 指定集群配置文件
集群配置文件(cluster-config-file)為內(nèi)部使用，可以不去指定，Redis會幫助創(chuàng)建一個。啟動還是普通的方式redis-server redis.conf
首先以集群方式啟動了N臺Redis實例，這當(dāng)然還沒完事。
接下來的步驟筆者稱為“牽線搭橋分配槽”，聽起來還算順口。
“牽線搭橋分配槽”的方式也在不斷升級，從直接用原始命令來處理，到使用腳本，以及現(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
復(fù)制代碼
上方的命令即是Redis官網(wǎng)給出的redis-cli的方式用法，一行命令完成“三主三從”以及自動分配槽的操作。
這樣集群就搭建完成了，當(dāng)然，使用官方提供的check命令檢查一下，也是有必要的。
redis-cli --cluster check 127.0.0.1:7001
復(fù)制代碼
更多
雖然是對分區(qū)良好支持，但也有一些分區(qū)的老問題，譬如：如果不在同一個“槽”的數(shù)據(jù)，是沒法使用類似mset的多鍵操作。 在[select命令頁]有提到, 集群模式下只能使用一個庫，雖然平時一般也是這么用的，但是要了解一下。 運維上也要謹(jǐn)慎，俗話說得好，“使用越簡單底層越復(fù)雜”，啟動搭建是很方便，使用時面對帶寬消耗，數(shù)據(jù)傾斜等等具體問題時，還需人工介入，或者研究合適的配置參數(shù)。
結(jié)尾
趣談
在寫“主從”方案的時候，發(fā)現(xiàn)有一個有趣的事情：
筆者開始是記得主從的關(guān)鍵命令是SLAVEOF，后來查閱官方的時候，發(fā)現(xiàn)命令已經(jīng)更改為REPLICAOF，雖然SLAVEOF還能用。
官網(wǎng)的一些描述詞匯，有的地方還是Slave，也有些是用Replication。
好奇的筆者查了一下相關(guān)的資料，并看了些Redis作者antirez的有關(guān)此時博客，發(fā)現(xiàn)已經(jīng)是兩年前的事情了。
其實就是“Slave”這個變量名給了一些人機(jī)會，借此“噴”了一波作者，作者也做出了一部分妥協(xié)。
有興趣的盆友可以自己搜搜看，技術(shù)外的東西就不做評價了，看個樂呵就行。
筆者的主要目的還是：看官方文檔的時候，別讓不同的“詞匯”迷惑了。
最近面試BAT，整理一份面試資料《Java面試BATJ通關(guān)手冊》，覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫、數(shù)據(jù)結(jié)構(gòu)等等。
獲取方式：點“在看”，關(guān)注公眾號并回復(fù) Java 領(lǐng)取，更多內(nèi)容陸續(xù)奉上。
文章有幫助的話，在看，轉(zhuǎn)發(fā)吧。
謝謝支持喲 (*^__^*）
