[[329400]]

 “Redis用過嗎?”

“用過。”

“能談?wù)剬edis集群的認(rèn)識嗎?”

“額……”

這是一段真實(shí)的面試經(jīng)歷。

最近，各大互聯(lián)網(wǎng)公司都開始了裁員，導(dǎo)致大量互聯(lián)網(wǎng)從業(yè)人員又開始了艱辛的求職路。老手自不必說，但對于久在項(xiàng)目里但基本只是使用Redis的程序員們來說，估計(jì)這問題得難倒一部分人。

Redis集群方式共有三種：主從模式，哨兵模式，cluster(集群)模式。下面我們來一起看卡這三種模式分別是如何工作的吧。

主從模式

主從模式是三種集群方式里最簡單的。它主要是基于Redis的主從復(fù)制特性架構(gòu)的。通常我們會設(shè)置一個(gè)主節(jié)點(diǎn)，N個(gè)從節(jié)點(diǎn)。

默認(rèn)情況下，主節(jié)點(diǎn)負(fù)責(zé)處理使用者的IO操作，而從節(jié)點(diǎn)則會對主節(jié)點(diǎn)的數(shù)據(jù)進(jìn)行備份，并且也會對外提供讀操作的處理。這樣做有兩個(gè)目的：備份數(shù)據(jù)，負(fù)載均衡。

備份數(shù)據(jù)

主從模式下，當(dāng)某一節(jié)點(diǎn)損壞時(shí)，因?yàn)槠鋾?shù)據(jù)備份到其它Redis實(shí)例上，這樣做在很大程度上可以恢復(fù)丟失的數(shù)據(jù)。

負(fù)載均衡

主從模式下，主節(jié)點(diǎn)和從節(jié)點(diǎn)是讀寫分離的。使用者不僅可以從主節(jié)點(diǎn)上讀取數(shù)據(jù)，還可以很方便的從從節(jié)點(diǎn)上讀取到數(shù)據(jù)，這在一定程度上緩解了主機(jī)的壓力。

當(dāng)然，從節(jié)點(diǎn)也是能夠支持寫入數(shù)據(jù)的，只不過從從節(jié)點(diǎn)寫入的數(shù)據(jù)不會同步到主節(jié)點(diǎn)以及其它的從節(jié)點(diǎn)下。

從以上，我們不難看出Redis在主從模式下，必須保證主節(jié)點(diǎn)不會宕機(jī)——一旦主節(jié)點(diǎn)宕機(jī)，其它節(jié)點(diǎn)不會競爭稱為主節(jié)點(diǎn)，此時(shí)，Redis將喪失寫的能力。這點(diǎn)在生產(chǎn)環(huán)境中，是致命的。所以Redis為我們引入了另一種集群模式——哨兵模式。

哨兵模式

哨兵模式是基于主從模式做的一定變化，它能夠?yàn)镽edis提供了高可用性。在實(shí)際生產(chǎn)中，服務(wù)器難免不會遇到一些突發(fā)狀況：服務(wù)器宕機(jī)，停電，硬件損壞等。這些情況一旦發(fā)生，其后果往往是不可估量的。而哨兵模式在一定程度上能夠幫我們規(guī)避掉這些意外導(dǎo)致的災(zāi)難性后果。

其實(shí)，哨兵模式的核心還是主從復(fù)制。只不過相對于主從模式在主節(jié)點(diǎn)宕機(jī)導(dǎo)致不可寫的情況下，多了一個(gè)競選機(jī)制——從所有的從節(jié)點(diǎn)競選出新的主節(jié)點(diǎn)。競選機(jī)制的實(shí)現(xiàn)，是依賴于在系統(tǒng)中啟動一個(gè)sentinel進(jìn)程。

sentinel特點(diǎn)

1. 監(jiān)控
2. 它會監(jiān)聽主服務(wù)器和從服務(wù)器之間是否在正常工作。
3. 通知
4. 它能夠通過API告訴系統(tǒng)管理員或者程序，集群中某個(gè)實(shí)例出了問題。
5. 故障轉(zhuǎn)移
6. 它在主節(jié)點(diǎn)出了問題的情況下，會在所有的從節(jié)點(diǎn)中競選出一個(gè)節(jié)點(diǎn)，并將其作為新的主節(jié)點(diǎn)。
7. 提供主服務(wù)器地址
8. 它還能夠向使用者提供當(dāng)前主節(jié)點(diǎn)的地址。這在故障轉(zhuǎn)移后，使用者不用做任何修改就可以知道當(dāng)前主節(jié)點(diǎn)地址。

就sentinel而言，其當(dāng)然也具備一定集群能力，Redis sentinel本身就是一個(gè)分布式系統(tǒng)。但sentinel集群，和其他的集群有點(diǎn)不一樣。sentinel可以通過發(fā)布與訂閱來自動發(fā)現(xiàn)Redis集群上的其它sentinel。sentinel在發(fā)現(xiàn)其它sentinel進(jìn)程后，會將其放入一個(gè)列表中，這個(gè)列表存儲了所有已被發(fā)現(xiàn)的sentinel。

集群中的所有sentinel不會并發(fā)著去對同一個(gè)主節(jié)點(diǎn)進(jìn)行故障轉(zhuǎn)移。故障轉(zhuǎn)移只會從第一個(gè)sentinel開始，當(dāng)?shù)谝粋€(gè)故障轉(zhuǎn)移失敗后，才會嘗試下一個(gè)。當(dāng)選擇一個(gè)從節(jié)點(diǎn)作為新的主節(jié)點(diǎn)后，故障轉(zhuǎn)移即成功了(而不會等到所有的從節(jié)點(diǎn)配置了新的主節(jié)點(diǎn)后)。這過程中，如果重啟了舊的主節(jié)點(diǎn)，那么就會出現(xiàn)無主節(jié)點(diǎn)的情況，這種情況下，只能重啟集群。

當(dāng)競選出新的主節(jié)點(diǎn)后，被選為新的主節(jié)點(diǎn)的從節(jié)點(diǎn)的配置信息會被sentinel改寫為舊的主節(jié)點(diǎn)的配置信息。完成改寫后，再將新主節(jié)點(diǎn)的配置廣播給所有的從節(jié)點(diǎn)。

Cluster(集群)模式

Cluster(集群)模式的出現(xiàn)是為了解決Redis單機(jī)容量有限的問題的。該種模式會將Redis中數(shù)據(jù)按照一定規(guī)則劃分到多臺機(jī)器上。這種模式有兩個(gè)特點(diǎn)：

能夠在多個(gè)節(jié)點(diǎn)之間自動拆分?jǐn)?shù)據(jù)集。

當(dāng)節(jié)點(diǎn)的子集遇到故障或無法與群集的其余部分通信時(shí)，能夠繼續(xù)操作。

Redis集群中有16384個(gè)散列槽。而Redis群集中的每個(gè)節(jié)點(diǎn)只負(fù)責(zé)哈希槽的一個(gè)子集。

例如，您可能擁有一個(gè)包含3個(gè)節(jié)點(diǎn)的集群，其中：

• 節(jié)點(diǎn)A包含從0到5500的散列槽。
• 節(jié)點(diǎn)B包含從5501到11000的散列槽。
• 節(jié)點(diǎn)C包含從11001到16383的散列槽。

這允許使用者輕松添加和刪除集群中的節(jié)點(diǎn)。例如，如果我想添加一個(gè)新節(jié)點(diǎn)D，我需要將一些哈希槽從節(jié)點(diǎn)A，B，C移動到D.同樣，如果我想從群集中刪除節(jié)點(diǎn)A，我只需移動A服務(wù)的哈希槽。到B和C.當(dāng)節(jié)點(diǎn)A為空時(shí)，我可以完全從集群中刪除它。

因?yàn)閷⒐２蹚囊粋€(gè)節(jié)點(diǎn)移動到另一個(gè)節(jié)點(diǎn)不需要停止操作，添加和刪除節(jié)點(diǎn)，或者更改節(jié)點(diǎn)所持有的哈希槽的百分比，所以不需要任何停機(jī)時(shí)間。