为什么Redis集群有16384个槽(下）

注意看红框的内容，type表示消息类型。 另外，消息头里面有个myslots的char数组，长度为16383/8，这其实是一个bitmap,每一个位代表一个槽，如果该位为1，表示这个槽是属于这个节点的。

到底数据信息究竟多大？ 在消息头中，最占空间的是myslots[CLUSTER_SLOTS/8]。这块的大小是: 16384÷8÷1024=2kb

那在消息体中，会携带一定数量的其他节点信息用于交换。那这个其他节点的信息，到底是几个节点的信息呢？约为集群总节点数量的1/10，至少携带3个节点的信息。这里的重点是:节点数量越多，消息体内容越大。

消息体大小是10个节点的状态信息约1kb。

那定期的频率是什么样的？ redis集群内节点，每秒都在发ping消息。规律如下 (1)每秒会随机选取5个节点，找出最久没有通信的节点发送ping消息 (2)每100毫秒(1秒10次)都会扫描本地节点列表，如果发现节点最近一次接受pong消息的时间大于cluster-node-timeout/2 则立刻发送ping消息

因此，每秒单节点发出ping消息数量为数量=1+10*num（node.pong_received>cluster_node_timeout/2）

那大致带宽损耗如下所示，图片来自《Redis运维与实现》

讲完基础知识以后，我们可以来看作者的回答了。

回答

(1)如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。如上所述，在消息头中，最占空间的是myslots[CLUSTER_SLOTS/8]。当槽位为65536时，这块的大小是:65536÷8÷1024=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的压缩率就很低。

ps：文件压缩率指的是，文件压缩前后的大小比。

综上所述，作者决定取16384个槽，不多不少，刚刚好！二.正文

基础

我们回忆一下Redis Cluster的工作原理！ 这里要先将节点握手讲清楚。我们让两个redis节点之间进行通信的时候，需要在客户端执行下面一个命令 127.0.0.1:7000>cluster meet 127.0.0.1:7001

如下图所示

意思很简单，让7000节点和7001节点知道彼此存在！ 在握手成功后，连个节点之间会定期发送ping/pong消息，交换数据信息，如下图所示。

在这里，我们需要关注三个重点。 (1)交换什么数据信息 (2)数据信息究竟多大 (3)定期的频率什么样

到底在交换什么数据信息？交换的数据信息，由消息体和消息头组成。消息体无外乎是一些节点标识啊，IP啊，端口号啊，发送时间啊。这与本文关系不是太大，我不细说。我们来看消息头，结构如下

注意看红框的内容，type表示消息类型。 另外，消息头里面有个myslots的char数组，长度为16383/8，这其实是一个bitmap,每一个位代表一个槽，如果该位为1，表示这个槽是属于这个节点的。

到底数据信息究竟多大？ 在消息头中，最占空间的是myslots[CLUSTER_SLOTS/8]。这块的大小是: 16384÷8÷1024=2kb

那在消息体中，会携带一定数量的其他节点信息用于交换。那这个其他节点的信息，到底是几个节点的信息呢？约为集群总节点数量的1/10，至少携带3个节点的信息。这里的重点是:节点数量越多，消息体内容越大。

消息体大小是10个节点的状态信息约1kb。

那定期的频率是什么样的？ redis集群内节点，每秒都在发ping消息。规律如下 (1)每秒会随机选取5个节点，找出最久没有通信的节点发送ping消息 (2)每100毫秒(1秒10次)都会扫描本地节点列表，如果发现节点最近一次接受pong消息的时间大于cluster-node-timeout/2 则立刻发送ping消息

因此，每秒单节点发出ping消息数量为数量=1+10*num（node.pong_received>cluster_node_timeout/2）

那大致带宽损耗如下所示，图片来自《Redis运维与实现》

讲完基础知识以后，我们可以来看作者的回答了。

回答

(1)如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。如上所述，在消息头中，最占空间的是myslots[CLUSTER_SLOTS/8]。当槽位为65536时，这块的大小是:65536÷8÷1024=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的压缩率就很低。

ps：文件压缩率指的是，文件压缩前后的大小比。

综上所述，作者决定取16384个槽，不多不少，刚刚好