redis cluster集羣模式總結

Redis集羣介紹

Redis 集羣是一個提供在多個Redis間節點間共享數據的程序集。

Redis集羣並不支持處理多個keys的命令,由於這須要在不一樣的節點間移動數據,從而達不到像Redis那樣的性能,在高負載的狀況下可能會致使不可預料的錯誤.

Redis 集羣經過分區來提供必定程度的可用性,在實際環境中當某個節點宕機或者不可達的狀況下繼續處理命令. Redis 集羣的優點:

• 自動分割數據到不一樣的節點上。
• 整個集羣的部分節點失敗或者不可達的狀況下可以繼續處理命令。

Redis 集羣的數據分片

Redis 集羣沒有使用一致性hash, 而是引入了 哈希槽的概念.

Redis 集羣有16384個哈希槽,每一個key經過CRC16校驗後對16384取模來決定放置哪一個槽.集羣的每一個節點負責一部分hash槽,舉個例子,好比當前集羣有3個節點,那麼:

• 節點 A 包含 0 到 5500號哈希槽.
• 節點 B 包含5501 到 11000 號哈希槽.
• 節點 C 包含11001 到 16384號哈希槽.

這種結構很容易添加或者刪除節點. 好比若是我想新添加個節點D, 我須要從節點 A, B, C中得部分槽到D上. 若是我想移除節點A,須要將A中的槽移到B和C節點上,而後將沒有任何槽的A節點從集羣中移除便可. 因爲從一個節點將哈希槽移動到另外一個節點並不會中止服務,因此不管添加刪除或者改變某個節點的哈希槽的數量都不會形成集羣不可用的狀態.

Redis 集羣的主從複製模型

爲了使在部分節點失敗或者大部分節點沒法通訊的狀況下集羣仍然可用，因此集羣使用了主從複製模型,每一個節點都會有N-1個複製品.

在咱們例子中具備A，B，C三個節點的集羣,在沒有複製模型的狀況下,若是節點B失敗了，那麼整個集羣就會覺得缺乏5501-11000這個範圍的槽而不可用.

然而若是在集羣建立的時候（或者過一段時間）咱們爲每一個節點添加一個從節點A1，B1，C1,那麼整個集羣便有三個master節點和三個slave節點組成，這樣在節點B失敗後，集羣便會選舉B1爲新的主節點繼續服務，整個集羣便不會由於槽找不到而不可用了

不過當B和B1 都失敗後，集羣是不可用的.

Redis 一致性保證

Redis 並不能保證數據的強一致性. 這意味這在實際中集羣在特定的條件下可能會丟失寫操做.

第一個緣由是由於集羣是用了異步複製. 寫操做過程:

• 客戶端向主節點B寫入一條命令.
• 主節點B向客戶端回覆命令狀態.
• 主節點將寫操做複製給他得從節點 B1, B2 和 B3.

主節點對命令的複製工做發生在返回命令回覆以後， 由於若是每次處理命令請求都須要等待複製操做完成的話， 那麼主節點處理命令請求的速度將極大地下降 —— 咱們必須在性能和一致性之間作出權衡。 注意：Redis 集羣可能會在未來提供同步寫的方法。 Redis 集羣另一種可能會丟失命令的狀況是集羣出現了網絡分區， 而且一個客戶端與至少包括一個主節點在內的少數實例被孤立。

舉個例子 假設集羣包含 A 、 B 、 C 、 A1 、 B1 、 C1 六個節點， 其中 A 、B 、C 爲主節點， A1 、B1 、C1 爲A，B，C的從節點， 還有一個客戶端 Z1 假設集羣中發生網絡分區，那麼集羣可能會分爲兩方，大部分的一方包含節點 A 、C 、A1 、B1 和 C1 ，小部分的一方則包含節點 B 和客戶端 Z1 .

Z1仍然可以向主節點B中寫入, 若是網絡分區發生時間較短,那麼集羣將會繼續正常運做,若是分區的時間足夠讓大部分的一方將B1選舉爲新的master，那麼Z1寫入B中得數據便丟失了.

注意， 在網絡分裂出現期間， 客戶端 Z1 能夠向主節點 B 發送寫命令的最大時間是有限制的， 這一時間限制稱爲節點超時時間（node timeout）， 是 Redis 集羣的一個重要的配置選項：

 

集羣在線重配置（live reconfiguration）-動態新增、刪除節點數據一致性保障

Redis 集羣支持在集羣運行過程當中添加或移除節點。實際上，添加或移除節點都被抽象爲同一個操做，那就是把哈希槽從一個節點移到另外一個節點。

• 向集羣添加一個新節點，就是把一個空節點加入到集羣中並把某些哈希槽從已存在的節點移到新節點上。
• 從集羣中移除一個節點，就是把該節點上的哈希槽移到其餘已存在的節點上。
• 因此實現這個的核心是能把哈希槽移來移去。從實際角度看，哈希槽就只是一堆鍵，因此 Redis 集羣在重組碎片（reshard）時作的就是把鍵從一個節點移到另外一個節點。

爲了理解這是怎麼工做的，咱們須要介紹 CLUSTER 的子命令，這些命令是用來操做 Redis 集羣節點上的哈希槽轉換表（slots translation table）。

如下是可用的子命令：

• CLUSTER ADDSLOTS slot1 [slot2] … [slotN]
• CLUSTER DELSLOTS slot1 [slot2] … [slotN]
• CLUSTER SETSLOT slot NODE node
• CLUSTER SETSLOT slot MIGRATING node
• CLUSTER SETSLOT slot IMPORTING node
• 頭兩個命令，ADDSLOTS 和 DELSLOTS，就是簡單地用來給一個 Redis 節點指派（assign）或移除哈希槽。 在哈希槽被指派後，節點會將這個消息經過 gossip 協議向整個集羣傳播。ADDSLOTS 命令一般是用於在一個集羣剛創建的時候快速給全部節點指派哈希槽。

當 SETSLOT 子命令使用 NODE 形式的時候，用來給指定 ID 的節點指派哈希槽。 除此以外哈希槽能經過兩個特殊的狀態來設定，MIGRATING 和 IMPORTING：

• 當一個槽被設置爲 MIGRATING，原來持有該哈希槽的節點仍會接受全部跟這個哈希槽有關的請求，但只有當查詢的鍵還存在原節點時，原節點會處理該請求，不然這個查詢會經過一個 -ASK 重定向（-ASK redirection）轉發到遷移的目標節點。
• 當一個槽被設置爲 IMPORTING，只有在接受到 ASKING 命令以後節點纔會接受全部查詢這個哈希槽的請求。若是客戶端一直沒有發送 ASKING 命令，那麼查詢都會經過 -MOVED 重定向錯誤轉發到真正處理這個哈希槽的節點那裏。

這麼講可能顯得有點奇怪，如今咱們用實例讓它更清晰些。假設咱們有兩個 Redis 節點，稱爲 A 和 B。咱們想要把哈希槽 8 從 節點A 移到 節點B，因此咱們發送了這樣的命令：

• 咱們向 節點B 發送：CLUSTER SETSLOT 8 IMPORTING A
• 咱們向 節點A 發送：CLUSTER SETSLOT 8 MIGRATING B

其餘全部節點在每次被詢問到的一個鍵是屬於哈希槽 8 的時候，都會把客戶端引向節點」A」。具體以下：

• 全部關於已存在的鍵的查詢都由節點」A」處理。
• 全部關於不存在於節點 A 的鍵都由節點」B」處理。

這種方式讓咱們能夠不用在節點 A 中建立新的鍵。同時，一個叫作 redis-trib 的特殊客戶端，它也是 Redis 集羣的配置程序（configuration utility），會確保把已存在的鍵從節點 A 移到節點 B。這經過如下命令實現：

CLUSTER GETKEYSINSLOT slot count

上面這個命令會返回指定的哈希槽中 count 個鍵。對於每一個返回的鍵，redis-trib 向節點 A 發送一個 MIGRATE 命令，這樣會以原子性的方式（在移動鍵的過程當中兩個節點都被鎖住，以避免出現競爭情況）把指定的鍵從節點 A 移到節點 B。如下是 MIGRATE 的工做原理：

MIGRATE target_host target_port key target_database id timeout

執行 MIGRATE 命令的節點會鏈接到目標節點，把序列化後的 key 發送過去，一旦收到 OK 回覆就會從它本身的數據集中刪除老的 key。因此從一個外部客戶端看來，在某個時間點，一個 key 要不就存在於節點 A 中要不就存在於節點 B 中。

在 Redis 集羣中，不須要指定一個除了 0 號以外的數據庫，但 MIGRATE 命令能用於其餘跟 Redis 集羣無關的的任務，因此它是一個足夠通用的命令。MIGRATE 命令被優化了，使得即便在移動像長列表這樣的複雜鍵仍然能作到快速。 不過當在重配置一個擁有不少鍵且鍵的數據量都很大的集羣的時候，這個過程就並不那麼好了，對於使用數據庫的應用程序來講就會有延時這個限制。

參數文檔：http://www.redis.cn/topics/cluster-spec.html、http://www.redis.cn/topics/cluster-tutorial.html