Docker Redis哈希槽分区原理详解

面试题：1~2亿条数据需要缓存，请问如何设计这个存储案例？

--上述问题阿里P6~P7工程案例和场景设计类必考题目，一般业界有3种解决方案（第三种）

（顺序由易到难）

（3）哈希槽分区

1、是什么

（1）为什么出现：

致性哈希算法的数据倾斜问题。

哈希槽实质就是一个数组，数组[0,2^14-1]形成hash slot空间。

（2）能干什么：

解决均匀分配的问题，在数据和节点之问又加入了一层，把这层称为哈希槽(slot)，用于管理数据和节点之间的关系，现在就相当于节点上放的槽，槽里放的是数据。

槽解决的是粒度问题，相当于把粒度变大了，这样便于数据移动。

哈希解决的是映射问题，使用key的哈希值来计算所在的槽，便于数据分配。

（3）多少个hash槽：

1个集群只能有16384个槽，编号0-16383(0-2^14-1)。这些槽公分配给集群中的所有主节点，分配策略没有要求。可以指定哪些编号的槽分配给哪个主节点。集群会记录节点和槽的对应关系。

解决了节点和槽的关系后，接下来就需要对key求哈希值，然后对16384取余，余数是几key就落入对应的槽里slot=CRC16(key)%16384。以槽为单位移动数据，因为槽的数目是固定的，处理起来比较容易，这样数据移动问题就解决了。

（附）为什么redis集群的最大槽数是16384个?（具体见redis）(了解)

Redis集群并没有使用一致性hash而是引入了哈希槽的概念。Redis 集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。

哈希槽的数量是16384(2^14)个，CRC16算法产生的hash值有16bit，该算法可以产生2^16=65536个值。换句话说值是分布在0~65535之间。

做mod运算的时候，为什么不mod65536，而选择mod16384?

（1）说明1：

译文：正常的心跳数据包带有节点的完整配置，可以用幂等方式用旧的节点替换旧节点，以便更新旧的配置。这意味着它们包含原始节点的插槽配置，该节点使用2k的空间和16k的插槽，但是会使用8k的空间(使用65k的插槽)。

同时，由于其他设计折衷，Redis集群不太可能扩展到1000个以上的主节点。

因此16k处于正确的范围内，以确保每个主机具有足够的插槽，最多可容纳1000个矩阵，但数量足够少，可以轻松地将插槽配置作为原始位图传播。请注意，在小型群集中，位图将难以压缩，因为当N较小时，位图将设置的slot/N位占设置位的很大百分比。

（2）说明2：

(a) 如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。在消息头中最占空间的是myslots[CLUSTER_SLOTS/8]。当槽位为65536时，这块的大小是:65536÷8÷1024=8kb因为每秒钟，redis节点需要发送一定数量的ping消息作为心跳包，如果槽位为65536，这个ping消息的消息头太大了，浪费带宽。

(b)redis的集主节点数量基本不可能超过1000个。集群节点越多，心跳包的消息体内携带的数据越多。如果节点过1000个，也会导致网络拥堵。因此redis作者不建议rediscluster节点数量超过1000个。那么，对于节点数在1000以内的redis cluster集群，16384个槽位够用了。没有必要拓展到65536个。

(c)槽位越小，节点少的情况下，压缩比高，容易传输。Redis主节点的配置信息中它所负责的哈希槽是通过一张bitmap的形式米保存的，在传输过程中会对bitmap进行压缩，但是如果bitmap的填充率slots/N很高的话(N表示节数),bitmap的压缩率就很低。如果节点数很少，而哈希槽数量很多的话，bitmap的压缩率就很低。

2哈希槽计算

Redis 集群中内置了16384个哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。

当需要在Redis 集群中放置一个 key-value时redis 先对key使用crc16算法算出一个结果，然后把结果对16384求余数，这样每个key都会对应一个编号在0-16383 之间的哈希槽，也就是映射到某个节点上。