Redis Cluster（Redis 3.X）設計要點

標籤：style   http   io   os   使用   ar   strong   sp   資料   

Redis 3.0.0 RC1版本10.9號發布，Release Note
這個版本支援 Redis Cluster，相信很多同學期待已久，不過這個版本只是RC版本，要應用到生產環境，還得等等

Redis Cluster設計要點：

架構：無中心Redis Cluster採用無中心結構，每個節點都儲存資料和整個叢集的狀態
每個節點都和其他所有節點串連，這些串連保持活躍
使用gossip協議傳播資訊以及發現新節點
node不作為client請求的代理，client根據node返回的錯誤資訊重新導向請求

資料分布：預分桶預分好16384個桶，根據 CRC16(key) mod 16384的值，決定將一個key放到哪個桶中
每個Redis物理結點負責一部分桶的管理，當發生Redis節點的增減時，調整桶的分布即可
例如，假設Redis Cluster三個節點A/B/C，則
Node A 包含桶的編號可以為: 0 到 5500.
Node B 包含桶的編號可以為: 5500 到 11000.
Node C包含桶的編號可以為: 11001 到 16384.
當發生Redis節點的增減時，調整桶的分布即可。
預分桶的方案介於“硬Hash”和“一致性Hash”之間，犧牲了一定的靈活性，但相比“一致性Hash“，資料的管理成本大大降低

可用性：Master-Slave為了保證服務的可用性，Redis Cluster採取的方案是的Master-Slave
每個Redis Node可以有一個或者多個Slave。當Master掛掉時，選舉一個Slave形成新的Master
一個Redis  Node包含一定量的桶，當這些桶對應的Master和Slave都掛掉時，這部分桶對應的資料不可用

寫Redis Cluster使用非同步複製
一個完整的寫操作步驟：
1.client寫資料到master
2.master告訴client "ok"
3.master傳播更新到slave
存在資料丟失的風險：
1. 上述寫步驟1）和2）成功後，master crash，而此時資料還沒有傳播到slave
2. 由於分區導致同時存在兩個master，client向舊的master寫入了資料。
當然，由於Redis Cluster存在逾時及故障恢複機制，第2個風險基本上不可能發生

資料移轉Redis Cluster支援線上增/減節點。
基於桶的資料分布方式大大降低了遷移成本，只需將資料桶從一個Redis Node遷移到另一個Redis Node即可完成遷移。
當桶從一個Node A向另一個Node B遷移時，Node A和Node B都會有這個桶，Node A上桶的狀態設定為MIGRATING，Node B上桶的狀態被設定為IMPORTING
當用戶端請求時：
所有在Node A上的請求都將由A來處理，所有不在A上的key都由Node B來處理。同時，Node A上將不會建立新的key

多key操作當系統從單節點向多節點擴充時，多key的操作總是一個非常難解決的問題，Redis Cluster方案如下：
1. 不支援多key操作
2. 如果一定要使用多key操作，請確保所有的key都在一個node上，具體方法是使用“hash tag”方案
hash tag方案是一種資料分布的例外情況


Reference：
Redis cluster tutorial
Redis cluster Specification

Redis Cluster（Redis 3.X）設計要點