數據分佈理論
分佈式數據庫首先要解決把整個數據集按照分區規則映射到多個節點的問題，即把數據集劃分到多個節點上，每個節點負責整體數據的一個子集。
需要重點關注的是數據分區規則.常見的分區規則有哈希分區和順序分區兩種:
Redis Cluster採用哈希分區規則，這裏我們重點討論哈希分區，常見的哈希分區規則有幾種
1.節點取餘分區
使用特定的數據，如Redis的鍵或用戶ID，再根據節點數量N使用公式：hash（key）%N計算出哈希值，用來決定數據映射到哪一個節點上。這種方案存在一個問題：當節點數量變化時，如擴容或收縮節點，數據節點映射關係需要重新計算，會導致數據的重新遷移。這種方式的突出優點是簡單性，常用於數據庫的分庫分表規則，一般採用預分區的方式，提前根據數據量規劃好分區數，比如劃分爲512或1024張表，保證可支撐未來一段時間的數據量，再根據負載情況將表遷移到其他數據庫中。擴容時通常採用翻倍擴容，避免數據映射全部被打亂導致全量遷移的情況
2.一致性哈希分區
一致性哈希分區（Distributed Hash Table）實現思路是爲系統中每個節點分配一個token，範圍一般在0~232，這些token構成一個哈希環。數據讀寫執行節點查找操作時，先根據key計算hash值，然後順時針找到第一個大於等於該哈希值的token節點，
這種方式相比節點取餘最大的好處在於加入和刪除節點隻影響哈希環中相鄰的節點，對其他節點無影響。但一致性哈希分區存在幾個問題：
·加減節點會造成哈希環中部分數據無法命中，需要手動處理或者忽略這部分數據，因此一致性哈希常用於緩存場景。
·當使用少量節點時，節點變化將大範圍影響哈希環中數據映射，因此這種方式不適合少量數據節點的分佈式方案。
·普通的一致性哈希分區在增減節點時需要增加一倍或減去一半節點才能保證數據和負載的均衡。
正因爲一致性哈希分區的這些缺點，一些分佈式系統採用虛擬槽對一致性哈希進行改進，比如Dynamo系統。
3.虛擬槽分區
虛擬槽分區巧妙地使用了哈希空間，使用分散度良好的哈希函數把所有數據映射到一個固定範圍的整數集合中，整數定義爲槽（slot）。這個範圍一般遠遠大於節點數，比如Redis Cluster槽範圍是0~16383。槽是集羣內數據管理和遷移的基本單位。採用大範圍槽的主要目的是爲了方便數據拆分和集羣擴展。每個節點會負責一定數量的槽
當前集羣有5個節點，每個節點平均大約負責3276個槽。由於採用高質量的哈希算法，每個槽所映射的數據通常比較均勻，將數據平均劃分到5個節點進行數據分區。Redis Cluster就是採用虛擬槽分區，下面就介紹Redis數據分區方法。
Redis數據分區
Redis Cluser採用虛擬槽分區，所有的鍵根據哈希函數映射到0~16383整數槽內，計算公式：slot=CRC16（key）&16383。每一個節點負責維護一部分槽以及槽所映射的鍵值數據
Redis虛擬槽分區的特點：
·解耦數據和節點之間的關係，簡化了節點擴容和收縮難度。
·節點自身維護槽的映射關係，不需要客戶端或者代理服務維護槽分區元數據。
·支持節點、槽、鍵之間的映射查詢，用於數據路由、在線伸縮等場景。
數據分區是分佈式存儲的核心，理解和靈活運用數據分區規則對於掌握Redis Cluster非常有幫助。
集羣功能限制
Redis集羣相對單機在功能上存在一些限制，需要開發人員提前瞭解，在使用時做好規避,限制如下
1）key批量操作支持有限。如mset、mget，目前只支持具有相同slot值的key執行批量操作。對於映射爲不同slot值的key由於執行mget、mget等操作可能存在於多個節點上因此不被支持。
2）key事務操作支持有限。同理只支持多key在同一節點上的事務操作，當多個key分佈在不同的節點上時無法使用事務功能。
3）key作爲數據分區的最小粒度，因此不能將一個大的鍵值對象如hash、list等映射到不同的節點。
4）不支持多數據庫空間。單機下的Redis可以支持16個數據庫，集羣模式下只能使用一個數據庫空間，即db0。
5）複製結構只支持一層，從節點只能複製主節點，不支持嵌套樹狀複製結構。