利用阿里云监控平台，监控接口时看到一个非常慢的接口，点了进去，发现了slot标志

通过查阅资料，习得哈希槽的概念：
slot：称为哈希槽

Redis 集群中内置了 16384 个哈希槽，当需要在 Redis 集群中放置一个 key-value时，redis 先对 key 使用 crc16 算法算出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。

使用哈希槽的好处就在于可以方便的添加或移除节点。

当需要增加节点时，只需要把其他节点的某些哈希槽挪到新节点就可以了；

当需要移除节点时，只需要把移除节点上的哈希槽挪到其他节点就行了；

在这一点上，我们以后新增或移除节点的时候不用先停掉所有的 redis 服务。

这里有个理解误区，有初学者会想，这个slot是不是存储数据的点？就是只能存16383+1个键？
实际并不是这样，这个slot只是对应节点(Redis服务)的一个存储范围(可以理解为这个Redis的别名)。

现有一个key要insert到Redis，那么根据 CRC16(key) mod 16384的值，比如得到3000,那就把这个key保存在A服务器里面了。读的时候也一样，有个key要去读，就先 CRC16(key) mod 16384 找到对应的slot，然后就去对应的服务器找数据。看起来，很像个索引吧。

想一个面试问题：
高并发的互联网公司中，有1亿条数据需要缓存，请问如何设计存储这批数据？
答：
单台服务器肯定存储不了这么大的数据，一般是分布式存储，就像数据库的分库分表一样存储，那针对缓存redis如何分布式存储这么大的数据？

利用哈希槽的做法：

哈希槽其实就是一个数组，数组[0, 1, 2, …, 2^14-1]形成hash slot空间

• 把哈希槽均匀分段，分配给redis节点
  redis节点1，负责存储5461个哈希槽的数据，编号0号至5460号哈希槽
  redis节点2，负责存储5462个哈希槽的数据，编号5461号至10922号哈希槽
  redis节点3，负责存储5461个哈希槽的数据，编号10923号至16383号哈希槽
• 计算每条数据的slot空间位置
• 将数据key进行哈希取值，映射已经固定大小的hash slot空间上
  例如：可以采用spring redis的API

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

例如：我们往redis设置3条数据：
redisTemplate.opsForValue.set(“A”, “agan1”);
redisTemplate.opsForValue.set(“B”, “agan2”);
redisTemplate.opsForValue.set(“C”, “agan3”);
然后计算key，A、B、C的slot槽位置
io.lettuce.core.cluster.SlotHash.getSlot(“A”)=6373
io.lettuce.core.cluster.SlotHash.getSlot(“B”)=10374
io.lettuce.core.cluster.SlotHash.getSlot(“C”)=14503
故，
key A、B落在slot空间的5461至10922区间上，并最终存储在Node 2上
key C落在slot空间的10923至16383区间上，并最终存储在Node 3上

redis哈希槽分区的特点：
1）解耦数据和节点之间的关系，例如：数据的读写只要计算出槽号就可以，节点的扩容和收缩只要重新均衡分配槽区间即可；故简化了节点扩容和收缩难度
2）节点自身维护槽的映射关系，不需要客户端（spring）或者代理服务维护槽分区和数据
3）支持节点、槽、键之间的映射查询，用于数据路由、在线伸缩等场景

数据和槽号是绑在一起的，spring通过槽号找到节点