目录
一、集群原理及搭建
当我们做了读写分离,做了哨兵高可用,还下列存在问题:
- 并发量:单机redis qps为10w/s,但是我们可能需要百万级别的并发量
- 数据量:机器内存16g--256g,如果存500g数据呢?
解决方案:使用集群
即加机器,使用分布式
1、redis集群介绍
redis cluster 在2015年的 3.0 版本加入了,满足分布式的需求
Redis集群是一个分布式的Redis数据库系统,它可以在多个节点上存储数据,并提供高可用性和可伸缩性。
Redis集群使用分片技术将数据分布在多个节点上,每个节点都负责存储其中的一部分数据。集群中的节点可以动态地加入或退出,从而实现高可用性和可伸缩性。
在Redis集群中,客户端可以连接到任何一个节点并进行读写操作,节点之间会自动同步数据。同时,Redis集群还提供了一些额外的功能,如槽位迁移和自动故障转移,以确保数据的可用性和一致性。
2、数据库的多机数据分布方案
存在问题
假设全量的数据非常大,500g,单机已经无法满足,我们需要进行分区,分到若干个子集中
主流分区方式(数据分片方式)
分布方式 | 特点 | 产品 |
---|---|---|
哈希分布 | 数据分散度高,建值分布于业务无关,无法顺序访问,支持批量操作 | 一致性哈希memcache,redis cluster,其他缓存产品 |
顺序分布 | 数据分散度易倾斜,建值业务相关,可顺序访问,支持批量操作 | BigTable,HBase |
拓展:在分数据的时候,也是有讲究的,比如一个表存了很多的数据,垂直分和水平分是不同的效果。
顺序分区
原理:100个数据分到3个节点上 1--33第一个节点;34--66第二个节点;67--100第三个节点(很多关系型数据库使用此种方式)
哈希分区
原理:hash分区: 节点取余 ,假设3台机器, hash(key)%3(即对用hash选法处理后得到的数字取余,余数是几就存在哪个节点上),落到不同节点上
节点取余分区介绍
从上图我们可以得知节点取余扩容的时候,存在问题,如果我们偏移一个节点,总偏移量大于80%(移动的数据量),当数据量很大的时候耗时很久。
因此这里我们推荐翻倍扩容,比如由三个节点变成6个节点,这样数据量迁移为50%,比80%低很多
优缺点总结:
1、客户端分片,通过hash+取余
2、节点伸缩,数据节点关系发生变化,导致影响数据迁移过大
3、迁移数量和添加节点数量有关:建议翻倍扩容
一致性哈希分区
每个节点负责一部分数据,对key进行hash,得到结果在node1和node2之间,就放到node2中,顺时针查找
假设添加一个新节点node5,现在只需要迁移一小部分数据,不会影响node3和node4的数据,只会迁移node1和node2的数据,虽然迁移的数据量小,但是会引起数据分布不均匀。
节点比较多的话合适,假设有1000个节点,加一个只要迁移千分之一的数据
优缺点总结
1、客户端分片:哈希+顺时针(优化取余)
2、节点伸缩:只影响临近节点,但是还有数据迁移的情况
3、伸缩:保证最小迁移数据和无法保证负载均衡(这样总共5个节点,数据就不均匀了),翻倍扩容可以实现负载均衡
虚拟槽分区
前面两种分区方式都存在一些问题,而虚拟草分区就可以解决他们存在的问题,原因如下:
- 预设虚拟槽:每个槽映射一个数据子集,一般比节点数大
- 良好的哈希函数:如CRC16(前面两种用的不是这种)
- 服务端管理节点、槽、数据:如redis cluster(槽的范围0–16383)
5个节点,把16384个槽平均分配到每个节点,客户端会把数据发送给任意一个节点,通过CRC16对key进行哈希对16383进行取余,算出当前key属于哪部分槽,属于哪个节点(余数为几就存在哪个位置),每个节点都会记录是不是负责这部分槽,如果是负责的,进行保存,如果槽不在自己范围内,redis cluster是共享消息的模式,它知道哪个节点负责哪些槽,返回结果,让客户端找对应的节点去存 服务端管理节点,槽,关系
拓展:
为什么redis的槽有16384个?
槽位的数量为16384是Redis设计者经过实验和经验总结得出的最佳值。
具体来说,16384个槽位可以提供良好的性能和分布式效果。如果槽位数量太少,会导致数据分布不均,一些节点可能会容易成为热点节点,而其他节点则可能闲置。而如果槽位数量太多,会导致集群中的节点数量限制,因为每个节点都需要处理大量的槽位,这可能会导致性能下降。
因此,16384个槽位是一个平衡点,可以提供良好的性能和分布式效果,并且也可以灵活地适应不同规模的集群。如果需要更高的性能或更大的集群规模,可以通过增加节点数量来实现。
3、集群搭建
之前我们学习的主从属于单机架构
分布式架构
每个节点之间相互通信,都负责读写,客户端去存,如果不是当前节点,会返回应该存到哪个节点
Redis Cluster(集群)架构就是一种分布式架构
Redis Cluster(集群)架构中的名词:节点,meet,指派槽,复制,高可用
名词解释
节点(某一台机器)
meet(节点跟节点之间通过meet通信)
指派槽(16384个槽分给几个节点)
复制(主从赋值)
高可用(主节点挂掉,从节点顶上)
meet
A meet一下C,C回复一下,A meet一下B ,B回复一下,这样B和C也能相互感知,A,B,C之间就可以相关交互数据,所有节点共享消息
指派槽
总共有16384个槽,平均分配到每个节点上
搭建步骤
ps:这里我们学习的时候用用即可,到了公司里,就算你想搭,公司也不敢让你来弄
步骤一
准备6台机器 (或是6个redis-server进程)
步骤二
编写六个配置文件(因为我们是起了六个进程来模拟,所以用命令快速配置了)
port 7000
daemonize yes
dir "/root/redis/data/"
logfile "7000.log"
cluster-enabled yes
cluster-node-timeout 15000
cluster-config-file nodes-7000.conf
cluster-require-full-coverage yes
配置介绍
# 配置
port ${port} # 端口
daemonize yes # 是否以后台进程的方式启动
dir "/opt/redis/redis/data/" # 文件保存目录
logfile "${port}.log" # 日志文件名称
#masterauth 集群搭建时,主的密码
cluster-enabled yes # 开启cluster(集群)
cluster-node-timeout 15000 # 故障转移,超时时间 15s
cluster-config-file nodes-${port}.conf # 给cluster节点增加一个自己的配置文件
cluster-require-full-coverage yes #只要集群中有一个故障了,整个就不对外提供服务了,这个实际不合理,假设有50个节点,一个节点故障了,所有不提供服务了;,需要设置成no
步骤三
快速复制6个配置问题,并修改配置
sed 's/7000/7001/g' redis-7000.conf > redis-7001.conf
sed 's/7000/7002/g' redis-7000.conf > redis-7002.conf
sed 's/7000/7003/g' redis-7000.conf > redis-7003.conf
sed 's/7000/7004/g' redis-7000.conf > redis-7004.conf
sed 's/7000/7005/g' redis-7000.conf > redis-7005.conf
步骤四
./src/redis-server ./redis-7000.conf
./src/redis-server ./redis-7001.conf
./src/redis-server ./redis-7002.conf
./src/redis-server ./redis-7003.conf
./src/redis-server ./redis-7004.conf
./src/redis-server ./redis-7005.conf
'查看启动的redis进程'
ps -ef |grep redis
这时候我们去设置数据,会失败,因为没有分配槽
redis-cli -p 7000 set hello world #报错
步骤五
一次性配置三个主从
./src/redis-cli --cluster create --cluster-replicas 1 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005
分开配置主从关系参考博客:https://www.cnblogs.com/liuqingzheng/articles/17324393.html
步骤六
通过命令查看相关信息
redis-cli -p 7000 cluster info # 查看集群信息
redis-cli -p 7000 cluster nodes # 查看集群节点
redis-cli -p 7000 cluster slots # 查看槽的信息
步骤七
测试,存数据
# 第六步:测试,存数据
./src/redis-cli -p 7000 -c
当我们停掉某一台主库的时候,过一段时间,我们会发现他的从库变成了新的主库,我们再次开启最初的主库,他就变成了从库
4、集群扩容
在上面配置的集群基础上,我们再启动两台机器(或是两个redis服务),用他们来做集群扩容
步骤一
创建两台新机器的配置文件
sed 's/7000/7006/g' redis-7000.conf > redis-7006.conf sed 's/7000/7007/g' redis-7000.conf > redis-7007.conf
步骤二
启动两台新的机器
./src/redis-server ./redis-7006.conf
./src/redis-server ./redis-7007.conf
步骤三
将两台机器加入到集群中去
ps:这两台机器(进程)必须是空的,如果是在一台机器上用多个redis进程来实现的,用了rdb方式产生了持久化文件,会导致这两个新的进程运行的时候内部出现数据,从而导致添加集群报错
./src/redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:7000 ./src/redis-cli --cluster add-node 127.0.0.1:7007 127.0.0.1:7000
步骤四
让7006充当主库(把7007做为7006的从),让7007复制7006
redis-cli -p 7007 cluster replicate 7006的id
./src/redis-cli -p 7007 cluster replicate baf261f2e6cb2b0359d25420b3ddc3d1b8d3bb5a
步骤六
迁移槽,执行的时候需要输入yes进行确认,期间还有一个操作需要我们确认,他会问我们手动迁移还是自动迁移,我们输入all进行自动迁移。
./src/redis-cli --cluster reshard 127.0.0.1:7000
因为我们是三个节点变成四个节点,所以计算之后可以看到,总共迁移了4096个槽,这些槽都被7006机器接收了
这些槽是每个节点中分一些出来,凑成4096个槽,给新的节点
5、集群缩容
步骤一
下线迁槽(把7006的4096个槽迁移到其他三个节点上)
redis-cli --cluster reshard --cluster-from 7006的id --cluster-to 7000的id --cluster-slots 1366 127.0.0.1:7000
yes
redis-cli --cluster reshard --cluster-from 7006的id --cluster-to 7001的id --cluster-slots 1366 127.0.0.1:7001
yes
redis-cli --cluster reshard --cluster-from 7006的id --cluster-to 7002的id --cluster-slots 1365 127.0.0.1:7002
yes
'实际代码'
redis-cli --cluster reshard --cluster-from baf261f2e6cb2b0359d25420b3ddc3d1b8d3bb5a --cluster-to 050bfd3608514d4db5d2ce5411ef5989bbe50867 --cluster-slots 1365 127.0.0.1:7000
yes
redis-cli --cluster reshard --cluster-from baf261f2e6cb2b0359d25420b3ddc3d1b8d3bb5a --cluster-to 9cb2a9b8c2e7b63347a9787896803c0954e65b40 --cluster-slots 1366 127.0.0.1:7001
yes
redis-cli --cluster reshard --cluster-from baf261f2e6cb2b0359d25420b3ddc3d1b8d3bb5a --cluster-to d3aea3d0b4cf90f58252cf3bcd89530943f52d36 --cluster-slots 1366 127.0.0.1:7002
yes
ps:我们在迁移会去的时候需要自己计算号槽的数量,多了报错,少了需要重新把少迁移的槽迁移过去
步骤二
下线节点 忘记节点,关闭节点
redis-cli --cluster del-node 127.0.0.1:7000 要下线的7007id # 先下从,再下主,因为先下主会触发故障转移
redis-cli --cluster del-node 127.0.0.1:7000 要下线的7006id
'实操代码'
./src/redis-cli --cluster del-node 127.0.0.1:7000 9c2abbfaa4d1fb94b74df04ce2b481512e6edbf3 # 先下从,再下主,因为先下主会触发故障转移
./src/redis-cli --cluster del-node 127.0.0.1:7000 baf261f2e6cb2b0359d25420b3ddc3d1b8d3bb5a
步骤三
验证集群是否正常工作,关掉其中一个主,另一个从立马变成主顶上, 重启停止的主,发现变成了从
标签:--,redis,cluster,集群,conf,7000,节点,搭建 From: https://www.cnblogs.com/wxlxl/p/17343270.html