2021-10-10----REDIS-CLUSTER集群

最新推荐文章于 2022-12-24 21:17:24 发布

我卡在门缝里了>_<

最新推荐文章于 2022-12-24 21:17:24 发布

阅读量133

点赞数

分类专栏： redis 文章标签： redis 数据库 ruby

本文链接：https://blog.csdn.net/qq_44494957/article/details/120689551

版权

11 篇文章 0 订阅

订阅专栏

集群结构

容量不够，如何进行扩容
并发写操作，如何分摊

redis2.9版本出现了redis-cluster,测试版本，从3.0正式出现redis-cluster，这个结构的出现彻底解决了搭建使用高可用分布式集群的难处。

redis-cluster是一个即可以高可用主从故障转移，也可以分片计算，分布式处理数据，从结构上来看，比之前高可用分布式变换一些，但是主从复制，故障转移依然存在，分布式计算不是hash取余，不是一致性hash，hash槽道。
在这里插入图片描述

在这里插入图片描述

所有节点之间两两之间互联通信的，底层二进制协议优化传输速度，是redis-cluster的基础
哨兵进程消失了，但是哨兵逻辑没有消失，整合到了master中，集群中最小结构是需要3个master存在的，master由于两两互联，可以监听集群所以节点通过master执行投票操作管理集群。
redis-cli客户端连接任意一个节点，通过两两互通的结构，都能获取到集群所以节点信息。
在集群中，引入了新的分布式计算逻辑（和之前介绍的一致性hash，hash取余区别），在于当前计算逻辑完全是集群技术定义的，不能由客户端更改–hash槽道，数据结构，hash槽中，提供了16384个槽道号slot，每一个主节点有权管理其中一部分数据（数据分片），key值计算hash取模运算（本质上是hash取余16384取余）得到结果【0-16383】对应槽道号，key值就和槽道号绑定，而因为槽道和节点绑定，key就对应了节点key–>slot–》node，key和节点之间就形成了一种松耦合的结构。

搭建的集群中，会有16384个槽道被分配给多个节点，每个节点管理其中一部分槽道
在这里插入图片描述
分布式计算定义的计算方法已经是hash槽，外界客户端无论使用哪种分布式计算逻辑，在集群内部都会重新计算分片
当数据到达某个节点之火，暂时不处理数据，这个节点作为集群一员先要计算槽道逻辑

使用8000-8005这个端口号来当做集群的节点启动，每个端口号启动的redis-server用到的配置文件都在redis家目录中。

启动6哥节点
8000为例：redis-server 8000/redis-cluster.conf
8000:是一个文件夹，redis-cluster.conf是一个文件，里面配置了端口号

后面六个按照相同的配置

在这里插入图片描述
搭建集群？

cluster meet# 集群节点握手，握手时传递了信息
绑定信息

cluster addslots slots…将16384个槽道中某一部分分配给当前登录的节点，等16384分配完毕，集群搭建成功了

分配槽道
在这里插入图片描述

cluster info 查看集群信息
cluster nodes查看集群中所有节点信息

在启动时，集群中测试新特性，测试具不具备之前学习的逻辑，高可用，数据备份
快速搭建集群命令

redis-cli --cluster create 创建的集群参数

redis-cli --cluster# 使用redis-cli操作集群相关内容
create # 搭建创建集群，包含了cluster meet和cluster addslots
ip1:port1 ip2:port,使用所有redis服务进程，来搭建集群，比如我们有六个节点，如果希望被外界访问就不要用回环地址127.0.0.1

其中7002等代表端口号
–cluster-replicas 1表示最少为每个主节点配置一个从节点，实现集群的高可用（6个节点，3主，3各自有一从，7个节点，3主，2个有一从，1个有2从）
在执行这个命令的时候，提示你的某个节点非空，原因
有持久化配置文件node的存在（$port文件夹/node.conf）
有吃鸡恶化数据的存在（$port文件/dump.rdb）
解决步骤
删除端口号为名称文件夹下的2个文件
可以编写一个脚本文件重置集群
reset-cluster.sh #编写shell脚本，实现当前redis cluster集群的清空工作。将集群重新变为搭建之前的结构。

使用redis-cli 能录到redis服务端，选项有2个-p -h。如果使用集群的效果，需要多添加一个选项-c

redis-cli -c -p 8000 -h 192.168.73.131

在这里插入图片描述

集群槽道体验
- 对8000执行命令set name haha
- 判断8000没有槽道，将客户端转向8001
在8001中继续执行命令set name haha
- 对name做hash取模计算–》5798
- 判断8001有这个操作，执行set命令
测试高可用数据复制
8000m—>8003s
8001m—>8005s
8002m—>8004s
8001中由于槽道测试效果，有了几个数据Name，可以使用8001测试
- 主从复制：8005看看有没有name就行
故障转移
将主节点宕机，然后观察从节点的顶替。

等待一段时间，观察8005变化

我们将这个时候，我们将8001回复
redis-server 8001/redis-cluster.conf
集群和之前结构比较
最大的区别在分布式计算逻辑hash槽
之前一致性hsh/hash取余：客户端进行分布式分片计算，客户端定义
现在的分布式计算hash槽：集群内部定义的，客户端重新定义任意分布式计算逻辑没有意义
hash槽道计算原理是什么？
- 如何判断所属权
- 如何获取正确管理权节点

关注