前言
为什么需要哨兵集群
搭建前准备
搭建步骤
集群测试
前言在上一篇，我们了解了redis 复制集群的完整的搭建流程，本篇来分享一下如何搭建 redis 哨兵集群。
为什么需要哨兵集群redis哨兵集群要解决的问题是什么呢？搞清楚这个问题之后，就知道为什么需要哨兵集群了。我们知道，redis复制集群解决的是，高并发情况下，单节点的读性能瓶颈以及单节点问题；
但是复制集群的很明显的问题就是，当主节点挂掉后，集群将无法提供写业务，如果要恢复集群，则需要人工介入，这个必定会丢失数据不说，而且需要一定的时间；
而在哨兵模式下，集群的状态通过哨兵可以得到实时监控，一旦主节点宕机，哨兵会立即感知，然后选举出新的主节点，继续对外提供服务；
搭建前准备1、基于centos7 的虚拟机（或云服务器）；
2、redis 安装包（本篇基于6.X版本）；
搭建步骤本篇的集群将在同一台机器上搭建演示，通过不同的端口进行区分
1、准备（规划）三个sentinel实例
| s1 | 10.34.33.80 | 27001 |
| s2 | 10.34.33.80 | 27002 |
| s3 | 10.34.33.80 | 27003 |
2、创建3个文件目录
要在同一台虚拟机开启3个实例，必须准备三份不同的配置文件和目录，配置文件所在目录也就是工作目录。我们创建三个文件夹，名字分别叫s1、s2、s3；
mkdir s1 s2 s3
3、在s1目录下创建一个sentinel.conf文件
添加下面的内容：
port 27001
sentinel announce-ip IP
sentinel monitor mymaster IP 7001 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
dir "/tmp/s1"
配置文件解读：
port 27001：是当前sentinel实例的端口；
sentinel monitor mymaster 192.168.150.101 7001 2：指定主节点信息
mymaster：主节点名称，自定义，任意写；
IP 7001：主节点的ip和端口；
2：选举master时的quorum值
4、将s1/sentinel.conf文件拷贝到s2、s3两个目录中
在/tmp目录执行下列命令
cp s1/sentinel.conf s2
cp s1/sentinel.conf s3
5、修改s2，s3目录下的配置文件端口分别为27002、27003
在tmp目录下执行下面的命令
sed -i -e 's/27001/27002/g' -e 's/s1/s2/g' s2/sentinel.conf
sed -i -e 's/27001/27003/g' -e 's/s1/s3/g' s3/sentinel.conf
随机打开一个s2或s3目录下的文件，可以发现，配置文件已调整；
6、启动3个sentinel实例
在启动sentinel集群之前，先把上一篇的redis集群启动起来
进入到tmp目录，分别执行下面的命令进行启动
# 第1个
redis-sentinel s1/sentinel.conf
# 第2个
redis-sentinel s2/sentinel.conf
# 第3个
redis-sentinel s3/sentinel.conf
启动过程
通过输出日志，也可以看到，三个sentinel实例已经正常启动，并探测到 7001，7002，7003这三个redis实例，以及这三个redis实例的主从关系，即redis集群已经成功被sentinel集群监控起来；
到这里为止，整改哨兵集群大搭建过程就完成了，接下来，做一下集群的异常测试
集群测试将redis 7001这个服务实例强制下线
在下线的时候，注意分别观察sentinel的3个实例控制台的输出日志变化
从sentinel实例控制台的输出日志来看，主要经历了3个阶段：
认为7001这个redis实例主观下线；
当sentinel集群超过半数以上的实例认为7001这个节点下线时，变成客观下线；
发起投票，在剩下的2个redis实例中进行新的redis master的选举；
再次启动7001这个实例
通过sentinel控制台输出日志，可以看到，7001服务实例信息再次被sentinel集群探测到，即监控起来
需要注意的是，再次启动7001服务之后，7001这个redis实例不一定会再次成为master
到此这篇关于redis 哨兵集群搭建的实现的文章就介绍到这了,更多相关redis 哨兵集群搭建内容请搜索易知道(ezd.cc)以前的文章或继续浏览下面的相关文章希望大家以后多多支持易知道(ezd.cc)！
