在實際應用 Redis 時，隨著用戶或業務規模的擴展，保存大量數據的情況通常是無法避免的。而切片集群，就是一個非常好的解決方案。切片集群，也叫分片集群，就是指啟動多個 Redis 實例組成一個集群，然后按照一定的規則，把收到的數據劃分成多份，每一份用一個實例來保存。

如何保存更多數據？

Redis 應對數據量增多的兩種方案分別為：縱向擴展（scale up）和橫向擴展（scale out）。

• 縱向擴展：升級單個 Redis 實例的資源配置，包括增加內存容量、增加磁盤容量、使用更高配置的 CPU。
• 橫向擴展：橫向增加當前 Redis 實例的個數。

縱向擴展

優點：

• 實施起來簡單、直接。

缺點：

• 當使用 RDB 對數據進行持久化時，如果數據量增加，需要的內存也會增加，主線程 fork 子進程時就可能會阻塞。
• 會受到硬件和成本的限制。

橫向擴展

優點：

• 擴展性更好。要想保存更多的數據，采用這種方案的話，只用增加 Redis 的實例個數就行了，不用擔心單個實例的硬件和成本限制。

缺點：

• 切片集群涉及到多個實例的分布式管理問題。

數據切片和實例如何對應？

Redis Cluster 方案采用哈希槽（Hash Slot，接下來我會直接稱之為 Slot），來處理數據和實例之間的映射關系。在 Redis Cluster 方案中，一個切片集群共有 16384 個哈希槽，這些哈希槽類似于數據分區，每個鍵值對都會根據它的 key，被映射到一個哈希槽中。具體的映射過程分為兩大步：首先根據鍵值對的 key，按照CRC16 算法計算一個 16 bit 的值；然后，再用這個 16bit 值對 16384 取模，得到 0~16383 范圍內的模數，每個模數代表一個相應編號的哈希槽。

那么，這些哈希槽又是如何被映射到具體的 Redis 實例上的呢？我們在部署 Redis Cluster 方案時，可以使用 cluster create 命令創建集群，此時，Redis 會自動把這些槽平均分布在集群實例上。例如，如果集群中有 N 個實例，那么，每個實例上的槽個數為 16384/N 個。當然， 我們也可以使用 cluster meet 命令手動建立實例間的連接，形成集群，再使用 cluster addslots 命令，指定每個實例上的哈希槽個數。

（注意：在手動分配哈希槽時，需要把 16384 個槽都分配完，否則 Redis 集群無法正常工作。）

Redis Cluster為什么不把key直接映射到實例？

Redis Cluster 方案是通過哈希槽的方式把鍵值對分配到不同的實例上，這個過程需要對鍵值對的 key 做 CRC 計算，然后再和哈希槽做映射，從而實現和實例的對應。其原因包括如下：

1、整個集群存儲key的數量是無法預估的，key的數量非常多時，直接記錄每個key對應的實例映射關系，這個映射表會非常龐大，這個映射表無論是存儲在服務端還是客戶端都占用了非常大的內存空間。

2、Redis Cluster采用無中心化的模式（無proxy，客戶端與服務端直連），客戶端在某個節點訪問一個key，如果這個key不在這個節點上，這個節點需要有糾正客戶端路由到正確節點的能力（MOVED響應），這就需要節點之間互相交換路由表，每個節點擁有整個集群完整的路由關系。如果存儲的都是key與實例的對應關系，節點之間交換信息也會變得非常龐大，消耗過多的網絡資源，而且就算交換完成，相當于每個節點都需要額外存儲其他節點的路由表，內存占用過大造成資源浪費。

3、當集群在擴容、縮容、數據均衡時，節點之間會發生數據遷移，遷移時需要修改每個key的映射關系，維護成本高。 而在中間增加一層哈希槽，可以把數據和節點解耦，key通過Hash計算，只需要關心映射到了哪個哈希槽，然后再通過哈希槽和節點的映射表找到節點，相當于消耗了很少的CPU資源，不但讓數據分布更均勻，還可以讓這個映射表變得很小，利于客戶端和服務端保存，節點之間交換信息時也變得輕量。

4、當集群在擴容、縮容、數據均衡時，節點之間的操作例如數據遷移，都以哈希槽為基本單位進行操作，簡化了節點擴容、縮容的難度，便于集群的維護和管理。