Redis哨兵5.0.3（Sentinel）模式

Sentinel模式简介

以下描述来自：https://www.cnblogs.com/xintiao-/p/10414742.html

Redis-Sentinel是redis官方推荐的高可用性解决方案，
当用redis作master-slave的高可用时，如果master本身宕机，redis本身或者客户端都没有实现主从切换的功能。

而redis-sentinel就是一个独立运行的进程，用于监控多个master-slave集群，
自动发现master宕机，进行自动切换slave > master。

sentinel主要功能如下：

• 不时的监控redis是否良好运行，如果节点不可达就会对节点进行下线标识
• 如果被标识的是主节点，sentinel就会和其他的sentinel节点“协商”，如果其他节点也人为主节点不可达，就会选举一个sentinel节点来完成自动故障转义
• 在master-slave进行切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换

测试环境介绍

测试环境为centos7.5

A机器ip：10.0.8.37

B机器ip：10.0.8.243

Redis版本：5.0.3

在这之前，我们分别在A机器和B机器上运行Redis服务，此刻他们均为master节点

Sentinel部署环境流程介绍

文字描述还可以参考：https://www.cnblogs.com/kevingrace/p/9004460.html

开始部署

如果你使用是的redis源代码安装形式安装的Redis，那么在解压出来的目录下，有一个名为sentinel.conf的配置文件，该文件就是用来配置sentinel的，拷贝一份，放到~目录下

前提：无故障时A机器Redis充当master节点，B为slave节点（无论是使用.conf写slave节点还是使用redis-cli配置均可）

首先做做一下我们的设想

• 设想2：此时A机器上面的Redis挂掉了，那么B机器此时应当切换为master节点节点
• 设想3：过了一段时间A机器的Redis恢复了，B机器又应该变成slave节点

为了完成上面的设想，先来进行配置，然后再去测试是否成功

对A机器的操作

创建文件夹redis_data

mkdir /home/zeng/redis_data

修改配置文件sentinel.conf

daemonize yes

logfile "26379.log"

dir "/home/zeng/redis_data"

sentinel monitor mymaster 10.0.8.37 6379 2

用redis-sentinel sentinel.conf启动A机器上的哨兵

查看一下当前A机器的redis信息

redis-cli info replication

可以看到如下

对B机器的操作

创建文件夹redis_data

mkdir /home/zeng/redis_data

修改配置文件sentinel.conf

daemonize yes

logfile "26379.log"

dir "/home/zeng/redis_data"

sentinel monitor mymaster 10.0.8.37 6379 2

用redis-sentinel sentinel.conf启动A机器上的哨兵

注意这里，在A和B机器上，都是同时监听A机器上的redis是否有响应

redis-cli info replication查看一下当前A机器的Redis信息，再过个几秒运行，发现B机器的Redis从master自动切换成了slave节点

此时设想1已经成功

开始测试

完成设想2

执行ps -ef|grep redis-server|grep -v grep|awk '{print $2}'|xargs sudo kill -9命令，退出redis-server

在B机器上用redis-cli info replication查看一下当前机器的Redis信息

已经自动切换到了master节点

此时设想2已经成功

完成设想3

此时我们在B机器上设置一个值

在A机器上，重启redis

再次查看A机器上的Redis信息，发现此时，A是B的slave节点，此时也能取出之前设置的值

所以设想3，需要更改一下：

设想3：过了一段时间A机器的Redis恢复了，~~B机器又应该变成slave节点，~~A机器此时会作为B机器的备用节点存在，这样才能使用故障时间内所存储的数据

所以，之前的设想，变成了结论：

• 结论1：无故障时A机器Redis充当master节点，B为slave节点
• 结论2：此时A机器上面的Redis挂掉了，那么B机器此时应当切换为master节点节点
• 结论3：过了一段时间A机器的Redis恢复了，B机器又应该变成slave节点；只有此时B机器出故障，A才又会变成master节点

有兴趣的朋友可以自己动手验证以下以上的步骤

使用keepalived完成哨兵模式

keepalived相对于使用Sentinel来说会比较麻烦，监听的脚本需要自己来写

具体keepalived来做哨兵的实现可以参考：https://www.cnblogs.com/binchen-china/p/5593451.html

因为链接提供gayhub地址中的脚本源码已经找不到，所以你只能按照blog文中的内容来复制粘了

还有其他的keepalived完成哨兵模式有：
使用Python脚本，slave一直ping Redis服务器，如果发现ping不同master，用命令调用redis-cli slave none形式来是当前节点变为master节点；如果恢复过来，用命令调用redis-cli slave ip 6379变成slave

需要特别注意防火墙在A、B服务器中的配置

务必相互打开6379和26379

更多的命令可参考

官网文档地址：http://redisdoc.com/topic/sentinel.html