redis集群值插槽算法灵魂拷问

在redis集群的时候使用的是总共有插槽数16384，会根据key值分配不同的插槽，由此我们产生了一下疑问
1、插槽是什么，为什么要有这个插槽算法
2、为什么插槽只有16384，而不是更多
3、插槽算法的是如何实现的，怎么去验证他啦

为什么要有这个插槽算法

虚拟槽分区是 redis cluster 中默认的数据分布技术，虚拟槽分区巧妙地使用了哈希空间，使用分散度良好的哈希函数把所有数据映射到一个固定范围的整数集合中，这个整数定义为槽(slot)，而且这个槽的个数一般远远的大于节点数。
虚拟槽分区解耦了数据与节点的关系，通过引入槽，让槽成为集群内数据管理和迁移的基本单位，简化了节点扩容和收缩难度，你只需要关注数据在哪个槽，并不需要关心数据在哪个节点上。所以虚拟槽分区可以说比较好的兼容了数据均匀分布和扩展性的问题。

为什么插槽只有16384，而不是更多

这个问题，Redis 官方 Issues 也有朋友提出来过
地址：https://github.com/redis/redis/issues/2576

大神给出的解释是

正常的心跳数据包携带节点的完整配置，它能以幂等方式来更新配置。如果采用 16384 个插槽，占空间 2KB （16384/8）；如果采用 65536 个插槽，占空间 8KB (65536/8)。
Redis Cluster 不太可能扩展到超过 1000 个主节点，太多可能导致网络拥堵。
16384 个插槽范围比较合适，当集群扩展到1000个节点时，也能确保每个master节点有足够的插槽，
8KB 的心跳包看似不大，但是这个是心跳包每秒都要将本节点的信息同步给集群其他节点。比起 16384 个插槽，头大小增加了4倍，ping消息的消息头太大了，浪费带宽。
Redis主节点的哈希槽配置信息是通过 bitmap 来保存的

传输过程中，会对bitmap进行压缩，bitmap的填充率越低，压缩率越高。

bitmap 填充率 = slots / N (N表示节点数)，

所以，插槽数偏低的话， 填充率会降低，压缩率会升高。

综合下来，从心跳包的大小、网络带宽、心跳并发、压缩率等维度考虑，16384 个插槽更有优势且能满足业务需求。

接下来，我们看下master节点间心跳数据包格式：

消息格式分为：消息头和消息体。消息头包含发送节点自身状态数据，接收节点根据消息头就可以获取到发送节点的相关数据，

代码位置：/usr/src/redis/redis-5.0.7/src/cluster.h

其中，消息头有一个myslots的char类型数组，unsigned char myslots[CLUSTER_SLOTS/8];，数组长度为 16384/8 = 2048 。底层存储其实是一个bitmap，每一个位代表一个槽，如果该位为1，表示这个槽是属于这个节点。

消息体中，会携带一定数量的其他节点信息用于交换，约为集群总节点数量的1/10，节点数量越多，消息体内容越大。10个节点的消息体大小约1kb。

划重点：

细心的同学可能会有疑问，char不是占2个字节吗？数组长度为什么是 16384/8？不应该是 16384/16 吗？

因为，Redis 是 C 语言开发的，char 占用一个 字节；而 Java 语言 char 占用 两个 字节。

master节点间心跳通讯

Redis 集群采用 Gossip（流言）协议， Gossip 协议工作原理就是节点彼此不断通信交换信息，一段时间后所有的节点都会知道集群完整的信息，类似流言传播。

集群中每个节点通过一定规则挑选要通信的节点，每个节点可能知道全部节点，也可能仅知道部分节点，只要这些节点彼此可以正常通信，最终它们会达到一致的状态。当节点出现故障、新节点加入、主从角色变化、槽信息变更等事件发生时，通过不断的 ping/pong 消息通信，经过一段时间后所有的节点都会知道整个集群 全部节点的最新状态，从而达到集群状态同步的目的。

具体规则如下：

1、每秒会随机选取5个节点，找出最久没有通信的节点发送ping消息
2、每隔 100毫秒 都会扫描本地节点列表，如果发现节点最近一次接受pong消息的时间大于cluster-node-timeout/2 ，则立刻发送ping消息
因此，每秒单master节点发出ping消息数量：

= 1 + 10 * num（node.pong_received>cluster_node_timeout/2）

总结：

1、每秒 redis节点需要发送一定数量的ping消息作为心跳包，如果槽位为 65536，这个ping消息的消息头太大了，浪费带宽。

2、业务上看，集群主节点数量基本不可能超过1000个。集群节点越多，心跳包的消息体携带的数据越多。如果节点超过1000个，会导致网络拥堵。因此redis作者，不建议redis cluster节点数量超过1000个。

3、槽位越小，节点少的情况下，压缩率更高

插槽算法的是如何实现的，怎么去验证他啦

查查算法是先执行crc16算法在，在对16384取余数。
java实现代码

@RunWith(SpringRunner.class)
@SpringBootTest
@Slf4j
public class RedisClusterTest {
    @Autowired
    @Qualifier("redisClusterTemplate")
    private RedisTemplate redisClusterTemplate;
    @Test
    public void encryptPwd() {
        String key=RandomUtil.randomString(6);
        final int slotNum = CRC16.crc16(key.getBytes())%16384;
        redisClusterTemplate.opsForValue().set(RandomUtil.randomString(6), "Damein_xym");
        log.info("执行成功key值{},插槽数：{}",key,slotNum);
    }
}

终点在CRC16.crc16(key.getBytes())%16384这条语句，我们执行下看结果如何

上图可以看出key为5pgn7k,插槽数：14417，我们如何校验他，这是个问题，其实redis-cli客户端中早已提供了相关的操作，

从上截图可以看出两者计算出的插槽算是完全一致的，说明以上的推断成立

查看插槽命令为

cluster keyslot  key