为什么Redis集群的最大的槽数是16384（2^14 - 1）

背景

Redis集群并没有使用一致性Hash而是引入了哈希槽的概念。Redis集群有16384个哈希槽，每个Key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分Hash槽。
CRC16算法产生的哈希值有16bit，该算法可以产生2¹⁶=65536个值。为什么不对65536取模。

原因

1、

• 正常的心跳数据包带有节点的完整配置，可以用幂等方式用旧的节点替换旧节点，以便更新旧的配置。这意味着它们包含原始节点的插槽配置，该节点使用2k的空间和16k的插槽，但是会使用8k的空间(使用65k的插槽)。同时，由于其他设计折衷，Redis集群不太可能扩展到1000个以上的主节点。因此16k处于正确的范围内，以确保每个主机具有足够的插槽，最多可容纳1000个矩阵，但数量足够少，可以轻松地将插槽配置作为原始位图传播。注意，在小型群集中，位图将难以压缩，因为当N较小时，位图将设置的slot I N位占设置位的很大百分比。
  
• 如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。在消息头中最占空间的是myslots[CLUSTER_ SLOTS/8]。 当槽位为65536时，这块的大小是65536/8/1024=8kb。因为每秒钟，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的压 率就很低。

2、