一致性哈希和哈希槽
1、集群分片模式
如果 redis 只用復制功能做主從，那么當數據量巨大的情況下，單機情況下可能已經承受不下一份數據，更不用說是主從都要各自保存一份完整的數據。在這種情況下，數據分片是一個非常好的解決辦法。
redis 的 custer 正是用於解決該問題。它主要提供兩個功能：
1、自動對數據分片，落到各個節點上
2、即使集群部分節點失效或者連接不上，依然可以繼續處理命令
對於第二點，它的功能有點類似於 sentienl 的故障轉移，在這里不細說。下面詳細了解下 redis 的槽位分片原理，在此之前，先了解下分布式簡單哈希算法和一致性哈希算法，以幫助理解槽位的作用。
2、簡單哈希算法
假設有三台機，數據落在哪台機的算法為：
c = Hash(key) % 3
例如 key A 的哈希值為4，4 % 3 = 1，則落在第二台機。Key ABC 哈希值為11，11 % 3 = 2，則落在第三台機上。
利用這樣的算法，假設現在數據量太大了，需要增加一台機器。A 原本落在第二台上，現在根據算法4 % 4 = 0，落到了第一台機器上了，但是第一台機器上根本沒有 A 的值。這樣的算法會導致增加機器或減少機器的時候，引起大量的緩存穿透，造成雪崩。
3、一致性哈希算法
在1997年，麻省理工學院的 Karger 等人提出了一致性哈希算法，為的就是解決分布式緩存的問題。
在一致性哈希算法中，整個哈希空間是一個虛擬圓環。
假設有四個節點 Node A、B、C、D，經過 ip 地址的哈希計算，它們的位置如下：
有4個存儲對象 Object A、B、C、D，經過對 Key 的哈希計算后，它們的位置如下：
對於各個 Object，它所真正的存儲位置是按順時針找到的第一個存儲節點。例如 Object A 順時針找到的第一個節點是 Node A，所以 Node A 負責存儲 Object A，Object B 存儲在 Node B。
一致性哈希算法大概如此，那么它的容錯性和擴展性如何呢？
假設 Node C 節點掛掉了，Object C 的存儲丟失，那么它順時針找到的最新節點是 Node D。也就是說 Node C 掛掉了，受影響僅僅包括 Node B 到 Node C 區間的數據，並且這些數據會轉移到 Node D 進行存儲。
同理，假設現在數據量大了，需要增加一台節點 Node X。Node X 的位置在 Node B 到 Node C 直接，那么受到影響的僅僅是 Node B 到 Node X 間的數據，它們要重新落到 Node X 上。
所以一致性哈希算法對於容錯性和擴展性有非常好的支持。但一致性哈希算法也有一個嚴重的問題，就是數據傾斜。
如果在分片的集群中，節點太少，並且分布不均，一致性哈希算法就會出現部分節點數據太多，部分節點數據太少。也就是說無法控制節點存儲數據的分配。如下圖，大部分數據都在 A 上了，B 的數據比較少。
4、哈希槽
redis 集群（cluster）並沒有選用上面一致性哈希，而是采用了哈希槽（slot）的這種概念。主要的原因就是上面所說的，一致性哈希算法對於數據分布、節點位置的控制並不是很友好。
首先哈希槽其實是兩個概念，第一個是哈希算法。redis cluster 的 hash 算法不是簡單的 hash()，而是 crc16 算法，一種校驗算法。另外一個就是槽位的概念，空間分配的規則。其實哈希槽的本質和一致性哈希算法非常相似，不同點就是對於哈希空間的定義。一致性哈希的空間是一個圓環，節點分布是基於圓環的，無法很好的控制數據分布。而 redis cluster 的槽位空間是自定義分配的，類似於 windows 盤分區的概念。這種分區是可以自定義大小，自定義位置的。
redis cluster 包含了16384個哈希槽，每個 key 通過計算后都會落在具體一個槽位上，而這個槽位是屬於哪個存儲節點的，則由用戶自己定義分配。例如機器硬盤小的，可以分配少一點槽位，硬盤大的可以分配多一點。如果節點硬盤都差不多則可以平均分配。所以哈希槽這種概念很好地解決了一致性哈希的弊端。
另外在容錯性和擴展性上，表象與一致性哈希一樣，都是對受影響的數據進行轉移。而哈希槽本質上是對槽位的轉移，把故障節點負責的槽位轉移到其他正常的節點上。擴展節點也是一樣，把其他節點上的槽位轉移到新的節點上。
但一定要注意的是，對於槽位的轉移和分派，redis 集群是不會自動進行的，而是需要人工配置的。所以 redis 集群的高可用是依賴於節點的主從復制與主從間的自動故障轉移。
