redis：为什么redis cluster要设计成16384个槽

╰半夏微凉° 2022-09-15 14:54 178阅读 0赞

# 问题 #

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_17_color_FFFFFF_t_70_g_se_x_16]  
对于客户端请求的key，根据公式HASH\_SLOT=CRC16(key) mod 16384，计算出映射到哪个分片上，然后Redis会去相应的节点进行操作！

那大家思考过，为什么有16384个槽么?

ps:CRC16算法产生的hash值有16bit，该算法可以产生2^16-=65536个值。换句话说，值是分布在0~65535之间。那作者在做mod运算的时候，为什么不mod65536，而选择mod16384？

# 准备 #

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

127.0.0.1:7000>cluster meet 127.0.0.1:7001

![在这里插入图片描述][5966bb4b0ce54603aaeda3de758bee87.png]  
意思很简单，让7000节点和7001节点知道彼此存在。在握手成功后，两个节点之间会定期发送ping/pong消息，交换数据信息。如下图：  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_12_color_FFFFFF_t_70_g_se_x_16]  
在这里，我们需要关注三个重点。  
(1)交换什么数据信息  
(2)数据信息究竟多大  
(3)定期的频率什么样

> 交换什么数据信息

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

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_17_color_FFFFFF_t_70_g_se_x_16 1]  
注意看红框的内容，type表示消息类型。另外，消息头里面有mysqlot的char数组，长度为16384/8，这其实是一个bitmap，每一个位代表一个槽，如果该位是1，表示这个槽是属于这个节点的。

> 到底数据信息究竟多大？

在消息头中，最占空间的是myslots\[CLUSTER\_SLOTS/8\]。

这块的大小是: 16384÷8÷1024=2kb

那在消息体重，会携带一定数量的其他节点信息用于交换。那这个其他节点的信息，到底是几个节点的信息呢？

约为集群总节点数量的1/10，至少携带3个节点的信息。这里的重点是：节点数量越多，消息体内容越大。

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

> 那定期的频率是什么样的？

redis集群内的节点，每秒都在发ping消息。规律如下：

*  每秒对随机选取5个节点，找出醉酒没有通信的节点发送ping消息
 *  每100毫秒(1秒10次)都会扫描本地节点列表，如果发现节点最近一次介绍pong消息的时间大于cluster-node-timeout/2 则立刻发送ping消息

因此，每秒单节点发出ping消息数量为 数量=1+10\*num（node.pong\_received>cluster\_node\_timeout/2）

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

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

*  如上所诉，在消息头中，最占空间的是myslots\[CLUSTER\_SLOTS/8\]，当槽位为65538时，这块数据的大小是65536÷8÷1024=8kb，因为每秒钟，redis节点需要发送一定数量的ping消息作为心跳包，如果槽位为65536，这个ping消息的消息头太大了，浪费带宽

1.  redis的集群主节点数量基本不可能超过100个

*  集群节点越多，心跳包的消息体内携带的数据越多
 *  如果节点超过1000个，也会导致网络拥塞
 *  因此redis作者，不建议redis cluster节点数量超过1000个。
 *  那么，对于节点数在1000以内的redis cluster集群，16384个槽位够用了，没有必要拓展到65536个

1.  槽位越小，节点少的情况下，压缩率高

*  redis主节点的配置信息中，它所负责的哈希槽是通过一张bitmap的形式来保存的，在传输过程中，会对bitmap进行压缩
 *  但是如果bitmap的填充率slots / N很高的话(N表示节点数)，bitmap的压缩率就很低。 如果节点数很少，而哈希槽数量很多的话，bitmap的压缩率就很低。
 *  而16384÷8÷1024=2kb，怎么样，神奇不！

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

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_17_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/480d7ac0f9b643bc8a37a80d25d952bd.png
[5966bb4b0ce54603aaeda3de758bee87.png]: /images/20220828/f8c750aa72a146d28d56aa951fa82f76.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_12_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/f34e80ffc7e04023a879adbc2477657c.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_17_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/1416b1c25c274767a5d87afae20aeb47.png