Rocky9实现redis分布式集群

实验目的

掌握redis cluster工作原理，特点，实现redis分布式集群

实验主要内容

实现redis分布式集群部署

实验环境与准备

3台拍完快照配置好的linux主机，台均为rocky9主机且安装redis，三台均创建一个实例作为从节点

四、实验分析与设计思路

建议基于画图、思维导图等模式，结合文字描述，写的清晰、明了、得体

Redis cluster的

①：所有Redis节点使用(PING机制)互联

②：集群中某个节点的是否失效，是由整个集群中超过半数的节点监测都失效，才能算真正的失效

③：客户端不需要proxy即可直接连接redis，应用程序中需要配置有全部的redis服务器IP

④：redis cluster把所有的redis node 平均映射到 0-16383个槽位slot上，读与需要到指定的redis node上进行操作，因此有多少redis node相当于redis 并发扩展了多少倍，每个redis node 承担16384/N个槽位

⑤：Redis cluster预先分配16384slot,槽位，当需要在redis集群中写入key-value的时候，会使用RC16key md 16384之后的值，决定将Kev写入值哪个槽位从而决定写入哪一个Redis节点上，从而有效解决单机瓶颈。

五、详细实验过程

1、实现redis分布式集群部署

①：首先将已有redis服务停服，创建多实例（两个即可）

运行脚本安装redis，安装完成之后，运行创建实例的脚本（需要更改一下脚本内容）

[root@node-1 ~]# bash new_install_redis.sh

[root@node-2 ~]# vim install_instance.sh 查看脚本内容，用来创建实例6380

100、110和120都运行脚本，查看端口，端口6379和6380都开启了，实例创建好了

[root@node-2 ~]# bash install_instance.sh

[root@node-2 ~]# ss -tnl

同样10.120也创建实例，操作是一样的操作，可以看到端口已经打开，实例创建成功

运行下面命令修改配置文件

sed -i.bak -e '/masterauth/a masterauth 666666' -e '/# cluster-enabled yes/a cluster-enabled yes' -e '/# cluster-config-file nodes-6379.conf/a cluster-config-file nodes_6379.conf' -e '/cluster-require-full-coverage yes/c cluster-require-full-coverage no' /usr/local/redis/etc/redis.conf

sed -i.bak -e '/masterauth/a masterauth 666666' -e '/# cluster-enabled yes/a cluster-enabled yes' -e '/# cluster-config-file nodes-6380.conf/a cluster-config-file nodes_6380.conf' -e '/cluster-require-full-coverage yes/c cluster-require-full-coverage no' /usr/local/redis/etc/redis_6380.conf

[root@node-1 ~]# cd /usr/local/redis/etc/

修改完配置文件后三台主机均重启服务

systemctl restart redis redis_6380

进入redis服务查看集群是否开启 可以看到已经开启了集群

redis-cli -a 666666

INFO cluster

定义分布式集群 一主二主三主、一从二从三从，有严格的顺序

[root@node-1 etc]# redis-cli -a 666666 --cluster create 192.168.10.100:6379 192.168.10.110:6379 192.168.10.120:6379 192.168.10.110:6380 192.168.10.120:6380 192.168.10.100:6380 --cluster-replicas 1

查看集群的工作情况，是否OK

[root@node-1 etc]# redis-cli -a 666666 cluster info

[root@node-2 ~]# ls /usr/local/redis/data/

[root@node-2 ~]# cat /usr/local/redis/data/nodes_6379.conf

redis-cli -a 666666 -p 6380 info replication 查看主从关系

查看实例槽位以及对应的从节点

[root@node-2 ~]# redis-cli -a 666666 --cluster info 192.168.10.100:6379

[root@node-2 ~]# yum -y install pip 安装pip

[root@node-2 ~]# pip3 install redis-py-cluster 安装redis-py-cluster 模块

[root@node-2 ~]# python redis_cluster_test.py 运行脚本将数据导入到redis中

查看实例槽位以及对应的从节点 可以看到在每个redis中都生成了数据，而且几乎是平均的

使用DBSIZE分别查看各自的KEY数量

查看下指定的槽位号内是否有KEY，有多少KEY ，0为空，1为有key

模拟故障

[root@node-2 ~]# redis-cli -a 666666 -p 6380 将10.110的6379主节点进行下线

110的6379主节点对应的从节点为120的6380，登录120的6380查看状态

[root@node-3 ~]# redis-cli -a 666666 -p 6380

127.0.0.1:6380> INFO replication

可以看到120的6380从节点已经变成了主节点

重启110的6379实例 可以看到6379已经变成了slave从节点，主节点为120的6380

查询数据

在120的6380实例上插入数据

在从节点110的6379上进行查看信息，查看失败，因为从节点为了节省空间，所以没有同步到从节点中

将120的6380主节点下线

可以看到110的6379又变回到了主节点

在110的6379主节点中查看数据，因为120的6380停服之后就会将数据同步给110的6379，所以110的6379就会有数据

实验结果及分析

所有Redis节点使用(PING机制)互联

集群中某个节点的是否失效，是由整个集群中超过半数的节点监测都失效，才能算真正的失效

客户端不需要proxy即可直接连接redis，应用程序中需要配置有全部的redis服务器IP

redis cluster把所有的redis node 平均映射到 0-16383个槽位slot上，读与需要到指定的redis node上进行操作，因此有多少redis node相当于redis 并发扩展了多少倍，每个redis node 承担16384/N个槽位

Redis cluster预先分配16384slot,槽位，当需要在redis集群中写入key-value的时候，会使用RC16key md 16384之后的值，决定将Kev写入值哪个槽位从而决定写入哪一个Redis节点上，从而有效解决单机瓶颈。