Redis 集群

一、集群概念

业务发展过程中遇到的峰值瓶颈:

  • redis提供的服务OPS可以达到10万/秒,当前业务OPS已经达到20万/秒
  • 内存单机容量达到256G,当前业务需求内存容量1T

这个时候可以使用集群的方式可以快速解决上述问题

集群架构: 集群就是使用网络将若干台计算机联通起来,并提供统一的管理方式,使其对外呈现单机的服务效果

集群的作用:

  • 分散单台服务器的访问压力,实现负载均衡
  • 分散单台服务器的存储压力,实现可扩展性
  • 降低单台服务器宕机带来的业务灾难的可能性,实现高可用性

在这里插入图片描述

二、集群数据存储设计

  • 通过hash算法设计,计算出key应该保存的位置
  • 将所有的存储空间切割成16384份,每台主机保存一部分,每份代表的一个存储空间(槽),不是一个key的保存空间,这个存储空间可以保存很多key
  • 将key按照计算出的结果放到对应的存储空间

在这里插入图片描述
假定我们现在增加一台机器,这些存储的数据以及空间应该如何分配呢?

在这里插入图片描述

一台机器分一些槽出来给新的机器,所谓的增加机器和删除机器,改变槽所存储的机器即可

三、集群内部通讯设计

  • 各个数据库相互通信,保存各个库中槽的编号
  • 一次命中,直接返回
  • 一次未命中,告知具体位置,最多两次才命中

在这里插入图片描述
此时有一台客户端查找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终端的提示信息

在这里插入图片描述

五、集群使用实践

1. 使用集群存放数据

在这里插入图片描述
我们连接上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机器就不会有重定向信息,而是直接取出数据

2. slave掉线对集群的影响

集群最大的优势并不是能在多台机器存放数据,而是集群能够很好的解决宕机带来的业务灾难

我们先停掉6382 slave1

在这里插入图片描述
我们看一下slave1对应的master1,master1发现slave1 10s内无响应,则将其标记为已下线
在这里插入图片描述
而此时集群中的其他master和slave都会收到master1的通知,slave1已下线

在这里插入图片描述
这时我们让slave1重新上线

在这里插入图片描述
上线后和master1重新同步即可,master1再通知其他的master和slave有关slave1的上线信息,其他的机器就清除slave1的下线标记

在这里插入图片描述

总结: slave下线后,与其对应的master会将其标记为下线状态,同时通知集群中其他机器该slave下线;待其上线后,再与其进行数据同步,然后通知集群中其他的机器该slave的上线信息

3. master掉线对集群的影响

我们停掉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
  • 3
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

bugcoder-9905

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值