您好,登录后才能下订单哦!
Redis是从3.0版本开始支持cluter的,采用的是hash槽方式,可以将多个Redis实例整合在一起,形成一个群集,也就是将数据分散存储到群集中的多个节点上。
Redis的cluster是一个无中心的结构,在群集中,每个master的身份是平等的,每个节点都保存数据和整个群集的状态,并且知道其他节点所负责的槽,也会定时发送心跳信息,能够及时感知群集中异常的节点,并且采取投票的方式来决定该节点是否为不可用,若票数为群集中节点的半数以上,则认为该节点不可用,也正是因为此特点,所以要部署Redis群集,节点数量最少要三个及以上。
群集角色有master和slave,master之间分配slots(槽),槽点编号是0-16383(共16384个)。
默认情况下,每个群集节点有两个TCP端口在监听,一个是6379(用于监听客户端的访问连接),另一个是16379(用于群集之间的节点通信)。注意,防火墙需要放行这两个端口的流量。
Redis的所有数据都是保存在内存中,然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”);也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)。
Redis提供的这两种方式进行持久化,一种是RDB持久化(原理是将Redis在内存中的数据库定时记录dump到磁盘上的RDB持久化),另一种是AOF(append only file)持久化(原理是将Redis的操作日志以追加的方式写入文件)
RDB的优点与缺点
RDB半持久化的优点:
- 只包含一个文件,有利于文件备份;
- 灾难恢复比aof持久化要快;
- 性能最大化。对于Redis的服务进程而言,在开始持久化时,它唯一需要做的只是fork出子进程,之后再由子进程完成这些持久化的工作,这样就可以极大的避免服务进程执行IO操作了。
- 相比较AOF机制,如果数据集过大,RDB的启动效率会更高。
RDB半持久化的缺点:- 由于RDB是通过fork子进程来协助完成数据持久化工作的,因此,如果当数据集比较大时,可能会导致整个服务停止几百毫秒,甚至是1秒钟。
AOF的优点与缺点
AOF全持久化的优点:
- 可以保证数据的高可用性;
- 写入过程中及时出现宕机现象,也不会破坏日志文件中已经存在的内容,如果在写入过程中宕机,重启Redis后可以通过redis-check-aof工具来解决;
- 如果日志过大,Redis可以自动启用rewrite机制,生成新的文件存储aof日志;
- 该机制可以带来更高的数据安全性,及数据持久性。Redis中提供了三种同步策略,即每秒同步、每修改同步和不同步。
AOF全持久化的缺点:- 对于相同数量的数据集而言,AOF文件通常要大于RDB文件。RDB在恢复大数据集时的速度比AOF的恢复速度要快;
- 根据同步策略的不同,AOF在运行效率上往往会慢于RDM,总之,每秒同步策略的效率是比较高的,同步禁用策略的效率和RDB一样高效。
如果RDB和AOF同时存在,则优先选择AOF方式。
上面共六台centos服务器,实现三台master分别对应一台slave(也可以在一台服务器上配置多个Redis实例,但不要master-slave在同一台物理服务器,可以使用交叉master-slave的方式进行主从复制,所谓交叉就是master在node01,但对应的slave在node02,node02上master对应的slave在node03,而node03对应的slave在node01,这样做的好处是避免因为物理服务器的宕机而造成整个群集崩溃,这里只是稍微提示以下,自行研究即可)。
这里为了展示同一台主机上配置多个Redis实例,所以将在node06上配置多个Redis实例,其余节点各负责一个Redis实例即可。
在进行接下来的配置前,请先下载我提供的源码包(其实,这里部署的版本是Redis4.0的,版本还低了些,有些方便的配置无法进行,可以参考下我那篇部署Redis 5.0的博文)。
这里以node01的配置进行示例,其他节点照搬进行配置即可。
[root@node01 ~]# ls | grep redis #在xshell使用rz命令上传我提供的包,如下:
redis-4.0.14.tar.gz
[root@node01 ~]# tar zxf redis-4.0.14.tar.gz -C /usr/local/ #解包
[root@node01 ~]# cd /usr/local/ #切换至指定路径
[root@node01 local]# mv redis-4.0.14 redis #更改目录名称
[root@node01 local]# cd redis/ #切换至解压后的目录
[root@node01 redis]# make && make install #无需配置,直接编译安装即可
[root@node01 redis]# ./utils/install_server.sh #对Redis进行初始化
#初始化的所有选项保持默认,一路回车确认即可
#是在确认监听端口、配置文件、日志文件、pid存放路径等信息
.............#省略部分内容
Successfully added to chkconfig!
Successfully added to runlevels 345!
Starting Redis server...
Installation successful!
#出现上述内容,则表示初始化成功
#接下来进行一些优化,如下:
[root@node01 redis]# echo "512" > /proc/sys/net/core/somaxconn
[root@node01 redis]# echo "vm.overcommit_memory = 1" >> /etc/sysctl.conf
[root@node01 redis]# sysctl -p
vm.overcommit_memory = 1
[root@node01 redis]# echo "never" > /sys/kernel/mm/transparent_hugepage/enabled
[root@node01 redis]# vim /etc/redis/6379.conf #编辑配置文件,修改如下
bind 0.0.0.0 #找到没有被注释的这一行,修改为0.0.0.0
daemonize yes #若有注释符号,需要删除注释符号,以便生效
cluster-enabled yes
cluster-node-timeout 5000
appendonly yes
#修改完成后,保存退出即可。
[root@node01 redis]# /etc/init.d/redis_6379 restart #重启Redis服务
[root@node01 redis]# netstat -anpt | grep redis #确定端口6379及16379处于监听状态
在其他节点服务器上将上述配置依次进行以便,主机node06除外,因为稍后将在node06上展示单台主机多Redis实例的配置。
node06这个节点上,我将配置其运行多个Redis数据库实例,所以与前面五个节点的配置并不是完全一样,请谨慎配置。
[root@node06 ~]# tar zxf redis-4.0.14.tar.gz -C /usr/local/
[root@node06 ~]# cd /usr/local/
[root@node06 local]# mv redis-4.0.14 redis
[root@node06 local]# cd redis/
[root@node06 redis]# make && make install #编译安装后,无需进行初始化
[root@node06 redis]# redis-server #启动查看需要优化的项
#在前面几个节点的优化配置就是从此命令执行后的提示信息获得的
#接下里就优化这些提示的配置咯!
[root@node06 redis]# echo "512" > /proc/sys/net/core/somaxconn
[root@node06 redis]# echo "vm.overcommit_memory = 1" >> /etc/sysctl.conf
[root@node06 redis]# sysctl -p
vm.overcommit_memory = 1
[root@node06 redis]# echo "never" > /sys/kernel/mm/transparent_hugepage/enabled
[root@node06 redis]# vim redis.conf #编辑当前目录下的模板配置文件以下几项
bind 0.0.0.0
port 6379
daemonize yes #开启后台守护进程,以便后台运行
cluster-enabled yes #开启群集
cluster-node-timeout 5000 #群集节点间的超时时间,单位是毫秒
appendonly yes #是否开启同步到磁盘
appendfilename "appendonly-6379.aof" #aof日志的名字
#编辑完成后,保存退出即可
[root@node06 redis]# mkdir -p /usr/local/redis-cluster/{6379..6382}
#以上是打算运行几个Redis实例,就创建几个目录即可,这里我以实例的端口号给目录命名(暂时打算运行4个Redis实例)
#以下是将修改后的配置文件复制到指定的目录下一份
[root@node06 redis]# cp redis.conf /usr/local/redis-cluster/6379/
[root@node06 redis]# cp redis.conf /usr/local/redis-cluster/6380/
[root@node06 redis]# cp redis.conf /usr/local/redis-cluster/6381/
[root@node06 redis]# cp redis.conf /usr/local/redis-cluster/6382/
#然后下面将复制过去的各个配置文件中改为与Redis实例对应的端口号
[root@node06 redis]# cd /usr/local/redis-cluster/
[root@node06 redis-cluster]# sed -i s/6379/6380/g 6380/redis.conf
[root@node06 redis-cluster]# sed -i s/6379/6381/g 6381/redis.conf
[root@node06 redis-cluster]# sed -i s/6379/6382/g 6382/redis.conf
[root@node06 redis-cluster]# cd 6379 #切换到6379目录
[root@node06 6379]# redis-server redis.conf #启动该目录下的配置文件
101582:C 04 Nov 23:37:04.988 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
101582:C 04 Nov 23:37:04.988 # Redis version=4.0.14, bits=64, commit=00000000, modified=0, pid=101582, just started
101582:C 04 Nov 23:37:04.988 # Configuration loaded
#接下来就是依次启动各个实例
[root@node06 6379]# cd ../6380
[root@node06 6380]# redis-server redis.conf
[root@node06 6380]# cd ../6381
[root@node06 6381]# redis-server redis.conf
[root@node06 6381]# cd ../6382
[root@node06 6382]# redis-server redis.conf
[root@node06 6382]# netstat -anpt | grep redis #查看Redis相关端口的监听情况
上述查看Redis端口监听情况的返回信息如下:
[root@node01 ~]# yum -y install rpm-build openssl openssl-devel #安装依赖
[root@node01 ~]# ls | egrep "gem|ruby" #将下面的两个包上传至主机node01
redis-3.3.0.gem
ruby-2.3.1.tar.gz
[root@node01 ~]# tar zxf ruby-2.3.1.tar.gz -C /usr/src #解包
[root@node01 ~]# cd /usr/src/ruby-2.3.1/ #进入解压后的目录
[root@node01 ruby-2.3.1]# ./configure --prefix=/usr/local/ruby && make && make install #编译安装,时间较长
#下面是对生成的命令做软连接
[root@node01 ruby-2.3.1]# ln -sf /usr/local/ruby/bin/* /usr/local/bin/
[root@node01 ruby-2.3.1]# ln -sf /usr/local/redis/src/redis-trib.rb /usr/local/bin/
[root@node01 ruby-2.3.1]# cd #回到 .gem文件所在目录
[root@node01 ~]# gem install redis-3.3.0.gem #执行此命令
Successfully installed redis-3.3.0
Parsing documentation for redis-3.3.0
Installing ri documentation for redis-3.3.0
Done installing documentation for redis after 0 seconds
1 gem installed
#返回上述信息则表示成功
[root@node01 ~]# redis-cli -p 6379 #登录到本地Redis实例
#以下是将参与群集的各个节点添加到群集中
127.0.0.1:6379> CLUSTER MEET 192.168.20.3 6379
OK
127.0.0.1:6379> CLUSTER MEET 192.168.20.4 6379
OK
127.0.0.1:6379> CLUSTER MEET 192.168.20.5 6379
OK
127.0.0.1:6379> CLUSTER MEET 192.168.20.6 6379
OK
127.0.0.1:6379> CLUSTER MEET 192.168.20.7 6379
OK
127.0.0.1:6379> set a b #虽然节点添加完成,但是由于没有分配hash槽,所以无法添加数据
(error) CLUSTERDOWN Hash slot not served
127.0.0.1:6379> CLUSTER INFO #查看群集的状态
cluster_state:fail #是失败的
192.168.20.3:6379> exit
#接下来为群集中的节点分配槽点
#必须小心分配,一旦分配错误,很麻烦
#虽然可以将命令中的“add”换为“del”,但是我没有成功
#一定要将0至16383完全分配出去,最好是等份分配
#只需给作为master的节点分配即可,我这里node01至node03为master
[root@node01 ~]# redis-cli -h 192.168.20.2 -p 6379 cluster addslots {0..5461}
OK
[root@node01 ~]# redis-cli -h 192.168.20.3 -p 6379 cluster addslots {5462..10922}
OK
[root@node01 ~]# redis-cli -h 192.168.20.4 -p 6379 cluster addslots {10923..16383}
OK
[root@node01 ~]# redis-cli -p 6379 -c #进入群集,需要加“-c”选项
127.0.0.1:6379> CLUSTER NODES #查看群集中的节点信息
#接下来是将各个slave从节点与master进行绑定
#node04作为node01的从节点,node05作为node02的从节点,node06的6379实例作为node03的从节点
#需要配置哪个从节点,就需要登录到哪个实例
127.0.0.1:6379> CLUSTER NODES #可以先执行此命令,查看相应节点的ID,以便接下来指定
[root@node01 ~]# redis-cli -h 192.168.20.5 -p 6379 #登录到node04
192.168.20.5:6379> CLUSTER REPLICATE 5cd3d0eec161a7bcc785202397fd8363074ae9c2
#上面指定的是node01节点的ID
OK
192.168.20.5:6379> exit #退出实例
[root@node01 ~]# redis-cli -h 192.168.20.6 -p 6379 #登录到node05
192.168.20.6:6379> CLUSTER REPLICATE e2de936c380eb2239f0a349dcbfba5daa74fa1d7
#上述指定的是node02的节点ID
OK
192.168.20.6:6379> exit #退出实例
[root@node01 ~]# redis-cli -h 192.168.20.7 -p 6379 #登录到node06的6379实例
192.168.20.7:6379> CLUSTER REPLICATE dd03b02213df3a91608d1f4ae8080c37f4790d7c
#上述是指定node03的节点ID
OK
192.168.20.7:6379> exit
配置至此,可再次查看群集的节点信息,会发现主从之间都对应上了,如下:
至此,群集即可正常读写数据了,如下:
[root@node01 ~]# redis-cli -h 192.168.20.2 -p 6379 -c #登录到群集
192.168.20.2:6379> set b c
OK
[root@node01 ~]# redis-trib.rb check 127.0.0.1:6379 #检查群集的状态
上述命令返回的信息如下:
[root@node01 ~]# redis-trib.rb add-node 192.168.20.7:6380 192.168.20.2:6379
#在添加节点时,不添加其他配置,默认加入群集后,角色是master
返回的提示信息如下则表示成功:
由于一个群集若要正常运行,必须将所有的槽点分配出去,所以当有新的节点加入后,需要重新给新加入的节点分配槽点,如下:
[root@node01 ~]# redis-trib.rb check 127.0.0.1:6379 #执行此命令进行确认新加入的节点时master
[root@node01 ~]# redis-trib.rb reshard 192.168.20.2:6379 #指定群集地址及端口
How many slots do you want to move (from 1 to 16384)? 4096
#若是四个master,那么平均值为4096,所以这里输入4096
What is the receiving node ID? 010752fb2527317a938fcb5b4e73822db805b3a1
#指定接收的节点,也就是新加入的node06主机上6380的那个实例的ID
Source node #1:all #指定从哪个节点的槽点分配,这里输入“all”选择所有节点
Do you want to proceed with the proposed reshard plan (yes/no)? yes #输入“yes”进行确认
至此,新的节点就添加完成了,并且分配了相应的槽点,但是...还没有从节点,所以接下来为新加入的master分配一个从节点。
分配从节点的方式有两种,一种是不指定为哪个master的从节点,自动绑定到没有从节点的master上,一种是直接指定绑定到哪个master上,这里将这两种方式都写下来。
#方式一:
[root@node01 ~]# redis-trib.rb add-node --slave 192.168.20.7:6381 192.168.20.7:6380
#将node06上的6381实例以slave的身份加入到群集
#注意,返回的信息不可有红色字样,那就说明有错误
[root@node01 ~]# redis-trib.rb check 192.168.20.2:6379
#查看确认新加入的slave是否与node06的6380master实例绑定
#方式二:
[root@node01 ~]# redis-trib.rb add-node --slave --master-id 010752fb2527317a938fcb5b4e73822db805b3a1 192.168.20.7:6382 192.168.20.2:6380
#上述命令指定的ID就是6380实例的master的ID,直接指定为6380的slave节点
[root@node01 ~]# redis-trib.rb check 192.168.20.2:6379
#查看群集状态,可以看到master6380有两个slave了,都是上面新加入的slave
删除主节点的操作其实就是把添加主节点的操作反了过了,需要先将要删除的主节点上的槽点分配给其他master,然后才可以执行删除操作,并且删除主节点后,该master对应的slave也将会随着slots槽进行转移到新的master上。
这里以移除node06上的6380实例为例。
#移除6380实例上的槽点
[root@node01 ~]# redis-trib.rb reshard 192.168.20.2:6379 #指定群集监听地址
How many slots do you want to move (from 1 to 16384)? 4096 #输入要删除多少槽
What is the receiving node ID? 5cd3d0eec161a7bcc785202397fd8363074ae9c2
#这里指定的是删除主节点后,主节点上的槽分配给谁?这里写了node02的6379实例的ID
Source node #1:010752fb2527317a938fcb5b4e73822db805b3a1
#这里指定的是要删除哪个主节点?指定的ID是node06上6380实例的ID
Source node #2:done #输入done表示结束
Do you want to proceed with the proposed reshard plan (yes/no)? yes
#输入“yes”表示确认
#移除槽点后,接下来将6380实例从群集中移除,如下:
[root@node01 ~]# redis-trib.rb del-node 192.168.20.2:6379 010752fb2527317a938fcb5b4e73822db805b3a1
#上面指定的是6380实例的ID
至此,6380实例就被彻底移除群集了,并且原本与之对应的slave也随着槽点转移到node02也一起成为了node02的slave。现在查看群集信息,node02的master应该是对应了三个slave。
关于Redis群集部署应该怎么做就分享到这里了,当然并不止以上和大家分析的办法,不过小编可以保证其准确性是绝对没问题的。希望以上内容可以对大家有一定的参考价值,可以学以致用。如果喜欢本篇文章,不妨把它分享出去让更多的人看到。
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。