redis-集羣（cluster）掃盲篇（一）

什麼是redis的集羣

按我我的的理解，redis集羣就是實現多個redis節點之間進行數據的共享。

集羣有什麼好處：

• 將數據自動split到多個節點進行存儲。
• 當集羣中的一部分節點失效或者沒法進行通信時， 仍然能夠繼續處理命令請求。

redis集羣的數據共享

redis集羣採用的是數據分片，即sharding，而並非一致性哈希（consistency hash）。

一個redis集羣包含16834個哈希槽（hash slot）數據庫中的每一個鍵都屬於這 16384 個哈希槽的其中一個， 集羣使用公式 CRC16(key) % 16384 來計算鍵 key 屬於哪一個槽， 其中 CRC16(key) 語句用於計算鍵 key 的 CRC16 校驗和 。

集羣中的每一個節點負責處理一部分哈希槽。 舉個例子， 一個集羣能夠有三個哈希槽， 其中：

• 節點 A 負責處理 0 號至 5500 號哈希槽。
• 節點 B 負責處理 5501 號至 11000 號哈希槽。
• 節點 C 負責處理 11001 號至 16384 號哈希槽。

這種將哈希槽分佈到不一樣節點的作法使得用戶能夠很容易地向集羣中添加或者刪除節點。 好比說：

• 若是用戶將新節點 D 添加到集羣中， 那麼集羣只須要將節點 A 、B 、 C 中的某些槽移動到節點 D 就能夠了。
• 與此相似， 若是用戶要從集羣中移除節點 A ， 那麼集羣只須要將節點 A 中的全部哈希槽移動到節點 B 和節點 C ， 而後再移除空白（不包含任何哈希槽）的節點 A 就能夠了。

由於將一個哈希槽從一個節點移動到另外一個節點不會形成節點阻塞， 因此不管是添加新節點仍是移除已存在節點， 又或者改變某個節點包含的哈希槽數量， 都不會形成集羣下線。

Redis 集羣中的主從複製

爲了使得集羣在一部分節點下線或者沒法與集羣的大多數（majority）節點進行通信的狀況下， 仍然能夠正常運做， Redis 集羣對節點使用了主從複製功能： 集羣中的每一個節點都有 1 個至 N 個複製品（replica）， 其中一個複製品爲主節點（master）， 而其他的 N-1 個複製品爲從節點（slave）。

在以前列舉的節點 A 、B 、C 的例子中， 若是節點 B 下線了， 那麼集羣將沒法正常運行， 由於集羣找不到節點來處理 5501 號至 11000 號的哈希槽。

另外一方面， 假如在建立集羣的時候（或者至少在節點 B 下線以前）， 咱們爲主節點 B 添加了從節點 B1 ， 那麼當主節點 B 下線的時候， 集羣就會將 B1 設置爲新的主節點， 並讓它代替下線的主節點 B ， 繼續處理 5501 號至 11000 號的哈希槽， 這樣集羣就不會由於主節點 B 的下線而沒法正常運做了。

不過若是節點 B 和 B1 都下線的話， Redis 集羣仍是會中止運做。

Redis 集羣的一致性保證（guarantee）

Redis 集羣不保證數據的強一致性（strong consistency）： 在特定條件下， Redis 集羣可能會丟失已經被執行過的寫命令。

使用異步複製（asynchronous replication）是 Redis 集羣可能會丟失寫命令的其中一個緣由。 考慮如下這個寫命令的例子：

• 客戶端向主節點 B 發送一條寫命令。
• 主節點 B 執行寫命令，並向客戶端返回命令回覆。
• 主節點 B 將剛剛執行的寫命令複製給它的從節點 B1 、 B2 和 B3 。

如你所見， 主節點對命令的複製工做發生在返回命令回覆以後， 由於若是每次處理命令請求都須要等待複製操做完成的話， 那麼主節點處理命令請求的速度將極大地下降 —— 咱們必須在性能和一致性之間作出權衡。

若是真的有必要的話， Redis 集羣可能會在未來提供同步地（synchronou）執行寫命令的方法。

Redis 集羣另一種可能會丟失命令的狀況是， 集羣出現網絡分裂（network partition）， 而且一個客戶端與至少包括一個主節點在內的少數（minority）實例被孤立。

舉個例子， 假設集羣包含 A 、 B 、 C 、 A1 、 B1 、 C1 六個節點， 其中 A 、B 、C 爲主節點， 而 A1 、B1 、C1 分別爲三個主節點的從節點， 另外還有一個客戶端 Z1 。

假設集羣中發生網絡分裂， 那麼集羣可能會分裂爲兩方， 大多數（majority）的一方包含節點 A 、C 、A1 、B1 和 C1 ， 而少數（minority）的一方則包含節點 B 和客戶端 Z1 。

在網絡分裂期間， 主節點 B 仍然會接受 Z1 發送的寫命令：

• 若是網絡分裂出現的時間很短， 那麼集羣會繼續正常運行；
• 可是， 若是網絡分裂出現的時間足夠長， 使得大多數一方將從節點 B1 設置爲新的主節點， 並使用 B1 來代替原來的主節點 B ， 那麼 Z1 發送給主節點 B 的寫命令將丟失。

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

• 對於大多數一方來講， 若是一個主節點未能在節點超時時間所設定的時限內從新聯繫上集羣， 那麼集羣會將這個主節點視爲下線， 並使用從節點來代替這個主節點繼續工做。
• 對於少數一方， 若是一個主節點未能在節點超時時間所設定的時限內從新聯繫上集羣， 那麼它將中止處理寫命令， 並向客戶端報告錯誤。