目录
第三步:接着进行脚本安装(直接执行并生成多个Redis实例)
一、Redis官网
二、Redis优势
Redis也称NoSQL,实际生产环境中和MySQL整合在一起使用。Redis由于是在内存中运行,因此它的有点很明显,就是快。常用于峰值流量很大的情况,例如电商、抢票等等。
三、Redis安装
第一步:下载并解压Redis压缩包
第二步:编译并安装
先<make USE_SYSTEMD=yes>编译。
make USE_SYSTEMD=yes #systemd安装
再<make install>直接安装
make install
第三步:接着进行脚本安装(直接执行并生成多个Redis实例)
如果直接启用脚本的话,程序会自动检测电脑硬件是否符合要求,并给出推荐的安装方式。所以可以按以下方法取消检测,可以直接安装。
修改完成后,重新启用脚本。一路回车,可以直接直接安装成功。
通过这个脚本可以非常快速地生成Redis示例。需要生成其他示例时,在执行脚本后的第一步输入一个新的序号即可
关闭Redis
由于执行脚本安装时会自动生成systemd命令,所以可以直接通过此命令启动或关闭redis。
/etc/init.d/redis_6380 stop #关闭redis_6380实例
第四步:更改redis配置
由于程序默认只允许<127.0.0.1>回环接口,如果要通过远程客户端访问的话,需要改接口。
编辑redis_6379的配置文件,将其中的回环接口改为<0.0.0.0>,表示允许所有IP访问。
重启redis_6379
/etc/init.d/redis_6379 restart
第五步:查看redis——master端
<redis-cli>命令可以很方便地管理redis。进入后输入<info>,可以查看redis的一些基本细细。
info中也可以查到master和slave信息。
第六步:创建redis——slave端
因为这个源码所在的平台都是一样的,所以可以直接复制到server2中。
在server2中直接<make install> 后。通过<install_server.sh >脚本直接生成redis(使用默认)。
接下来的步骤和之前一样:修改配置文件的端口;重启redis的服务。
第七步:配置redis——slave端
按照之前的方法安装好server2的redis后,默认也是一个master。因此要更改配置使其成为一个slave。
在<redis-cli>内部,输入<config get *>,可以查看slave状态。这里查到的server2的slave状态是关闭的。
更改server2的配置文件,向其中添加<replicaof 172.25.254.1 6379>。指向master的IP及端口。
重启server2的redis后,进入redis-cli内部,查看信息,显示server2已经成为了一个slave节点,并且它的master是<172.25.254.1>。
第八步:测试redis
在master端定义一个“name”,在slave端可以直接查询到。但是slave只能读不能写。
注意:通过redis创建slave节点时,会丢掉slave端的所有数据!!!以做到跟master端完全一样,不需要像mysql那样同步、授权等。
四、redis常用指令
config get * | 查看配置 | select 1 | 选择数据库 |
flushdb | 清空当前数据库 | flushall | 清空所有数据库 |
move key 1 | 移动key | del key | 删除 |
rename oldkey newkey | 改名 | expire key 10 | 设置过期时间 |
persist key | 设置持久化 | keys user* | 查询 |
exists key | 判断是否存在 |
<select 1>选择数据库,默认有16个数据库,序号从0到15
<flushdb>:清空当前数据库
<expire name 5>:设置5秒过期时间(设置过期时间的好处在于免维护)
<keys user*>:查询关键字。
五、redis主从复制原理及高可用设置,并实现自动主从切换
第一步:设置最小可写slave
config get min-slaves-to-write #查看后端有多少可写的slave
一般来说,这个值最小应该为2。这样设置的原因是: 当master和slave之间出现故障(网络连接中断等),客户端感知不到,仍然会向master中写数据,但是此master已经脱离集群了;所以必须从集群中的slave中重新选择一个master。但是这将导致集群中的主从设置全部都发生变更,之前的master恢复正常后重新接入集群中,就只能作为新选择的master的一个slave,从master切换到slave状态后,将会flushall清除本机所有数据,因此将会导致原本客户端写入的数据丢失。
因此<min-slaves-to-write>参数必须为1或者2,以保证master出现故障时后端有slave可用,否则将不允许客户端向master中写入数据。
第二步:更改配置文件
为了解决上述问题,可以在配置文件或redis-cli内部设置。
更改配置文件(永久生效):
其中<min-replicas-max-lag>表示与slave失联10秒即放弃该slave
redis-cli内部设置(热生效、重启后还原):
127.0.0.1:6379> config set min-slaves-to-write 2 #设置最小可写slave数量为2
第三步:新增一个slave端
由于在master中设置的最小slave数量为2,因此需要再开一个server3作为sredia的slave端。具体操作和之前server2的步骤一样,注意设置<bind 0.0.0.0>和<replicaof 172.25.254.1 6379>。设置完成后重新启动redis。
如下图所示:设置成功
在master中可以看到先在已经有两个slave端了
第四步:高可用配置——sentinel.conf
REDIS sentinel-old -- Redis中国用户组(CRUG)redishttp://redis.cn/topics/sentinel.html首先将redis解压包中的<sentinel.conf>配置文件复制到redis的配置目录中,操作方法如下:
然后编辑高可用配置文件<sentinel.conf>
第84行表示:监控172.25.254.1的6379端口,只有当两票认为master挂掉了,才最终确定master与slave失去连接
第125行表示,等待连接10秒后仍然连接不上则可以判定master与slave失去连接。
第225行表示整个故障切换的超时时间为180秒
再然后,将修改后的这个文件复制到集群中其他slave(server2和server3)中。
第五步:启动高可用程序sentinel
redis-sentinel /etc/redis/sentinel.conf #读取配置文件
这时可以查看到一个master和两个slave端,证明master端的sentinel已启动成功。
启动成功后查看server1中的sentinel配置文件,文件的最后已经发生改变!!!
第六步:测试
在server2和server3中都启用sentinel。
注意:master和slave中的sentinel配置文件必须一致。因为master启动sentinel后配置文件会发生变动,因此server2和server3中的配置文件在master启动sentinel之前就应该复制过去。
redis-sentinel /etc/redis/sentinel.conf
以server3为例,启动sentinel后可以看到集群中已经有了三个sentinel了。
继续测试:
查看server1的master是好的,这时让master产生故障(也就是关闭master的redis)
127.0.0.1:6379> shutdown #redis内部执行,关闭redis
关闭server1的redis后,可以看到server1的sentinel已经检查出了当前的master故障,因此从剩余的两个slave中投票选举出一个节点当作新的master,这里的信息显示选择出了server2作为新的master,同时将server1和server3作为新的slave,接着检查出了server1已经down掉了。
所以目前的结构为:server2为master,server1和server3作为slave,且server1已经挂掉。
使用server1连接server2的远程,查看server2的redis信息,可以看到server2目前作为master,且只有一个slave可用。
redis-cli -h 172.25.254.2
再接着测试:
重新启动server1中的redis,sentinel信息显示server1恢复以后,加入集群中将以server2为master
在server1的redis-cli中查看信息,确实如此。以server2为master。