哈希槽分区
哈希槽分区是为了解决一致性哈希算法的数据倾斜问题。
哈希槽实质上就是一个数组，数组 [0, 2^14 - 1]形成的 hash slot空间。
目的是为了解决均匀分配的问题。在数据和节点之间又加入了一层，把这层称之为槽（slot），用于管理数据和节点之间的关系。就相当于节点上放的是槽，槽里面放的是数据。
槽解决的是粒度问题，相当于把粒度变大了，这样便于数据移动。
哈希解决的是映射问题，使用key的哈希值来计算所在的槽，便于数据分配。
一个集群只能有 16394个槽，编号 0 - 16383（2^14 - 1）。这些槽会分配给集群中所有的主节点，分配策略没有要求。可以指定哪些编号的槽分配给哪个主节点，集群会记录节点和槽的对应关系。
解决了节点和槽的关系后，接下来就需要对key求哈希值，然后对16384取余，根据余数决定key落到哪个槽里。
以槽为单位移动数据，因为槽的数目是固定的，处理起来比较容易，这样数据移动问题就解决了。
Redis集群存储策略
Redis集群使用的就是哈希槽。Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置在哪个槽，集群的每个节点负责一部分hash槽。
哈希槽数量16384（2^14）的决定原因：
CRC16算法产生的hash值有 16bit，该算法可以产生 2^16 = 65536个值。但是为了心跳方便和数据传输最大化，槽的数量只能有 2^14个。
如果槽位数量为65535个，那么发送心跳信息的消息头将达到 8k，发送的心跳包过于庞大。在消息头中最占空间的是 myslots[CLUSTER_SLOTS/8]。当槽位为65536时，这块的大小是 ：
每秒中redis节点需要发送一定数量的ping消息作为心跳，如果槽位为65536，那么这个ping消息头就会太大浪费带宽。
redis集群的主节点数量基本不可能超过1000个。集群节点越多，心跳包的消息体内携带的数据越多。如果节点超过1000个，也会导致网络拥堵。因此redis作者不建议redis cluster节点超过1000个。对于节点数在1000以内的redis cluster集群，16384个槽位足够了，没有必要扩展到65536个。
槽位越小，节点少的情况下压缩比越高，容易传输。Redis主节点的配置信息中它锁负责的哈希槽是通过一张bitmap的形式来保存的，在传输过程中会对bitmap进行压缩，但是如果bitmap的填充率 slots / N（N为节点数）很高的话，bitmap的压缩率就很低。如果节点数很少，而哈希槽数很多的话，bitmap的压缩率就很低。
原文：
正常的心跳数据包带有节点的完整配置，使得可以用幂等方式用旧的节点替换旧节点，以便更新旧的配置。这意味着它们包含原始节点的插槽配置，该节点使用 2k 的空间和 16k 的插槽，而不是使用 8k 的空间（使用65k的插槽）。
同时，因为其他设计折衷，Redis集群的主节点不太可能扩展到1000个以上
Redis集群中内置了16384个哈希槽，redis会根据节点数量大致均等的将哈希槽映射到不同的节点。当需要在Redis集群中放置一个Key-Value时，redis先对key使用 CRC16 算法算出一个结果，然后把结果对 16384 取余，这样每个key都会对应一个编号在0-16383之间的哈希槽，也就是映射到某个节点上。
@Test
public void test() {
// import io.lettuce.core.cluster.SlotHash;
System.out.println(SlotHash.getSlot('A')); // 计算结果6373，存入上图的Node2
System.out.println(SlotHash.getSlot('B')); // 计算结果10374，存入上图的Node2
System.out.println(SlotHash.getSlot('C')); // 计算结果14503，存入上图的Node3
System.out.println(SlotHash.getSlot('Hello')); // 计算结果866，存入上图的Node1
}
