在上篇文章我们学习了Redis教程——主从复制，这篇文章我们学习Redis教程——哨兵监控。
在主从复制中如果主机发生宕机，从机Redis会一直等到主机的恢复，这样会导致只能进行读操作，不能进行写操作，这大大降低了系统的高可用性。为了解决这个问题，Redis提供了哨兵监控。
哨兵监控
哨兵监控是吹哨人巡查监控后台主机Redis是否故障，如果故障了根据投票数自动将某个从机Redis转换为新主机Redis，继续对外服务。
如下图所示：
这样大大提高了Redis的高可用性。
通过哨兵监控，我们可以实现：
-
主从监控：监控主从Redis运行是否正常；
-
消息通知：哨兵可以将故障转移的结果发送给客户端；
-
故障转移：如果主机Redis异常，则会进行主从切换，将其中一个从机Redis作为新主机Redis；
-
配置中心：客户端通过连接哨兵来获取当前Redis服务的主节点地址。
注意：哨兵一般是有多个，负责自动监控和维护集群，不存放数据。
配置文件
哨兵的默认配置文件为sentinel.conf，大家可以在Redis的安装路径中找到，在哨兵配置，通过如下图配置项监听主机Redis，
其配置项语法格式如下：
sentinel monitor <master-name> <ip> <redis-port> <quorum> # 设置监控的主机Redis服务器
sentinel auth-pass <master-name> <password> # 设置连接主机Redis服务的密码
由于网络是不可靠的，哨兵可能会因为网络阻塞误认为一个主机Redis发生宕机，所以一般情况下是有多个哨兵来监控Redis，互相沟通某个Redis是否真的发生宕机。
配置代码中的quorum表示有多少个哨兵认为主机Redis发生宕机就进行从机Redis选举新的主机Redis。
除了上面的两条配置项，哨兵还有如下配置项，
sentinel down-after-milliseconds <master-name> <milliseconds> # 指定多少毫秒后，主机节点没有应答哨兵，此时哨兵主观上认为主节点下线
sentinel parallel-syncs <master-name> <nums> # 表示允许并行同步从机Redis个数，当主机Redis挂后，哨兵会选出新的主机Redis，此时，剩余的从机Redis会向新主机Redis发起同步数据
sentinel failover-timeout <master-name> <milliseconds> # 故障转移超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败
sentinel notification-script <master-name> <script-path> # 配置当某一个事件发生时所需要执行的脚步
sentinel client-reconfig-script <master-name> <script-path> # 客户端重新配置主节点参数脚步
示例
配置
为了方便演示，我们准备了三台服务器、三个哨兵，没服务器的可以使用VMware虚拟机，如下图所示：
这里我们已经配置好了主从关系，大家不懂怎么配置可以参考之前的文章：Redis教程——主从复制。
主机Redis有可能会变为从机，需要访问新主机Redis的密码，所以主机Redis配置也要添加masterauth配置项。
因为缺少足够的服务器，我们把三个哨兵都配置在主机Redis的服务器中。
为了更直观地查看哨兵的配置项，我们这里整理了目前所需的配置项，如下所示：
bind 0.0.0.0 # 服务监听地址，用于客户端连接
daemonize yes # 开启哨兵
protected-mode no # 允许外界连接
port 26379 # 哨兵端口
logfile "/myRedis/sentinel26379.log" # 哨兵日志文件路径
pidfile /var/run/redis-sentinel26379.pid # 哨兵pid文件
dir /myRedis # 工作目录
sentinel monitor mymaster 47.119.21.164 6379 2 # 设置监控的主机Redis服务器
sentinel auth-pass mymaster 123456 # 配置主机Redis的登录密码
由于三个哨兵都配置在同一个服务器中，所以不同哨兵的配置文件中端口号有所不同，所以上面的配置项中，port参数，哨兵日志、pid文件都需要稍微作调整。
最终我们在myRedis文件夹创建了三个哨兵配置文件，如下图所示：
启动哨兵
启动哨兵有两种方式：
redis-sentinel 哨兵配置文件路径 --sentinel
redis-server 哨兵配置文件路径 --sentinel
如下图所示：
成功启动哨兵后，会在你设置的哨兵日志文件路径下生成日志文件，其中一个日志文件如下图所示：
同时之前的哨兵配置文件也会发生变化，如下图所示：
该新增的内容简单来说就是哨兵已经知道了Redis主从关系并正在监听Redis。
模拟主机宕机
通过关闭主机Redis的方式，模拟主机Redis发生宕机，发生宕机后，哨兵会在后台进行一系列操作，所以这次的shutdown操作会延迟一下，如下图所示：
主机Redis发生宕机后，从机Redis需要重新读取网络的规划，所以从机Redis执行操作命令时，可能会报如下错误：
Error: Server closed the connection
我们只需稍微等待一下，错误就会自动消失。
接下来我们看哨兵日志文件，如下图所示：
简单来说，当主机Redis发生宕机后，一个哨兵主观认为主机Redis宕机，多个哨兵进行投票后，客观认为Redis已经宕机，接着选举新主机Redis并确定主从关系。
在这个过程中，哨兵通过Raft算法选出一个哨兵为领导，推动新主机Redis的选举、所有Redis配置文件、哨兵配置文件的修改。
Raft算法的基本思路是先到先得。
其中：
Redis配置文件将原来的replicaof配置项删除或修改了，并在配置文件末尾添加了如下代码：
# Generated by CONFIG REWRITE
latency-tracking-info-percentiles 50 99 99.9
save 3600 1
save 300 100
save 60 10000
user default on #8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92 ~* &* +@all
该代码主要是用于RDB持久化的配置。
原主机Redis末尾添加了如下代码：
# Generated by CONFIG REWRITE
latency-tracking-info-percentiles 50 99 99.9
replicaof 111.230.32.139 6379
user default on #8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92 ~* &* +@all
该代码主要是用于配置主从关系，所以当原主机Redis恢复后，会变成新主机Redis的从机。
在哨兵配置文件中，主要对监听的主机Redis服务器IP，主从关系做了修改，如下图所示：
选举原理
通过上面的内容，我们可以知道当一个主从配置中主机Redis失效后，哨兵会选举出一个新的主机Redis来接替原主机Redis的工作。
选举原理如下图所示：
首先Redis配置文件中的slave-priority或replica-priority权限最高的Redis（数字越小优先级越高），如下图所示：
优先级一样高就对比复制数据的偏移量offset最大的从机Redis，偏移量一样大就对比ID号，ID号最小的就成为新主机Redis。
选举结束后，哨兵领导者会对选举出来的新主机执行slaveof no one操作，将其提升为主机Redis，再向从机发送命令，让剩余的从机成为新主机的从机，再让原主机降级为从机并恢复正常工作。
好了，Redis教程——哨兵监控就讲到这里。
公众号：白巧克力LIN
该公众号发布Python、数据库、Linux、Flask、Django、自动化测试、Git、算法、前端、服务器等相关文章！
- END -
