微服务框架
【SpringCloud+RabbitMQ+Docker+Redis+搜索+分布式，系统详解springcloud微服务技术栈课程|黑马程序员Java微服务】
分布式缓存
文章目录
- 微服务框架
- 分布式缓存
- 44 Redis 分片集群
- 44.2 散列插槽
- 44.2.1 散列插槽
- 44.2.2 总结
44 Redis 分片集群
44.2 散列插槽
44.2.1 散列插槽
Redis会把每一个master节点映射到0~16383共16384个插槽（hash slot）上，查看集群信息时就能看到：
可以看到三个master 节点的插槽加到一起，总共就是16384 个插槽
想想为什么要有这个插槽？
一个场景，现在我要存储一个数据到这个分片集群中去，比如
set num 123， 那么这个 num 数据应该存在哪一个master 上？如果是随便挑一个比如 7002 就存了，将来取的时候你怎么就知道num 在7002 上呢？
就相当于找不到了好家伙有道理【插槽就是用来解决这个问题的】
数据key不是与节点绑定，而是与插槽绑定。
redis会根据key的有效部分计算插槽值，分两种情况：
- key中包含"{}"，且“{}”中至少包含1个字符，“{}”中的部分是有效部分
- key中不包含“{}”，整个key都是有效部分
例如：key是num，那么就根据num计算，如果是{itcast}num，则根据itcast计算。计算方式是利用CRC16算法得到一个hash值，然后对16384取余，得到的结果就是slot值。
问题又来了
为什么key 要去和插槽 绑定而不是节点？
这是因为Redis 的 master 主节点是有可能出现宕机的情况的，或者集群扩容增加结点、集群伸缩删除节点，都有可能
如果说一个节点删除了，这时候数据和它绑一块儿的话，那就丢了
而 数据如果和插槽进行绑定，当master 宕机时，我们就可以将该节点对应的插槽转移到健康的主节点，集群扩容时，也可以将插槽进行转移，这样数据跟着插槽走，就永远都可以找到数据的位置
【这就是Redis 要将数据与插槽绑定的原因】
【验证一下】
redis-cli -c -p 7001
可以看到现在和以前单机没啥区别
再来一个 set a 1
可以看到有个什么 重定向的东西，即a 这个key 计算出来的插槽值是 15495，而15495 插槽确实又在7003 节点上
而且现在自己就跑到 7003 了
拿一下a
拿到了，但是num 显然不在 7003 ，拿一下试试
妙啊，它又自己给我重定向回了 7001 ，而且算出来的插槽值是 2765
44.2.2 总结
Redis如何判断某个key应该在哪个实例？
- 将16384个插槽分配到不同的实例
- 根据key的有效部分计算哈希值，对16384取余【存储时】
- 余数作为插槽，寻找插槽所在实例即可
如何将同一类数据固定的保存在同一个Redis实例？
- 这一类数据使用相同的有效部分，例如key都以{typeId}为前缀
试试这个
这就是控制一个key 的有效部分
