【Redis一主(master)二从(slave)复制及哨兵模式实践学习】

Redis一主(master)二从(slave)复制及哨兵模式实践学习

知识回顾:

通过对Redis中的String的命令做了充分的讲解以及实践学习
通过对Redis中String类型之Bit命令的详解以及Bit命令的实践进行了学习
通过对Redis中的Hash类型以及Hash中常用命令的实践学习
通过对Redis之List类型的详解&List类型中常用命令的实践的学习
通过对Redis之Set类型的详解&Set类型中常用命令的实践的学习
通过对Redis之ZSet类型的详解&ZSet类型中常用命令的实践的学习
通过对Redis中消息的发布和订阅以及命令的实践学习
通过对Redis中事务Multi命令及监控键值Watch命令的实践学习
通过对Redis持久化原理之快照版本RDB的学习
通过对Redis持久化原理之AOF(Append Only File)的学习
通过对Redis主从复制原理以及搭建一主俩从集群实践的学习
接下来的学习任务:
接下来我们要学习的内容是:Redis一主(master)二从(slave)复制及哨兵模式实践学习。

Redis中String类型内容请看这里呦:
【Redis之String类型的详解&String类型中常用命令的实践】
Redis中String类型是Bit命令内容请看这里呦:
【Redis中String类型之Bit命令的详解&Bit命令的实践】
Redis之Hash类型的详解&Hash类型中常用命令的实践请看这里呦:
【Redis之Hash类型的详解&Hash类型中常用命令的实践】
Redis之List类型的详解&List类型中常用命令的实践请看这里呦:
【Redis之List类型的详解&List类型中常用命令的实践】
Redis之Set类型的详解&Set类型中常用命令的实践请看这里呦:
【Redis之Set类型的详解&Set类型中常用命令的实践】
Redis之Zset类型的详解&Zset类型中常用命令的实践请看这里呦:
【Redis之ZSet类型的详解&ZSet类型中常用命令的实践】
Redis中消息的发布和订阅以及命令的实践请看这里呦:
【Redis中消息的发布和订阅】
Redis中事务Multi命令及监控键值Watch命令的实践请看这里呦:
【Redis中事务Multi命令及监控键值Watch命令】
Redis持久化原理之快照版本RDB的学习请看这里呦:
【Redis持久化原理之快照版本RDB】
Redis持久化原理之AOF(Append Only File)的学习请看这里呦:
【Redis持久化原理之AOF(Append Only File)】
Redis主从复制原理以及搭建一主俩从集群实践的学习请看这里呦:
【Redis主从复制原理以及搭建一主master俩从slave集群实践】

Redis的一主二从的部署请看前面的章节呦，接下来会利用之前Redis的一主二从来部署并学习Redis的哨兵模式，可以看这里呦:

【Redis主从复制原理以及搭建一主master俩从slave集群实践】

Redis的一主二从之哨兵模式

如果Redis中的master宕机了，那么整体的服务就不可以使用了，此时我们希望系统能在还运行的slave中从新选举新的节点作为mater，这样我们就不用重启服务了。能够显著的提高我们系统的稳定性，这里就需要用到我们将要介绍的哨兵模式。

sentinel的配置注意事项

sentinel中文含义为哨兵，顾名思义，它的作用就是监控redis集群的运行状况，特点如下：

• sentinel模式是建立在主从模式的基础上，如果只有一个Redis节点，sentinel就没有任何意义
• 当master挂了以后，sentinel会在slave中选择一个做为master，并修改它们的配置文件，其他slave的配置文件也会被修改，比如slaveof属性会指向新的master
• 当master重新启动后，它将不再是master而是做为slave接收新的master的同步数据
• sentinel因为也是一个进程有挂掉的可能所以sentinel也会启动多个形成一个sentinel集群
• 多sentinel配置的时候，sentinel之间也会自动监控
• 当主从模式配置密码时，sentinel也会同步将配置信息修改到配置文件中，不需要担心
• 一个sentinel或sentinel集群可以管理多个主从Redis，多个sentinel也可以监控同一个redis
• sentinel最好不要和Redis部署在同一台机器，不然Redis的服务器挂了以后，sentinel也挂了

哨兵模式的工作机制

每个sentinel以每秒钟一次的频率向它所知的master，slave以及其他sentinel实例发送一个 PING 命令

• 如果一个实例距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被sentinel标记为主观下线。
• 如果一个master被标记为主观下线，则正在监视这个master的所有sentinel要以每秒一次的频率确认master的确进入了主观下线状态
• 当有足够数量的sentinel（大于等于配置文件指定的值）在指定的时间范围内确认master的确进入了主观下线状态， 则master会被标记为客观下线
• 在一般情况下， 每个sentinel会以每 10 秒一次的频率向它已知的所有master，slave发送 INFO 命令
• 当master被sentinel标记为客观下线时，sentinel向下线的master的所有slave发送 INFO 命令的频率会从 10 秒一次改为 1 秒一次
• 若没有足够数量的sentinel同意master已经下线，master的客观下线状态就会被移除；
• 若master重新向sentinel的 PING 命令返回有效回复，master的主观下线状态就会被移除

Redis哨兵模式的实践部署

首先通过命令启动一个主机(redis:6379)，二个主机(redis:6380/(redis:6381))，并将二个主机的master设置为(redis:6379)，前面的章节学习过，此处直接跳过

然后通过命令分别进入三个容器，查看此时每个容器中对应的节点信息

# 6379  主机
docker exec -it redis redis-cli
info replication

# 6380  从机1
docker exec -it redis6380 redis-cli
info replication

# 6381  从机2
docker exec -it redis6381 redis-cli
info replication

redis哨兵模式说明

使用docker启动3个redis服务器，一个master（主）, 两个slave （从），进行主从配置。
3台redis服务器分别启动一个哨兵sentinel。

第一步：【master–6379容器配置哨兵】:

docker exec -it  redis /bin/bash
#cd / （进入根目录）
#apt-get update (更新依赖)
#apt-get install -y vim (安装vim)
#vim sentinel.conf  (建立sentinel（哨兵模式）的配置文件，保存退出，内容如下：)
port 26379 (指定哨兵监听端口)
dir "/data"  #sentinel工作目录
logfile "sentinel.log"  #日志文件
sentinel monitor name 172.17.0.3 6379 2 #启动哨兵(名称：name) 监听master
# 后面这个数字2的意思是:当有俩个及以上的sentinel监测到master宕机，才会去执行主从切换
daemonize yes #后台运行
#

# 启动哨兵：
redis-sentinel sentinel.conf

以master为例，结果展示，其它俩台同理，就不一个一个展示了:
按照上述的命令操作:

sentinel.conf配置文件的编写

启动redis-sentinel sentinel.conf

第二步：【slave–6380容器配置哨兵】:

docker exec -it  redis6380 /bin/bash
# 进入根目录
cd /
# 更新依赖
apt-get update
#安装vim
apt-get install -y vim 
#建立sentinel（哨兵模式）的配置文件 
vim sentinel.conf  
# 保存退出，内容如下：
port 26380 (指定哨兵监听端口)
dir "/data"  #sentinel工作目录
logfile "sentinel.log"  #日志文件
sentinel monitor name 172.17.0.3 6379 2 #启动哨兵(名称：name) 监听master
daemonize yes #后台运行
#

# 启动哨兵：
redis-sentinel sentinel.conf

第三步：【slave–6381容器配置哨兵】:

docker exec -it  redis6381 /bin/bash
# 进入根目录
cd /
# 更新依赖
apt-get update
#安装vim
apt-get install -y vim 
#建立sentinel（哨兵模式）的配置文件 
vim sentinel.conf  
# 保存退出，内容如下：
port 26381 (指定哨兵监听端口)
dir "/data"  #sentinel工作目录
logfile "sentinel.log"  #日志文件
sentinel monitor name 172.17.0.3 6379 2 #启动哨兵(名称：name) 监听master
daemonize yes #后台运行
#

# 启动哨兵：
redis-sentinel sentinel.conf

验证环节

进入master容器，查看主节点以及从节点的信息

docker exec  -it redis redis-cli
info replicaton

同理进入slave1和slave2容器，查看从节点slave1和slave2的信息

docker exec  -it redis6380 redis-cli
info replicaton

docker exec  -it redis6381 redis-cli
info replicaton

停止主节点master，再次进入slave1和slave2容器，查看从节点slave1和slave2的信息，发现slave2–6381被选为master

重新启动我们redis的master容器，发现它会成为redis6381的从节点，并不会重新成为主节点

Redis哨兵模式存在的问题

注意在主从复制中所有的写入操作都是在master实例上进行的，然后再将信息同步到slave上，这就存在一定的信息延迟，在系统非常繁忙的时候延迟会更加的严重，增加slave也会存在这个问题，因此在实际开发中我们需要通过集群(cluster)来进一步提升redis的性能，接下来继续为大家更新redis的集群操作。