厲害了!原來Redis是這樣集群的
“Redis用過嗎?”
“用過。”
“能談談對Redis集群的認識嗎?”
“額……”
這是一段真實的面試經歷。
最近，各大互聯網公司都開始了裁員，導致大量互聯網從業人員又開始了艱辛的求職路。老手自不必說，但對于久在項目里但基本只是使用Redis的程序員們來說，估計這問題得難倒一部分人。
Redis集群方式共有三種：主從模式，哨兵模式，cluster(集群)模式。下面我們來一起看卡這三種模式分別是如何工作的吧。
主從模式
主從模式是三種集群方式里最簡單的。它主要是基于Redis的主從復制特性架構的。通常我們會設置一個主節點，N個從節點。
默認情況下，主節點負責處理使用者的IO操作，而從節點則會對主節點的數據進行備份，并且也會對外提供讀操作的處理。這樣做有兩個目的：備份數據，負載均衡。
備份數據
主從模式下，當某一節點損壞時，因為其會將數據備份到其它Redis實例上，這樣做在很大程度上可以恢復丟失的數據。
負載均衡
主從模式下，主節點和從節點是讀寫分離的。使用者不僅可以從主節點上讀取數據，還可以很方便的從從節點上讀取到數據，這在一定程度上緩解了主機的壓力。
當然，從節點也是能夠支持寫入數據的，只不過從從節點寫入的數據不會同步到主節點以及其它的從節點下。
從以上，我們不難看出Redis在主從模式下，必須保證主節點不會宕機——一旦主節點宕機，其它節點不會競爭稱為主節點，此時，Redis將喪失寫的能力。這點在生產環境中，是致命的。所以Redis為我們引入了另一種集群模式——哨兵模式。
哨兵模式
哨兵模式是基于主從模式做的一定變化，它能夠為Redis提供了高可用性。在實際生產中，服務器難免不會遇到一些突發狀況：服務器宕機，停電，硬件損壞等。這些情況一旦發生，其后果往往是不可估量的。而哨兵模式在一定程度上能夠幫我們規避掉這些意外導致的災難性后果。
其實，哨兵模式的核心還是主從復制。只不過相對于主從模式在主節點宕機導致不可寫的情況下，多了一個競選機制——從所有的從節點競選出新的主節點。競選機制的實現，是依賴于在系統中啟動一個sentinel進程。
sentinel特點
- 監控
- 它會監聽主服務器和從服務器之間是否在正常工作。
- 通知
- 它能夠通過API告訴系統管理員或者程序，集群中某個實例出了問題。
- 故障轉移
- 它在主節點出了問題的情況下，會在所有的從節點中競選出一個節點，并將其作為新的主節點。
- 提供主服務器地址
- 它還能夠向使用者提供當前主節點的地址。這在故障轉移后，使用者不用做任何修改就可以知道當前主節點地址。
就sentinel而言，其當然也具備一定集群能力，Redis sentinel本身就是一個分布式系統。但sentinel集群，和其他的集群有點不一樣。sentinel可以通過發布與訂閱來自動發現Redis集群上的其它sentinel。sentinel在發現其它sentinel進程后，會將其放入一個列表中，這個列表存儲了所有已被發現的sentinel。
集群中的所有sentinel不會并發著去對同一個主節點進行故障轉移。故障轉移只會從第一個sentinel開始，當第一個故障轉移失敗后，才會嘗試下一個。當選擇一個從節點作為新的主節點后，故障轉移即成功了(而不會等到所有的從節點配置了新的主節點后)。這過程中，如果重啟了舊的主節點，那么就會出現無主節點的情況，這種情況下，只能重啟集群。
當競選出新的主節點后，被選為新的主節點的從節點的配置信息會被sentinel改寫為舊的主節點的配置信息。完成改寫后，再將新主節點的配置廣播給所有的從節點。
Cluster(集群)模式
Cluster(集群)模式的出現是為了解決Redis單機容量有限的問題的。該種模式會將Redis中數據按照一定規則劃分到多臺機器上。這種模式有兩個特點：
能夠在多個節點之間自動拆分數據集。
當節點的子集遇到故障或無法與群集的其余部分通信時，能夠繼續操作。
Redis集群中有16384個散列槽。而Redis群集中的每個節點只負責哈希槽的一個子集。
例如，您可能擁有一個包含3個節點的集群，其中：
- 節點A包含從0到5500的散列槽。
- 節點B包含從5501到11000的散列槽。
- 節點C包含從11001到16383的散列槽。
這允許使用者輕松添加和刪除集群中的節點。例如，如果我想添加一個新節點D，我需要將一些哈希槽從節點A，B，C移動到D.同樣，如果我想從群集中刪除節點A，我只需移動A服務的哈希槽。到B和C.當節點A為空時，我可以完全從集群中刪除它。
因為將哈希槽從一個節點移動到另一個節點不需要停止操作，添加和刪除節點，或者更改節點所持有的哈希槽的百分比，所以不需要任何停機時間。
