目标:
从0到1搭建一个redis的哨兵sentinel模式集群
内容:
一、准备工作
- 安装Centos7系统
- 在官网下载最新版的redis(目前是6.0.9)
- 在Centos7系统的任意目录下建一个任意文件夹,并将redis通过xftp工具上传指定文件夹
二、开始安装
1、开始之前,需要先升级一下你系统的gcc工具。(如果你的系统没有自带gcc,那么需要先下载)因为redis6版本需要gcc5.3以上的版本支持。而Centos7自带的gcc是4.xx版本。否则待会编译redis源码的时候会报错。
#直接升级到当前最新版本
yum -y install centos-release-scl
yum -y install devtoolset-9-gcc devtoolset-9-gcc-c++ devtoolset-9-binutils
scl enable devtoolset-9 bash
#注意:scl命令启用只是临时的,推出xshell或者重启就会恢复到原来的gcc版本。
#如果要长期生效的话,执行如下:
echo "source /opt/rh/devtoolset-9/enable" >>/etc/profile
2、安装好所需环境以后,进入你的redis压缩包所在地方直接解压缩。然后进入解压后的文件夹
tar -zxvf redis-6.0.9.tar.gz
cd redis-6.0.9
出现如下效果图:
3、接下来就可以正常的编译了,先make后make install(执行这两个命令都会出现一大堆命令输出。仔细检查一下,看是否有报错)
make
make install
4、正常编译安装完后,redis会被安装进上图的src目录里。至于为什么在src下面,可以去看一下上图的Makefile文件,里面有原因!
5、src下面只要有上面这些绿色的文件出来。说明就安装成功了!
三、搭建主从
这里要特别说明一下,redis部署模式总共分为四种:
- 单机版
- 主从版
- 哨兵版
- 集群版
我们刚刚完成安装的就是单机版;主从版则是需要最少两个redis实例形成一主一从或一主多从,主写从读;哨兵版是在主从的基础上新增了一个或多个sentinel进程。用来监控redis实例;集群版跟主从、哨兵都有些不同。集群模式里没有从主从节点的区分,所有的节点都可以用来“读和写”。去中心化配置。
开始搭建
1、复制两份redis.conf文件,给它命名:redis-slave1.conf 和 redis-slave2.conf
cp redis.conf redis-slave1.conf
cp redis.conf redis-slave2.conf
2、修改两个slave.conf的配置信息
slave1.conf
bind 0.0.0.0
port 6380
daemonize yes
replicaof masterIp masterPort(示例:replicaof 127.0.0.1 6379)
slave2.conf
bind 0.0.0.0
port 6381
daemonize yes
replicaof masterIp masterPort(示例:replicaof 127.0.0.1 6379)
3、两个从实例配置好了以后,分别启动三个(加上默认6379)实例
./redis-server redis**.conf
4、这样,redis的主从就配置好了。如下图:
我这里6380是主,79和81是从。从库只能读,不能写!
四、哨兵集群
上面说过,哨兵模式是在主从的基础上构建来的。那为什么会有哨兵模式,它解决了什么问题?
主从模式相对来说并没有很高的可用性,万一主实例因为不可抗力因素挂了,那么所有的redis写入操作都将失败。这个时候就需要人为去将其中一台slave升为master,并且其他所有slave的配置文件都要手动改 replicaof 的指向地址。这还不是最致命的,最致命的是代码里连接的redis信息也要改
基于这点,为了保证你的集群环境高可用。就必须使用Sentinel模式,它的好处是有单独的一个(通常是多个)sentinel实例去监控你的master实例、slave实例。一旦监控到你master服务不可用,它会迅速通过投票、选举(多个sentinel实例之间)出一个salve升为master。并且自动会将其他所有的slave里 replicaof 指向改为选举出来的leader。当你挂了的“主”实例起来后,也会降为slave。自动追随上leader。
这样就解决了刚刚主从的问题,保证了你的集群环境高可用性。任何一台实例宕机都不会影响服务的提供。
开始搭建
1、 回到你之前redis解压后有redis.conf配置文件的目录。同级下有一个叫sentinel.conf的文件
2、跟redis.conf一样,复制两份sentinel-slave1.conf 、sentinel-slave2.conf用作sentinel集群搭建(共三份)
cp sentinel.conf sentinel-slave1.conf
cp sentinel.conf sentinel-slave2.conf
3、修改三个sentinel**.conf文件
port 26379 26380 26381 ##分别三个端口
daemonize yes ##以后台运行
sentinel monitor <master-name> <ip> <redis-port> <quorum>
示例:sentinel monitor mymaster 127.0.0.1 6379 2
- 《master-name》 redis-master 服务名
- 《ip》redis-master IP地址
- 《redis-port》redis-master 端口
- 《quorum》最少需要多少个sentinel实例同意(判断master是否宕机)
这里要注意,三个配置文件,只有端口不一样。且,sentinel monitor 只需要设置redis-master实例的配置就好了。监控了master,sentinel会自动去找slave监控。
到这里就配置完成。
校验结果
1、先启动redis所有的主、从实例(上面已经启动好了)。然后再启动sentinel集群
./redis-sentinel sentinel.conf
./redis-sentinel sentinel-slave1.conf
./redis-sentinel sentinel-slave2.conf
2、因为我们设置了daemonize后台启动。控制台看不到后台信息,所以想检验结果。我们可用直接关闭redis-master实例。然后过大概几秒钟,回到剩下的两台slave实例里去查看。会发现,其中某一台slave已经变成了master。且另外一台slave指向的地址也改为了新master的地址
先关闭主redis服务
./redis-cli -p 6379
shutdown
过一会再去其他两台从实例查看
./redis-cli -p 6380
info replication
./redis-cli -p 6381
info replication
这个时候发现:剩下的两台slave中,6380成了master。6381追随6380。然后我们再将之前的老大6379服务启动。
./redis-server redis.conf
info replication
老大变成了小弟!所以这就是我上面,一开始的master是6379,后面又变成6380的原因!
结束:
到此!哨兵模式集群搭建就完成,但在哨兵模式之上,还有另外一个Cluster集群模式!!!