Redis哨兵监控

1、Redis哨兵监控的基本概念

先回顾一下Redis复制的缺点：当主机掉线后，从机不能上位成为master，只能傻傻的等待主机归来，此时整个redis服务就处于半瘫痪状态，只能读不能写。

对此Redis引入了哨兵机制，来监控整个redis服务。当主机宕机了，哨兵就通过某种选举算法或者机制(投票数)，选择让其中一台从机上位，成为master，继续对外提供服务。实现主从互换，高容错备份。

简单点说：哨兵的作用就是无人值守运维

1、监控redis运行状态，包括master和slave
2、当master down机，能自动将slave切换成新master

按照Redis的官方建议，哨兵一定要配集群，因为如果只有一个哨兵，哨兵挂了，master主机也挂了，谁来监控Redis服务呢？谁来帮助从机上位成为master呢？因此哨兵集群为计数，方便投票

哨兵实现的四个功能：

1、主从监控：监控主从redis库运行是否正常
2、消息通知：哨兵可以将故障转移的结果发送给客户端
3、故障转移：如果master异常，则会进行主从切换，将其中一个slave作为新master
4、配置中心：客户端通过连接哨兵来获得当前Redis服务的主节点地址

2、哨兵监控配置文件sentinel .conf说明

哨兵的配置文件和redis-server的配置文件是完全不同的

以下是sentinel .conf中常用的参数：

bind：服务监听地址，用于客户端连接，默认本机地址

daemonize：是否以后台daemon方式运行

protected-mode：安全保护模式

port：端口

logfile：日志文件路径

pidfile：pid文件路径

dir：工作目录

sentinel monitor <master-name> <ip> <redis-port> <quorum>：设置要监控的master服务器，quorum表示最少有几个哨兵认可客观下线，同意故障迁移的法定票数。

为什么会存在quorum？
我们知道，网络是不可靠的，有时候一个sentinel会因为网络堵塞而误以为一个master redis已经死掉了，在sentinel集群环境下需要多个sentinel互相沟通来确认某个master是否真的死了，quorum这个参数是进行客观下线的一个依据，意思是至少有quorum个sentinel认为这个master有故障，才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因，导致无法连接master，而此时master并没有出现故障，所以，这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用

sentinel auth-pass <master-name> <password>：master设置了密码，连接master服务的密码

sentinel down-after-milliseconds <master-name> <milliseconds>：指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线

sentinel parallel-syncs <master-name> <nums>：表示允许并行同步的slave个数，当master挂了后，哨兵会选出新的master，此时，剩余的slave会向新的master发起同步数据

sentinel failover-timeout <master-name> <milliseconds>：故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败

sentinel notification-script <master-name> <script-path>：配置当某一事件发生时所需要执行的脚本

sentinel client-reconfig-script <master-name> <script-path>：客户端重新配置主节点参数脚本

3、Redis哨兵监控实操演示

Redis哨兵架构，提前说明
3个哨兵：自动监控和维护集群，不存放数据，只是吹哨人
1主2从：用于数据读取和存放

sentinel 文件通用配置

因为我只有一台云服务器，所以我将三个sentinel都放在同一台机器上

编辑sentinel26379.conf

bind 0.0.0.0	
daemonize yes	#开启后台运行
protected-mode no	#关闭保护模式
port 26379	#哨兵26379的端口为26379
logfile "/root/myredis/sentinel26379.log"	#logfile的保存路径
pidfile /var/run/redis-sentinel26379.pid	#pidfile的路径
dir /root/myredis	#工作目录
sentinel monitor mymaster (master的ip地址) (master的端口) 2	#2表示同意故障迁移的法定票数
sentinel auth-pass mymaster 123456	#master的密码

sentinel26380.conf和sentinel26381.conf只需要将内容中的26379改为26380或者26381即可

在启动一主二从时，还需要进行相应的文件配置

主机6379需要设置masterauth项访问密码，因为6379后续可能会变成从机，需要设置访问新主机的密码，否则后续可能报错master_link_status:down。从机6380和6381需要设置replicaof <masterip> <masterport>

从机6380和6381的配置是一样的

此时注意一个细节：

这时从机6380和从机6381的配置文件的末尾，后续需要进行数据对比

启动redis

查看主从关系是否正常

主机6379插入数据，验从机是否能同步数据

启动哨兵
启动哨兵的方式有两种

redis-sentinel /path/to/sentinel.conf
redis-sentinel /path/to/sentinel.conf --sentinel  

查看对应哨兵的日志文件
哨兵26379日志

其他两个哨兵日志都是一样的

查看哨兵26379的配置文件是否发生变化

哨兵26380和哨兵26381的配置文件也是大体类似

手动关闭主机6379，模拟master宕机

查看从机数据是否还在

数据还在

是否会从剩下的两台主机上选出新的master？

从上述信息可以看出，选择了从机6381作为了master

也可从对应的log中查看，例如查看sentinel26379.log

其他的哨兵日志也大概一样

主机6379重启，会不会再成为master，或者会不会造成双master冲突

答案：主机重启不会成为master，会成为新master的salve

对比配置文件
前面说到需要注意一个细节，需要进行数据对比，现在是时候了，查看主机6379的配置文件

再看看主机6381的配置文件

文件的最后也多了一些东西

结论：文件的内容，在运行期间会被 sentinel 动态进行更改。master-slave 切换后，master_redis.conf、 slave_redis.conf 和 sentinel.conf的内容都会发生改变，即 master_redis.conf 中会多一行 slaveof 的配置，sentinel.conf 的监控目标会随之调换

除此之外，一个哨兵可以监视多个master

问题：如果3个哨兵都宕机了，谁来做master的转换？
这样的情况很少出现，因为真正提供服务的是 master 和 slave，而3个哨兵是后台进程，可以看做是一个定时任务，只做监控，不存在高并发的场景，业务上压力不大。除此之外，哨兵都是在不同的机房，不同的服务器，很少出现3个哨兵都在同一台机器上，同时挂掉的场景。如果真出现这种情况，那也没办法了

4、哨兵监控的运行流程

1. 三个哨兵监控一主二从，正常运行中

2. SDown主观下线(Subjectively Down)
   SDOWN(主观不可用)是单个sentinel自己主观上检测到的关于mastr的状态，从sentinel的角度来看如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件。
   

3. ODown客观下线(Objectively Down)
   ODown需要一定数量的sentinel，多个哨兵达成一致意见才能认为一 个master客观上已经宕机
   

4. 选举出领导者哨兵(哨兵中选出兵王)
   当主节点被判断客观下线以后，各个哨兵节点会进行协商，先选举出一个领导者哨兵节点(兵王/leader)并由该领导者节点，也即被选举出的兵王进行failover (故障迁移)。所有的选举过程都可以在log日志中查看
   哨兵领导者，兵王如何选出来的?------》Raft算法
   

5. 由兵王开始推动故障切换流程并选出一个新master
   新主登机
   选出新的master的规则，剩余slave节点健康前提下
   1)redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点(数字越小优先级越高)
   
   replica-priority默认是100
   2)复制偏移位置offset最大的从节点
   3)最小Run ID的从节点，字典顺序，ASCII码
   
   群臣俯首
   1)执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点
   2)Sentinel leader会对选举出的新master执行slaveof no one操作，将其提升为master节点
   3)Sentinel leader向其它slave发送命令,让剩余的slave成为新的master节点的slave
   旧主拜服
   1)将之前已下线的老master设置为新选出的新master的从节点，当老master重新上线后，它会成为新master的从节点
   2)Sentinel leader会让原来的master降级为slave并恢复正常工作

总结：上述的故障迁移(failover)操作均由sentinel自己独自完成，完全无需人工干预

6、哨兵的使用建议

1. 哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用
2. 哨兵节点的数量应该是奇数
3. 各个哨兵节点的配置应一致
4. 如果哨兵节点部署在Docker等容器里面，尤其要注意端口的正确映射
5. 哨兵集群+主从复制，并不能保证数据零丢失