为什么Redis集群的最大槽数是16384个？

大家好，我是袁庭新。分享一个经典面试题：为什么Redis集群的最大槽数是16384个？

Redis集群并没有使用一致性hash，而是引入了哈希槽的概念。Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。但为什么哈希槽的数量是16384（2^14）个呢？

CRC16算法产生的hash值有16位（bit），该算法可以产生2^16=65536个值，换句话说值是分布在0~65535之间。明明有更大的65536，为什么不用而用16384呢？也就是说，在HASH_SLOT = CRC16(key) mod 65536为什么没有启用。Redis作者Salvatore Sanfilippo在Github上回答了这个问题（https://github.com/redis/redis/issues/2576）。

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

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

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

typedef struct {
    char sig[4]; /* 信号标示 */
    uint32_t totlen; /* 消息总长度 */
    uint16_t ver; /* 协议版本 */
    uint16_t type; /* 消息类型，用于区分meet、ping、pong等消息 */
    uint16_t count; /* 消息体包含的节点数量，仅用于meet、ping、pong消息类型 */
    uint64_t currentEpoch; /* 当前发送节点的配置纪元 */
    uint64_t configEpoch; /* 主节点/从节点的主节点配置纪元 */
    uint64_t offset; /* 复制偏移量 */
    unsigned char myslots[CLUSTER_SLOTS/8]; /* 发送节点负责的槽信息 */
    char slaveof[CLUSTER_NAMELEN]; /* 如果发送节点是从节点，记录对应主节点的nodeId */
    uint16_t port; /* 端口号 */
    uint16_t flags; /* 发送节点标识，区分主从角色，是否下线等 */
    unsigned char state; /* 发送节点所处的集群状态 */
    unsigned char mflags[3]; /* 消息标识 */
    union clusterMsgData data; /* 消息正文 */
} clusterMsg;

(1) 如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。

在消息头中最占空间的是myslots[CLUSTER_SLOTS/8]，当槽位为65536时，这块的大小是：65536÷8÷1024=8kb。

在消息头中最占空间的是myslotS[CLUSTER_SLOTS/8]，当槽位为16384时，这块的大小是：16384÷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的压缩率就很低。

最后，需要注意的是，Redis集群不保证强一致性，这意味着在特定的条件下，Redis集群可能会丢掉一些被系统收到的写入请求命令。