业务发展过程中遇到的峰值瓶颈:
这个时候可以使用集群的方式可以快速解决上述问题
集群架构: 集群就是使用网络将若干台计算机联通起来,并提供统一的管理方式,使其对外呈现单机的服务效果
集群的作用:
假定我们现在增加一台机器,这些存储的数据以及空间应该如何分配呢?
一台机器分一些槽出来给新的机器,所谓的增加机器和删除机器,改变槽所存储的机器即可
此时有一台客户端查找key,首先会通过hash算法计算出key对应的槽编号,然后在哈希环上找到对应的机器,检查这台机器上是否有对应的槽(由于可能进行了机器的增加、删除,机器上的槽会被添加到不同机器上)
如果这台机器有key对应的槽,直接查找返回;如果没有,则查找每台机器槽编号和机器的记录,然后再到对应机器取即可
Cluster配置
设置加入cluster,成为其中的节点
cluster-enabled yes|no
cluster配置文件名,该文件属于自动生成,仅用于快速查找文件并查询文件内容
cluster-config-file <filename>
节点服务响应超时时间,用于判定该节点是否下线或切换为slave
cluster-node-timeout <milliseconds>
master连接的slave最小数量
cluster-migration-barrier <count>
配置3 masters—3 slaves
编写redis-6379.conf
由redis-6379.conf得到redis-6380.conf、redis-6381.conf、redis-6382.conf、redis-6383.conf、redis-6384.conf,分别作为3个master和3个slave的启动配置文件
启动所有的master和slave
这还是一个一个的节点,我们需要把他们连在一起,在src
目录下有一个redis-trib.rb
的可执行程序(这个文件执行需要安装ruby)
# 这里的n表示1个master对应n个slave
# 后面的ip:port表示master和slave的信息,master和slave的数量需要和前面的n对应
# 假设n=1,写了6组ip:port,则表示前3个为master,后3个为slave,实现1主1从
# 假设n=2,写了9组ip:port,则表示前3个为master,后6个为slave,实现1主2从
./redis-trib.rb create --replicas n ip1:port1 ip2:port2 ....
写6组ip:port,执行指令,生成3组1主1从
生成多组主从结构前,我们先看一下data目录(在redis-端口.conf中配置)下生成的节点的配置文件nodes-端口.conf
我们输入yes,生成3组1主1从
cluster连接在一起后,集群就配置好了,此时nodes-端口.conf就发生了改变。我们看一下master 6379对应的节点配置文件
我们看一下6379master终端的提示信息
我们连接上6379端口的redis服务器后,想要在6379服务器上放数据,可通过CRC算法和模16384计算出itheima
这个数据应该放在5798号槽,而这个槽在6380机器上,不允许我们放在6379机器上
我们使用-c
参数登录服务器,这个参数是专门操作集群的
我们依然连接6379服务器,放数据的时候,给出提示信息,虽然我们在6379上放数据,但通过CRC算法和模16384计算出itheima
这个数据应该放在5798号槽,故重定向到了6380机器
我们通过-c
参数登录6382这台slave服务器取数据
提示信息告诉我们,重定向到6380机器上的5798号槽取出来的。只要是我们登录集群中的任意一台机器,都能在6380机器上的5798号槽取出来,如果我们登录6380机器就不会有重定向信息,而是直接取出数据
集群最大的优势并不是能在多台机器存放数据,而是集群能够很好的解决宕机带来的业务灾难
我们先停掉6382 slave1
我们看一下slave1对应的master1,master1发现slave1 10s内无响应,则将其标记为已下线
而此时集群中的其他master和slave都会收到master1的通知,slave1已下线
这时我们让slave1重新上线
上线后和master1重新同步即可,master1再通知其他的master和slave有关slave1的上线信息,其他的机器就清除slave1的下线标记
总结: slave下线后,与其对应的master会将其标记为下线状态,同时通知集群中其他机器该slave下线;待其上线后,再与其进行数据同步,然后通知集群中其他的机器该slave的上线信息
我们停掉master1
下面是与master1对应的slave1的操作
我们用cluster nodes查看一下节点信息,发现有4个master,其中6379被标记为fail
我们现在重新启动6379
6379请求和6382进行数据同步
再用cluster nodes查看一下节点信息,6379的状态从master fail被修改为slave
总结: 当master1下线后,对应的slave1会尝试连接,超时后自己成为新的master,然后通知集群中其他的机器,master1下线以及自己成为master的消息,master1的状态被标记为master fail;6379重新上线时,会成为slave,并和自己的master进行数据同步
Cluster节点操作命令
查看集群节点信息
cluster nodes
进入一个从节点redis,切换其主节点
cluster replication <master-id>
发现一个新节点,新增主节点
cluster meet ip:port
忽略一个没有slot的节点
cluster forget
手动故障转移
cluster failover