Redis Cluster是Redis的分布式解决方案,在3.0版本后推出的方案,有效地解决了Redis分布式的需求,当一个服务挂了可以快速的切换到另外一个服务,当遇到单机内存、并发等瓶颈时,可使用此方案来解决这些问题。
Redis 集群的数据分片
Redis 集群没有使用一致性hash, 而是引入了 哈希槽的概念.
Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽,举个例子,比如当前集群有3个节点,那么:
节点 A 包含 0 到 5500号哈希槽.
节点 B 包含5501 到 11000 号哈希槽.
节点 C 包含11001 到 16384号哈希槽.
这种结构很容易添加或者删除节点. 比如如果我想新添加个节点D, 我需要从节点 A, B, C中得部分槽到D上. 如果我想移除节点A,需要将A中的槽移到B和C节点上,然后将没有任何槽的A节点从集群中移除即可. 由于从一个节点将哈希槽移动到另一个节点并不会停止服务,所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态.
Redis集群参数配置
cluster-enabled <yes/no>: 如果配置”yes”则开启集群功能,此redis实例作为集群的一个节点,否则,它是一个普通的单一的redis实例。
cluster-config-file : 注意:虽然此配置的名字叫“集群配置文件”,但是此配置文件不能人工编辑,它是集群节点自动维护的文件,主要用于记录集群中有哪些节点、他们的状态以及一些持久化参数等,方便在重启时恢复这些状态。通常是在收到请求之后这个文件就会被更新。
cluster-node-timeout : 这是集群中的节点能够失联的最大时间,超过这个时间,该节点就会被认为故障。如果主节点超过这个时间还是不可达,则用它的从节点将启动故障迁移,升级成主节点。注意,任何一个节点在这个时间之内如果还是没有连上大部分的主节点,则此节点将停止接收任何请求。
cluster-slave-validity-factor : 如果设置成0,则无论从节点与主节点失联多久,从节点都会尝试升级成主节点。如果设置成正数,则cluster-node-timeout乘以cluster-slave-validity-factor得到的时间,是从节点与主节点失联后,此从节点数据有效的最长时间,超过这个时间,从节点不会启动故障迁移。假设cluster-node-timeout=5,cluster-slave-validity-factor=10,则如果从节点跟主节点失联超过50秒,此从节点不能成为主节点。注意,如果此参数配置为非0,将可能出现由于某主节点失联却没有从节点能顶上的情况,从而导致集群不能正常工作,在这种情况下,只有等到原来的主节点重新回归到集群,集群才恢复运作。
cluster-migration-barrier :主节点需要的最小从节点数,只有达到这个数,主节点失败时,它从节点才会进行迁移。更详细介绍可以看本教程后面关于副本迁移到部分。
cluster-require-full-coverage <yes/no>:在部分key所在的节点不可用时,如果此参数设置为”yes”(默认值), 则整个集群停止接受操作;如果此参数设置为”no”,则集群依然为可达节点上的key提供读操作。
环境介绍:
redis版本 5.0.4
集群环境
三台服务器模拟集群环境 三主三从:
134.98.1.80 6379 ; 134.98.1.80 6380
134.98.1.81 6379 ; 134.98.1.81 6380
134.98.1.85 6379 ; 134.98.1.85 6380
要让集群正常运作至少需要三个主节点,不过在刚开始试用集群功能时, 强烈建议使用六个节点: 其中三个为主节点, 而其余三个则是各个主节点的从节点。
第一步
网上看到之前构建集群需要ruby的方式,但是实践发现5.0 版本不需要,直接就可以使用 下面展示一下我的操作过程;
首先为了方便,我的每个机器上都新建了一个cluster文件件用来放配置文件。
每个机器各有两个配置文件,修改配置文件设置:
修改部分如下:
port 6380 #端口号
pidfile "/var/run/redis_6383.pid"
logfile "/usr/local/redis6380.log"
dbfilename "dump6380.rdb"
cluster-enabled yes #是否开启集群
cluster-config-file nodes-6380.conf #集群配置文件
cluster-node-timeout 15000 #集群中的节点能够失联的最大时间,超过这个时间,该节点就会被认为故障
文件中的 cluster-enabled 选项用于开实例的集群模式, 而 cluster-conf-file 选项则设定了保存节点配置文件的路径, 默认值为 nodes.conf.节点配置文件无须人为修改, 它由 Redis 集群在启动时创建, 并在有需要时自动进行更新。
每个机器都做了对应修改。
第二步
分别将服务器下的redis启动 redis-server ***.conf
第三步
使用redis-cli运行如下命令去构建集群
redis-cli --cluster create 134.98.1.80:6379 134.98.1.80:6380 134.98.1.85:6379 134.98.1.85:6380 134.98.1.81:6379 134.98.1.81:6380 --cluster-replicas 1
过程中需要我们去输入yes确认同意构建集群,当看到
下面绿色部分 才说明已经构建完成。主从关系是系统默认给你构建 不需要自己去操作。上图可以看出我的主机分别是
134.98.1.80:6379;134.98.1.85 :6379;134.98.1.81:6379 分别对应的从机依次是 134.98.1.85:6380;134.98.1.81:6380;134.98.1.80:6380
这里可能会出现错误,可能是因为你的服务器之前残留了dump或aof文件 需要将他们全部删除。
注:
之前使用ruby命令是:
./redis-trib.rb create --replicas 1 *******
5.0中,这个命令是一个过时已不再支持的方式,在Redis5.0中创建集群已经使用“redis-cli”来实现。
create 代表创建。–cluster-replicas 1代表一个主机对应一个从服务器
第四步
使用redis-cli -c 操作集群
集群会自动将你的数据存储到对应的卡槽中,如果当前卡槽不是要存储数据对应卡槽,会自动切换到该卡槽。
cluster nodes 可以查看集群环境
猜想:
如果此时我的一个主机挂了怎么办?
这里我们模拟一下134.98.1.81:6379挂机,在我们设置挂机连接超时时间过后,结果如下图
可以看到134.98.1.81:6379已经失去连接,而他的从机134.98.1.80:6380 已经上位成为新的主机。
如果这个时候134.98.1.81:6379修复好了 从新启动会怎么样呢?
演示一下 结果如下图:
可以看到 它已经自动成为134.98.1.80:6380从机。
下面简单介绍一下ruby的方式:
安装环境依赖
yum install ruby
yum install rubygems
gem install redis
使用yum install ruby安装后的ruby是2.0.0版本 而我们集群要求必须高于2.2所以我们需要安装高于2.2以上版本,以下是解决方案:
1、RVM 安装:
先执行一条官方 https://rvm.io/ 复制来的长命令:
gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB
继续执行#:curl -sSL https://get.rvm.io | bash -s stable
然后 执行 source /usr/local/rvm/scripts/rvm
继续执行#: rvm list known
,安装ruby,
#rvm install 2.5.x // 安装ruby,直接跟版本号即可
设置默认版本,命令:rvm use 2.5.1 --default
卸载一个已知版本,命令:rvm remove 2.0.0
查看ruby版本,命令:ruby -v
修改配置文件
节点加入集群命令
redis-trib.rb create --replicas 1 IP1: port1 ip2 :port 2
(不过此方式5.0中已经过时)
【参考资料】
http://www.redis.cn/topics/cluster-tutorial.html
https://blog.csdn.net/truelove12358/article/details/79612954
如有总结不当 或描述错误的地方请予以指正