笔记记录两个场景:
1:数据读写存储
a:一个新key数据来了,是否会按照预设的进入槽中?集群是否生效
2:容错切换迁移
a:如果master 6381挂了。那么对应的从6384是否会补位?
数据读写存储操作步骤:
1、启动6台机器构成的集群并通过exec进入
2:对6381新增两个key
查看当前6381机器上是否存在缓存key:
发现没有,则就来set k1 v1.
发现错误了。错误信息:
(error) MOVED 12706 192.168.50.128:6383
set k v是最简单的命令但不支持。
分析原因:
现在使用的是集群的,是有hash槽的。如下图:
可以看到,master 1 只能管理5461个槽。master2只能管理5462个。master3也是管理5461个槽。
集群的时候,是通过把key通过hash值,算出的hash值找到对应具体需要存放在哪个master上的。那么可能set的k1这个key经过hash之后,不在当前master1所管理的0~5460共5461个hash槽中。所以会报错。
试试存放其他的:
可以看到,set k2和k3的时候可以的。但是k1和k4是不行的。
k1和k4的错误:MOVED 12706和MOOVED 8455
这两个数字可能是hash槽。可以看到这两个值都大于master1所能管理的最大槽的值。master1最大槽值为:5460.因为使用的是redis-clie -p 6381 这种直连的方式连接的,所以master1存放不了。
3:防止路由 失效,加参数-c 并新增加两个key
如果是集群模式下,我们需要添加一个参数-c。来防止路由失效
重新set k1 k4试试。
可以看到,key路由到对应的master上了。
4:查看集群信息
命令公式:
redis-cli --cluster check ip:端口
容错切换迁移
假设master1(6381)宕机了,那么对应的slave4(6384)是否会正常补位。
步骤:1:maser1 6381和从机6384切换,先停止主机6381
使用docker stop 容器id/或者容器names
停止后,等一会。因为集群之间有心跳检查。所以等待一会。2:再次查看集群信息
因为6381已经宕机了。那么我们进入6382中,注意以集群的方式进入。需要加参数-c。
查看进群情况;
cluster nodes
注意看:我们发现集群还是6个。但是6481这特master,是fail了。6381对应的从及6384现在成了master.说明,从机补位了。
这就实现了故障容错切换迁移。
get下k1 k2 k3 k4看看情况:
可以正常获取3:先还原之前的3主3从
4:查看集群状态
我们可以看到,虽然6381重新启动了。但是6381却成了6384的从节点了。