redis 3.0 cluster 叢集 學習之路篇 [1]

標籤：redis 3.0 叢集

周氏一族，整理技術文檔，給下一代留點教程......

目前，項目用的redis主備，感覺超不爽，很多局限性，特別是在 redis master 宕機之後，維護非常麻煩，尋思著弄一個redis叢集，可不，總算到了今年10.1，redis發布了cluster版本。開啟摸索之路...

很多人，一看到官網有最新的cluster版本，滿懷熱血，第一件事，就是搭建cluster環境，其實，鄙人卻不，還是要從基層走起，先來瞭解一下官方資訊，整理成下面的，大部分都是根據網路上整理出來的，又存在相同，純屬借鑒，往見諒！！！

redis主備面臨的問題需求

1、主備模式，過於單一，特別是主伺服器宕機的情況下，資料沒法寫入。

2、業務發展，資料龐大，主備必須同步相同資料，對儲存需求較大，有點多餘

3、雖然說有sentinel，但是效率還是非常低

Redis叢集是一個可以在多個 Redis 節點之間進行資料共用的設施。 這一點毫無疑問的！

Redis叢集通過分區來提供一定程度的可用性：即使叢集中有一部分節點失效或者無法進行通訊， 叢集也可以繼續處理命令請求。

Redis 叢集提供了以下兩個好處：

（1）將資料自動切分（split）到多個節點的能力。

           面臨大資料時代，叢集，就是得要能實現一台宕機，不影響整個叢集運作，換句話說，資料得每台機器都必須擁有對方的data，但是這樣由於業務的慢慢擴充，資料會原來越大，很明顯對儲存比較吃力。redis在這一點上面，做得比較完美，那就是"切片"。通過內部 “私人演算法技術”，把data分布式儲存到叢集機器，當要讀取資料時，再通過 “私人內部演算法” 映射到對應機器讀取。

（2）當叢集中的一部分節點失效或者無法進行通訊時， 仍然可以繼續處理命令請求的能力。

          因為在3.0版本當中，redis採用master n-1 salver的模式，也就是說，一台master主，就若干台備，甚至沒有備也行，但是本人強烈建議要1:1的模式，條件允許的情況下，建議1:n的模式

2、叢集的資料分區功能：

叢集要實現的目的是要將不同的 key 分散放置到不同的 redis 節點，這裡我們需要一個規則或者演算法，通常的做法是擷取 key 的雜湊值，然後根據節點數來求模，但這種做法有其明顯的弊端，當我們需要增加或減少一個節點時，會造成大量的 key 無法命中，這種比例是相當高的，所以就有人提出了一致性雜湊的概念。

一致性雜湊有四個重要特徵：

均衡性：也有人把它定義為平衡性，是指雜湊的結果能夠儘可能分布到所有的節點中去，這樣可以有效利用每個節點上的資源。

單調性：對於單調性有很多翻譯讓我非常的不解，而我想要的是當節點數量變化時雜湊的結果應儘可能的保護已指派的內容不會被重新指派到新的節點。

分散性和負載：這兩個其實是差不多的意思，就是要求一致性雜湊演算法對 key 雜湊應儘可能的避免重複。

但是：

Redis 叢集沒有使用一致性hash, 而是引入了雜湊槽的概念。

Redis 叢集有16384個雜湊槽,每個key通過CRC16校正後對16384模數來決定放置哪個槽.叢集的每個節點負責一部分hash槽。這種結構很容易添加或者刪除節點，並且無論是添加刪除或者修改某一個節點，都不會造成叢集停用狀態。

使用雜湊槽的好處就在於可以方便的添加或移除節點。

當需要增加節點時，只需要把其他節點的某些雜湊槽挪到新節點就可以了；

當需要移除節點時，只需要把移除節點上的雜湊槽挪到其他節點就行了；

在這一點上，我們以後新增或移除節點的時候不用先停掉所有的 redis 服務，very good的

3、Redis叢集的主從架構：

為了使在部分節點失敗或者大部分節點無法通訊的情況下叢集仍然可用，所以叢集使用了主從複製模型,每個節點都會有N-1個複製品。

例如有A，B，C三個節點的叢集,在沒有複製模型的情況下,如果節點B失敗了，那麼整個叢集就會以為缺少B節點所承擔的雜湊槽這個範圍的槽而不可用。

然而如果在叢集建立的時候（或者過一段時間）我們為每個節點添加一個從節點A1，B1，C1,那麼整個叢集便有三個master節點和三個slave節點群組成，這樣在節點B失敗後，叢集便會選舉B1為新的主節點繼續服務，整個叢集便不會因為槽找不到而不可用了。當然如果B和B1都down了，那叢集還是停用，不過這種情況微乎其妙，基本不用考慮，出發你交換器掛了吧，或者機房斷電。

4、redis架構圖

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M00/4B/72/wKiom1Qsx06wtVlXAAGEwXnBz08131.jpg" title="134caad7-0591-3edd-9162-6ae43d068333.jpg" alt="wKiom1Qsx06wtVlXAAGEwXnBz08131.jpg" />

架構細節:

(1)所有的redis節點彼此互聯(PING-PONG機制),內部使用二進位協議最佳化傳輸速度和頻寬.

(2)節點的fail是通過叢集中超過半數的節點檢測失效時才生效.

(3)用戶端與redis節點直連,不需要中間proxy層.用戶端不需要串連叢集所有節點,串連叢集中任何一個可用節點即可

(4)redis-cluster把所有的物理節點映射到[0-16383]slot上,cluster 負責維護node<->slot<->value

5、redis-cluster選舉:容錯

650) this.width=650;" src="http://s3.51cto.com/wyfs02/M01/4B/74/wKioL1Qsx8uwkQU2AAEcQpIDk1E403.jpg" title="2bba02ae-da6c-3747-987d-6a4a3851ec6f.jpg" alt="wKioL1Qsx8uwkQU2AAEcQpIDk1E403.jpg" />

(1)領著選舉過程是叢集中所有master參與,如果半數以上master節點與master節點通訊超過(cluster-node-timeout),認為當前master節點掛掉.

(2):什麼時候整個叢集不可用(cluster_state:fail),當叢集不可用時,所有對叢集的操作做都不可用，收到((error) CLUSTERDOWN The cluster is down)錯誤

    a:如果叢集任意master掛掉,且當前master沒有slave.叢集進入fail狀態,也可以理解成進群的slot映射[0-16383]不完成時進入fail狀態.

    b:如果進群超過半數以上master掛掉，無論是否有slave叢集進入fail狀態

本文出自 “周氏一族” 部落格，謝絕轉載！

redis 3.0 cluster 叢集 學習之路篇 [1]