redis在我们工作中是非常重要的，由于网络的不可靠性，随时会有故障发生，所以使用单机的redis存在机器宕机的危险，此时我们可以给redis做一个主从复制，用一个从服务器作为备份机器。
本次搭建是在centOS7上面进行搭建，我们首先上传一个redis5.0+的安装包到服务器上，解压之后，由于本次暂时是模拟搭建，所以只在一台服务器上进行搭建，
首先将redis5.0bin目录下的redis.conf文件复制一份为redis6380.conf
cp redis.conf redis6380.conf
然后去修改redis6380.conf里面的配置
#修改端口
port 6380
pidfile /var/run/redis_6380.pid
logfile "6380.log"
#创建一个存放日志log的路径
dir /usr/local/redis‐5.0/data/6380
3、配置主从复制
replicaof 192.168.56.102 6379 # 从本机6379的redis实例复制数据
replica‐read‐only yes同时要把主配置文件和6380的配置文件的bind进行修改 注释掉 bind 127.0.0.1
#bind 127.0.0.1
启动两个redis实例
#启动redis主服务
./redis-server redis.conf
#启动redis从服务
./redis-server redis6380.conf接下来启动查看一下redis线程实例
ps -ef|grep redis
两个线程启动完毕。
接着我们去主线程里面插入一个数据，然后在从线程里面也可以看到了。
[root@localhost bin]# ./redis-cli -p 6379
127.0.0.1:6379> set helloredis hello
OK
127.0.0.1:6379>
[root@localhost bin]# ./redis-cli -p 6380
127.0.0.1:6380> get helloredis
"hello"
127.0.0.1:6380>
上面 我们成功的搭建了如何配置一个主从的redis实例，但是如果主服务器宕机了，从服务器是无法提供写服务的，所以相当于无法对外提供服务，为了解决高可用的问题，这里我们需要对主从的架构配置redis的哨兵，能够实现redis实例的选举。
按照上面的方式重新搭建一个6381的实例，实现一主两从的架构。
但是当在创建第二个实例的时候遇到了一个问题。第二个从节点无法被主节点绑定
然后最后找到原因就是因为上面把bind隐藏的原因 所以后面去主节点里面把配置修改为开放全部端口
bind 0.0.0.0问题解决了。
接下来搭建哨兵
复制一份sentinel.conf文件
cp sentinel.conf /usr/local/redis/config/sentinel‐26379.conf修改里面的配置信息
port 26379
daemonize yes
pidfile "/var/run/redis‐sentinel‐26379.pid"
logfile "26379.log"
dir "/usr/local/redis/data"
# sentinel monitor <master‐name> <ip> <redis‐port> <quorum>
# quorum是一个数字，指明当有多少个sentinel认为一个master失效时(值一般为：sentinel总数/2 +1)
#，master才算真正失效
sentinel monitor mymaster 192.168.56.102 6379 2接下来启动哨兵进程
./redis-sentinel ../config/sentinel‐26379.conf查看进程
看一下我的bin目录
看一下redis目录 可能和有的小伙伴不太一样
按照上面的方式再配置26380和26381另外两个哨兵吧
然后我们进入一个sentinel里面去查看一下Info信息
./redis-cli -p 26381
info
发现出了一个问题 明明配置了三个sentinels 怎么上面显示sentinels=1呢？ 后来发现在配置文件中有sentinel myid这一行 当时复制的时候也复制过来了，我们把这行注释掉
修改了文件之后分别进入26380和26381执行shutdown命令 关闭然后再从新启动redis-sentinels实例。
启动后，进入sentinel实例里面就可以看到有三个sentinel了
redis的哨兵架构这里也已经搭建完毕了。