为什么Redis的槽数是16384？
Redis集群并没有使用一致性hash而是引入了哈希槽的概念。
Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置那个槽，集群的每个节点负责一部分哈希槽，但为什么哈希槽的数量是16384(2^14)个呢？
CRC16算法产生的哈希值有16bit，该算法可以产生2^16=65536个值，换句话说值是分布在0~65535之间，有更大的65536不用为什么只用16384呢？
我们看下作者的解释
编辑
The reason is:
- Normal heartbeat packets carry the full configuration of a node, that can be replaced in an idempotent way with the old in order to update an old config. This means they contain the slots configuration for a node, in raw form, that uses 2k of space with16k slots, but would use a prohibitive 8k of space using 65k slots.
- At the same time it is unlikely that Redis Cluster would scale to more than 1000 mater nodes because of other design tradeoffs.
So 16k was in the right range to ensure enough slots per master with a max of 1000 maters, but a small enough number to propagate the slot configuration as a raw bitmap easily. Note that in small clusters the bitmap would be hard to compress because when N is small the bitmap would have slots/N bits set that is a large percentage of bits set.
简单翻译下：
- 正常的心跳数据包带有节点的完整配置，可以用幂等方式用旧的节点替换旧节点，以便更新旧的配置。这意味着它们包含原始节点的插槽配置，该节点使用2k的空间和16k的插槽，但是会使用8k的空间（使用65k的插槽）。
- 同时，由于其他设计折衷，Redis集群不太可能扩展到1000个以上的主节点。
因此16k处于正确的范围内，以确保每个主机具有足够的插槽，最多可容纳1000个矩阵，但数量足够少，可以轻松地将插槽配置作为原始位图传播。请注意，在小型群集中，位图将难以压缩，因为当N较小时，位图将设置的slot/N占设置位的很大百分比。
（1）如果槽位为65536，发送心跳信总的消息头达8k，发送的心跳包过于庞大。
在消息头中最占空间的是myslots[CLUSTER_SL0TS/8]，当槽位为65536时，这块的大小是：65536÷8÷1024=8kb；当槽位为16384时，这块的大小是：6384÷8÷1024=2kb
因为每秒钟，Redis节点需要发送一定数量的ping消息作为心跳包，如果槽位为65536，这个ping消息的消息头太大了，会浪费带宽。
（2）Redis的集群主节点数量基本不可能超过1000个。
集群节点越多，心跳包的消息体内携带的数据越多。如果节点过1000个，也会导致网络拥堵。
因此Redis作者不建议redis cluster节点数量超过1000个，而对于节点数在1000以内的redis cluster集群，16384个槽位够用了，没有必要拓展到65536个。
（3）槽位越小，节点少的情况下，压缩比高，容易传输
Redis主节点的配置信息中它所负责的哈希槽是通过一张bitmap的形式来保存的，在传输过程中会对bitmap进行压缩，但是如果bitmap的填充率slots/N很高的话（N表示节点数），bitmap的压缩率就很低。如果节点数很少，而哈希槽数量很多的话，bitmap的压缩率也会很低。
总结起来就是：适用、小巧、精干
