这是我参与8月更文挑战的第30天，活动详情查看:8月更文挑战
哨兵模式
前面我们介绍了Redis的主从复制模式，通过主从复制模式，可以实现读的高可用，但无法实现写的高可用，当Redis主机宕机了则此时整个Redis集群无法写。这时我们就需要使用到主从切换技术，主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，但是这就需要人工的干预，费事费力，还会造成一段时间内服务不可用，好在Redis从2.8开始正式就提供了Sentinel(哨兵模式)，哨兵能够后台监控主机是否故障，如果主机故障了会通过选举指定集群中一个Redis服务器晋升成为主服务器Master，然后集群中的其他Redis服务器自动指向新的master同步数据，保证在任何情况下，都有主服务器可以支持写入操作，实现了Redis的高可用。哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，他可以独立运行，其原理是哨兵通过发送命令，等待集群中各Redis服务器的响应，从而监控运行的多个Redis实例。
以上是一个简单的哨兵模式，但该模式存在这样一个问题：如果一个哨兵监控一个Redis集群，在某些情况下，当哨兵崩掉了，那么就又回到了无哨兵的那种模式，则无法确保这个Redis集群的高可用，因此，可以使用多个哨兵对所有Redis服务器进行监控，各个哨兵之间还会进行相互的监控，这样就形成了多哨兵模式，如下图：
主观下线
所谓主观下线是指单个哨兵对服务器做出的下线判断。例如，假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行故障转移操作，因为仅仅哨兵1主观认为主服务器不可用，这个现象称为主观下线。
客观下线
客观下线就是指只有在足够数量的哨兵都将一个Redis服务器标记为主观下线之后， 该Redis服务器才会被标记为客观下线，只有当Redis服务器被认定为客观下线时，才会进行故障转移操作。
测试
下面我们搭建集群下的多哨兵模式
-
配置主从复制，同样的使用不同的redis.conf配置文件、端口号来启动三个Redis客户端进程，模拟主从复制，采用一主二从的模式，设定端口为6379的为主服务器、6381和6382为对应的从服务器。这里不再赘述、具体看上一篇文章Redis主从复制 (juejin.cn)
-
配置完主从复制之后，配置哨兵配置文件
sentinel.conf(在/usr/loacl/bin/Rconfig目录下新建哨兵配置文件sentinel.conf)，内容如下
#当前哨兵是用来监听主机为127.0.0.1端口为6379的主Redis服务器
# 2代表只有两个或者两个以上的哨兵认为主服务器不可用的时候，才会做故障切换操作
sentinel monitor myredis 127.0.0.1 6382 2
#禁止保护模式 protected-mode no
#哨兵端口
port 26379
user default on nopass sanitize-payload ~* &* +@all
dir "/usr/local/bin"
sentinel myid bdeaad27a235eca01cf5210084b4b5a850ff2dfa
sentinel config-epoch myredis 1
sentinel leader-epoch myredis 1
sentinel current-epoch 1
sentinel known-replica myredis 127.0.0.1 6381
sentinel known-replica myredis 127.0.0.1 6379
- 启动哨兵，在
/usr/local/bin目录下 ，运行redis-sentinel Rconfig/sentinel.conf命令
- 接着我们测试，当主服务器下线后，我们看看Sentinel能不能通过选举指定集群中一个Redis服务器晋升成为主服务器Master，当下线的服务器重新上线后，又会出现什么情况呢？
从以上哨兵的运行日志可以看出，当Redis的主服务器下线后，哨兵会通过选举指定集群中的一个Redis服务器晋升成为主服务器，同时通过发布订阅模式通知其他的Redis服务器，修改配置文件，让他们隶属于新的主Redis服务器。而当下线后的Redis服务器重启之后，并不是为主服务器，而是变为新主服务器下的一个从服务器。
以上介绍的仅仅是Redis哨兵模式的冰山一角，后面学习后再回来补充吧😆
🏁以上就是对Redis之哨兵模式的简单介绍，如果有错误的地方，还请留言指正，如果觉得本文对你有帮助那就点个赞👍吧😋😻😍
