为什么RedisCluster会设计成16384个槽?

总结：
槽介绍：
Redis集群通过分片的方式来保存数据库中的键值对：集群的整个数据库被分为16384个槽（slot），
数据库中的每个键都属于这16384个槽的其中一个，集群中的每个节点可以处理0个或最多16384个槽。

为什么RedisCluster会设计成16384个槽?
1、由于redis集群各个节点会定时发送心跳包以确保在线，而如果槽位太多的话，发送的心跳信息就太多了，浪费了带宽。
如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。
在消息头中，最占空间的是 myslots[CLUSTER_SLOTS/8]。当槽位为65536时，这块的大小是: 65536÷8=8kb。
因为每秒钟，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的压缩率就很低。而16384÷8=2kb，怎么样，神奇不！