SpringCloud-高级篇（十三）

前面的主从集群可以应对Redis高并发读的问题，Redis主从之间可以做同步，为了提高主从同步时的性能，单节点Redis的内存不要设置太高，如果内存占用过多，做RDB的持久化，或者做全量同步的时候，导致大量的IO性能会有一定的下降， 如果单节点Redis的内存降低了，比如说只能存10g，20g，那么有海量的数据要存储的时候改怎么办？这个问题解决不了，虽然应对高并发读的问题，如果我写的问题高并发也挺高，该怎么办，这就需要Redis的分片集群来解决

（1）搭建分片集群

需要有多个master，每个master都可以写，并发写的问题就可以保障了，每个master存储10g，好几个master加起来，内存就扩大了，数据存储的上限，取决于master的数量，理论上就能应对海量数据存储的问题 

每个master可以有多个slave节点，每个master可以形成主从关系，就能实现高并发读，具备的主从集群的特性了 

master之间有心跳，原来主从需要做哨兵，现在不需要做哨兵了，master之间互相起到哨兵的效果，通过心跳互相监控，多个master对一个master主观下线，也会把它做到可观下线，也可以做主从的切换，类似哨兵的功能，Redis客户端，可以访问集群中的任意节点，这些节点之间可以自动做路由，把你的请求路由到正确的节点上去访问，所以就不在需要哨兵机制了，同时具备的哨兵机制的所有功能，这就是分片集群的结构

准备多个配置文件 

查看启动状态：

输入yes回车

（2）散列插槽

slots叫做散列插槽

数据为什么跟插槽绑定而不是跟节点绑定，如果数据跟节点绑定，因为Redsi的主节点可能出现宕机的情况的，或者是集群扩容增加了节点，或者是删除了节点，如果节点删除了，或者宕机了数据就跟着丢了，如果跟插槽绑定，当节点宕机时，我们可以这个节点对应的插槽，转移到活着的节点

集群扩容时，我们也可以将插槽进行转移，数据跟着插槽走，永远就能找到数据的位置

集群模式下启动客户端需要加-c的参数

存储num的话算出的slot值是2765正好在7001分配的插槽内，正好存到这里

当存储a算出的是slot值在7003分配的插槽内，它会重定向到7003进行存储，并且只能在7003获取到这个值，在7003是获取不到num的值的它需要重定向到7001获取

所以我们说啊你访问集群中的任意一个节点都没有问题，它都可以显示这种重定向

{}为有效部分，为了让数据存储到一个插槽，可以把{}设为一样，后面的不一样，这样的key就可以存储到同一个Redis实例

（3）集群伸缩

作为分片集群有一个非常重要的功能，就是集群伸缩，就是集群可以动态的增加节点，或者是移出节点

添加集群节点帮助文档：

num存储在的插槽在7001，所以需要把7001的插槽分配到7004上

修改配置文件 

添加新节点7004到集群 后面的ip是集群中存在的一个ip端口

查询集群状态：但是7004是没有插槽的 

需要把num   2765的插槽分配到7004 

插槽的分配：把7001上的插槽分配到7004

移动2765的曹操移动过去，或者直接移动3000

那个曹的id7001的 id，然后done

输入yes 

查看发现7004有了插槽：

此时就可以在7004进行存储获取num

（4）故障转移

分片集群虽然没有哨兵但是也具备故障转移的功能

自动故常转移 

上面我们已经删除了7004节点：

我们让7002master宕机

发现8003变成主了 

重新启动7002就变成slave了：就实现了主从的切换

我们并不需要哨兵，Redis分片集群，具备主从的故障切换

手动故障转移 

这是自动的故障转移，有时候我们需要手动的进行主从切换，比如说这个机器比较老旧了，需要维护了，这个时候我们可以启动一个新的节点，让他称为7001的slave，然后手动的让它替换7001，实现手动故障转移

（5）RedisTemplate访问分片集群

我们最终还是使用java代码访问分片集群的，配置根集群的配置一样，这里只要改变分片集群的ip配置

 

 

查询：

set：他应该去找7001存取

换一个值：

它存取找的是7003节点：对应的插槽

所以集群的自动切换，插槽路由啊，读写分离都实现了。