redis主从、哨兵架构搭建

一、安装环境

说明：由于是我刚刚搭建好的虚拟机，需要先安装JDK和gcc环境。

1.安装JDK

链接：https://pan.baidu.com/s/1MPN4wHZBV35UTHUqttVdfw
提取码：baba
在/usr/local下创建java文件夹，将文件上传到此目录下，执行tar -zxvf jdk-8u51-linux-x64.tar.gz解压即可。
解压后，需要配置环境变量。执行vi /etc/profile，配置三个变量，然后执行导入。

JAVA_HOME=/usr/local/java/jdk1.8.0_51
CLASSPATH=$JAVA_HOME/lib/
PATH=$PATH:$JAVA_HOME/bin
# export 导入当前虚拟机的环境变量中
export PATH JAVA_HOME CLASSPATH

最后让环境变量生效就可以了。

#让环境变量生效
source /etc/profile

执行java -version看到版本号就说明环境安装成功了。用env命令可以看到此前配置的环境变量。

2.安装gcc

yum install gcc

3.安装redis

在/usr/local/目录下创建redis-sentinel文件夹。

#在/usr/local/redis-sentinel目录下下载redis
wget http://download.redis.io/releases/redis‐5.0.3.tar.gz
#解压
tar -zxvf soft/redis-5.0.3.tar.gz
#进入解压好的目录 
cd /redis-5.0.3 
# 进行编译与安装
make
# 修改配置
vi redis.conf

port 6379
pidfile /var/run/redis_6379.pid # 把pid进程号写入pidfile配置的文件
daemonize yes #后台启动
protected‐mode no #关闭保护模式，开启的话，只有本机才可以访问redis
logfile "6379.log"
dir /usr/local/redis-sentinel/redis-5.0.3/data # 指定数据存放目录
# 需要注释掉bind
# bind 127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户
# 端通过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可）

# 启动服务
src/redis‐server redis.conf
# 验证启动是否成功
ps ‐ef | grep redis
# 进入redis客户端
src/redis‐cli

这里执行info命令可以看到此时我这个节点是单机模式的，我打算将他作为主节点，另外两台机器搭两个从节点。我这台机器的ip是192.168.199.222

二、搭建主从环境

1.配置从节点

在192.168.199.197和192.168.199.157两台机器上同样安装redis服务，修改其redis.conf配置文件。
需要告诉redis从哪台主节点上复制数据，并配置从节点只读。

port 6379
pidfile /var/run/redis_6379.pid # 把pid进程号写入pidfile配置的文件
daemonize yes #后台启动
protected‐mode no #关闭保护模式，开启的话，只有本机才可以访问redis
logfile "6379.log"
dir /usr/local/redis-sentinel/redis-5.0.3/data # 指定数据存放目录
# 需要注释掉bind
# bind 127.0.0.1（bind绑定的是自己机器网卡的ip，如果有多块网卡可以配多个ip，代表允许客户
# 端通过机器的哪些网卡ip去访问，内网一般可以不配置bind，注释掉即可）
replicaof 192.168.199.222 6379 # 从192.168.199.222的redis实例复制数据，Redis 5.0之前使用slaveof
replica‐read‐only yes # 配置从节点只读

配置完src/redis-server redis.conf启动两个从节点，src/redis-cli进去用info命令查看从节点状态。

可以看到，这样两台都是作为192.168.199.222的从节点，已成功启动。我们可以测试下，在主节点设置key，在从节点查看。


从节点可以读到a的值，但不能对其进行修改，也就达到了只读的效果。至此，一个简易版的主从架构就搭建完成了。但主从架构有一个致命的缺陷，就是单点故障问题。如果主节点宕机，从节点是不会进行master选举的。也就没有了写的服务，当然读的服务不会受到影响。可以简单测试下，下面我将主节点kill掉模仿主节点发生异常。


此时从节点没有发起选举，master的状态变成了down。哨兵机制就很好的解决了这个问题，下面我们开始搭建哨兵集群。

三、搭建哨兵环境

在所有节点中，编辑sentinel.conf配置文件。

vi sentinel.conf

port 26379
daemonize yes
pidfile "/var/run/redis‐sentinel‐26379.pid"
logfile "26379.log"
dir "/usr/local/redis-sentinel/redis-5.0.3/data"
# sentinel monitor <master‐redis‐name> <master‐redis‐ip> <master‐redis‐port> <quorum>
# quorum是一个数字，指明当有多少个sentinel认为一个master失效时(值一般为：sentinel总数/2 +
# 1)，master才算真正失效
sentinel monitor mymaster 192.168.0.60 6379 2 # mymaster这个名字随便取，客户端访问时会用
# 到

# 执行命令启动哨兵
 src/redis-sentinel sentinel.conf

三个节点依次启动后就可以在sentinel.conf文件的尾部看到节点信息和检测到的哨兵节点信息。

sentinel known‐replica mymaster 192.168.199.197 6379 #代表主节点的从节点信息
sentinel known‐replica mymaster 192.168.199.157 6379 #代表主节点的从节点信息
sentinel known‐sentinel mymaster 192.168.199.197 26379 c0d765f2b197ea58d5031b56183d0fd1bedba00d#代表感知到的其它哨兵节点
sentinel known‐sentinel mymaster 192.168.199.157 26379 a0d765f2b197ea58d5031b56183d0fd1bedba00d #代表感知到的其它哨兵节点

这时候我把主节点干掉，哨兵会发起选举投票，将从节点选举成为master。被干掉的master节点重新启动后会成为从节点。


此时192.168.199.197成为主节点。这样我们的哨兵架构也就搭好了。

但哨兵模式当master节点宕机到哨兵发起选举投票重新选举主节点的过程，是比较耗时的。这个可以自己验证下，我刚才把主节点kill掉，也没有很快选举到新的master。所以redis官方还推出了cluster的集群模式，这个有时间还会再记录下。

持续学习，持续分享中。。