文章目录
Redis之cluster集群
注:本文是基于CentOs 7系统上Redis v4.0.0进行讲解
1.集群介绍
集群就是使用网络将若干台计算机联通起来,并提供统一的管理方式,使其对外呈现单机的服务效果
2.集群作用
1.分散单台服务器的访问压力,实现负载均衡
2.分散单台服务器的存储压力,实现可扩展性
3.降低单台服务器宕机带来的业务灾难
3.集群数据存储设计
%16384是取模运算
如果又添加了一个服务器,或者有一个服务器突然宕机了,怎么办?
37所在的小方框叫作”槽“
如果现在又添加了一个服务器,或者有一个服务器突然宕机了,怎么办?
如下举例是3个服务器,又添加了一个服务器,变成了4个,则其他三个服务器每人掏出来一部分key给新来的服务器,进行优化。
所谓的增添节点与去节点其实是改变槽所存储的位置
4.集群内部通讯设计
1.加入现在有客户端进行访问数据库,进行key的查找,key被经过两个算法计算以后,得到key对应的存储槽的位置,假如计算的结果是A里面的35号槽,如果一次命中的话就直接返回,没有命中的话,35号槽会根据这个key进行查找,告诉客户端是在B那个槽里面,客户端会再去B里面的槽进行查找(注意:不是A去查找,是客户端再去查找,避免客户端自己多次去别的地方自己一个个挨着找)
2.最多两次即可命中
注意:各个数据库里面的槽的编号不一定是连续的,是散的
5.集群搭建方式
1.原生安装(单条命令)
1)配置服务器(3主3从)
2)建立通信(Meet)
3)分槽(Slot)
4)搭建主从(master-slave)
2.工具安装(批处理)
6.cluster配置
1.cluster-enabled yes|no
把该服务器添加为节点
2.cluster-config-file <filename>
cluster配置文件名,该文件属于自动生成。
如果我们给指定名字的话,会自动生成该指定名字的cluster-config-file ;
如果我们给未指定名字的话,会自动生成一个默认名字的cluster-config-file ;
举例:cluster-config-file nodes-6379.conf
仅用于快速查找文件并查询文件内容。
(注:我们尽量给指定名字,因为在大量节点的情况下默认生成的cluster-config-file文件名字都一样,容易混淆)
3.cluster-node-timeout
节点服务响应超时时间,用于判定该节点是否下线或切换为从节点
4.cluster-migration-barrier
master连接的slave最小数量
7.cluster节点操作命令
1.查看集群节点信息
cluster nodes
2.进入一个从节点 redis,切换其主节点
cluster replicate <master-id>
3.发现一个新节点,新增主节点
cluster meet ip:port
4.忽略一个没有solt的节点
cluster forget <id>
5.手动故障转移
cluster failover
8.redis-trib命令
redis-trib相当于一个脚本,把cluster的一些命令进行优化,实际中用cluster自带的命令或者redis-trib命令都可以
1.添加节点
redis-trib.rb add-node
2.删除节点
redis-trib.rb del-node
3.重新分片
redis-trib.rb reshard
9.演示(cluster集群搭建)
目前我们要配置一个3主3从的结构
删除data目录下的所有东西;
删除conf下的大部分东西,只剩下一个redis.conf
复制一个6379配置文件,并对6379配置文件进行修改,添加如下内容:
cluster-enabled yes|no
cluster-config-file nodes-6379.conf
cluster-node-timeout 10000 (10秒)
再把redis-6379.conf进行赋值6份
启动6379、6380、6381、6382、6383、6384
目前nodes-端口.conf里只有自己的id
接下来要执行一个redis-trib.rb命令,要想用这个命令必须嘚下载ruby与rubygem,ruby版本及rubygem版本必须得下载redis版本可接受范围内的版本
redis-trib.rb命令不能全局使用,比如./
ll | grep redis-
接下来就要开始创建集群,并且指定内部结构,
如果写1的话代表 1个master连接一个salve,命令会自动识别前一半ip是master,后一半ip是slave,进行一一对应
以下命令6382是6379的slave,6383是6380的slave,6384是6381的salve
6个服务器的运行id都显示出来了(与node-端口.conf里面运行id是一模一样的),而且还显示了它们分别所分的槽:
6379:0-5463(5461)
6380:5461-10922(5462)
6381:10923-16383(5461)
从机没有槽,回头salve需要复制master的槽
几乎是平均分配的
再次看node-端口号.conf配置文件,发现里面内容已经发生了变化
到此为止,cluster集群就搭建完成
再看master服务器日志控制台
再看slave服务器日志控制台
发现在6379master居然不能进行set操作,提示你让我们去6380进行操作,解决方法是连接redis客户端时候加-c参数,这是专门用来进行操作cluster集群的,自动帮我们重定向存到6380,第二次仍需要存到6380的原因是算法对key的计算是固定的,无论算几次结果都一样
在6382salve客户端进行get操作也需要加上-c参数,提示重定向到6380去取值
把6382slave给停止了,模拟来看看 salve宕机会发生什么事
看6379master日志输出,6382slave宕机后10秒后(我们在配置文件中配置过),master确认6382即死,标记failing
再看6380master日志输出,6380master收到了6379传来的信息;
再看6381master日志输出,6380master收到了6379传来的信息;
发现收到的信息一模一样
注:6383、6384salve也是会收到与6380收到的一模一样的信息
再次启动6382slave
看6379master日志输出,又进行了同步,同步过程与第一次连接时候一模一样;
6380、6381、6383、6384都输出”清楚“的信息,即把salve的死亡状态消除
总结:如果salve下线后,对整个系统没有什么影响,只是主机标记他下线了而已
现在使6379masetr下线,对6379进行ctrl c,
6381salve:
断之后,salve反复尝试与master进行连接,尝试10次后(之前我们设置了10秒,所以是10次,平均一秒一次,如果我们设置30的话就是尝试30次),确定master已死亡。然后6381salve自己当家作主,自己变成master,把cluster状态恢复ok
以下命令查看集群信息,发现4个master(其中1个失败,标记fail,因为这个master还可能恢复,所以仅仅标记下),2个salve
cluster nodes
把6379master再次启动:
把”6379master fail“状态清除掉,6379master变成slave,与6382进行同步
再次查看集群信息
查看6380日志输出