序言

本篇文章是在配置完主从的基础进行操作的，如不会请点击查看配置过程部署Redis的主从复制

这篇文章主要说明哨兵的配置，主从复制后带来的问题，以及使用哨兵进行解决

1. 主从复制带来的问题

在进行Redis的主从配置时，没有考虑当主机master宕机。如果发生宕机，我们需要人工解决切换，使用slaveof no one。实际上主从复制并没有实现高可用。高可用侧重备份机器，利用集群中系统的冗余，当系统中某台机器发生损坏的时候，其他后备的机器可以迅速的接替它来启动服务

如下图所示：一旦master宕机，服务无法使用，就需要手动切换，重新选取主节点，手动设置主从关系

那么这个问题就需要我们今天写的哨兵来解决，它可以监控各个机器的状态及时做出调整，将手动的操作变成自动的。

2. 哨兵简单介绍

Redis Sentinel 是一个分布式架构，其中包含若干个 Sentinel 节点和 Redis 数据节点，每个 Sentinel 节点会对数据节点和其余 Sentinel 节点进行监控，当它发现节点不可达时，会对节点做下线标识。如果被标识的是主节点，它还会和其他 Sentinel 节点进行“协商”，当大多数 Sentinel 节点都认为主节点不可达时，它们会选举出一个 Sentinel 节点来完成自动故障转移的工作，同时会将这个变化实时通知给 Redis 应用方。整个过程完全是自动的，不需要人工来介入，所以这套方案很有效地解决了 Redis 的高可用问题。

如下图所示：可以看到客户端并没有直接连接master主机，而是连接的是sentinel

3. 配置哨兵

1、我们需要先搭建一个整体的架构，配置好一台主机跟三台从机，并配置好主从关系，主从不会配置的看序言部分

2、结构图

3、配置哨兵

把三台哨兵服务器全部修改为一下配置

sentinel monitor mymaster 172.10.0.2 6379 2

监控的主节点的名字、IP 和端口，最后一个2的意思是有几台 Sentinel 发现有问题，就会发生故障转移，例如 配置为2，代表至少有2个 Sentinel 节点认为主节点不可达，那么这个不可达的判定才是客观的。对于设置的越小，那么达到下线的条件越宽松，反之越严格。一般建议将其设置为 Sentinel 节点的一半加1

配置完哨兵之后可以查看日志

4.查看哨兵过程

1、现在的slave2是一台主机

2、干掉slave2这台机器

先使用docker top slave2

在使用kill 18906即可

干掉之后需要重启我们的容器啊！切记

3、在来查看我们的主从连接情况

可以看到主节点又回到了master这台服务器上

这样我们的哨兵就配置好了，这只是简单地进行了配置，体验一下哨兵机制。后期还会说明更多的优化配置

5. 查看哨兵状态

使用你的主机随便连接一台哨兵服务器

redis-cli -h 172.10.0.6 -p 26379

文章来源: blog.csdn.net，作者：咔咔-，版权归原作者所有，如需转载，请联系作者。

原文链接：blog.csdn.net/fangkang7/article/details/100991949