redis学习二十：redis哨兵监控

是啥：

吹哨人巡查监控后台master主机是否故障，如果故障了根据投票数自动将某一个从库转换为新主库，继续对外服务。

作用：

1.监控redis运行状态，包括master和slave

2.当master宕机，能自动将slave切换成新master

能干啥：

主从监控：监控主从redis库运行是否正常

消息通知：哨兵可以将故障转移的结果发送给客户端

故障转移：如果master异常，则会进行主从切换，将其中一个slave作为新master

配置中心：客户端通过连接哨兵来获得当前redis服务的主节点地址

实例演示：

架构：

3个哨兵：自动监控和维护集群，不存放数据，只是吹哨人

1主2从：用于数据读取和存放

案例步骤：

1./myredis目录下新建或者拷贝sentinel.conf文件，名字绝不能错

2.重点参数说明

设置要监控的master服务器：

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

 master设置了密码，连接master服务的密码：

其他（默认即可）：

 指定多少毫秒后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线

 表示允许并行同步的slave个数，当master挂了后，哨兵会选出新的master，此时，剩余的slave会向新的master发起同步数据

 故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败

 配置当某一事件发生时所需要的执行的脚本

 客户端重新配置主节点参数脚本

 3.本次案例哨兵sentinel文件的通用配置

因为电脑不太行，三个哨兵我都放在一个服务器里，三个具体配置如下，每行意思可以参照之前的配置讲解

 4.先启动一主二从3个redis实例，测试正常的主从复制

 6379虽然作为主机按道理不需要配置masterauth，但是后续可能会变成从机，需要设置访问新主机的密码，

所以需要设置。

然后启动主从复制

 进入哨兵的内容

5.启动三个哨兵

查看哨兵日志可以看到加了两个slave挂在6379

 

 6.启动完再试一次主从复制

实验ok

7.原有master挂掉情况

 手动把6379shutdown后，过了一会，便选举6381作为新的master

 日志中可以看到6381转换为master

 并且重新启动6379我们会发现master还是6381,6379成为6381的slave

配置结论：

1.文件的内容在运行期间会被sentinel动态进行修改

2.master-slave切换后，master-reids.conf，slave-redis.conf和sentinel.conf的内容都会发生改变，

即master-redis.conf中会多一行slaveof/replication的配置,sentinel.conf的监控目标会随之调换。

备注：

1.生产都是不同机房不同服务器，很少出现3个哨兵全部挂掉的情况

2.可以同时监控多个master，一行一个

 

哨兵运行流程和选举原理

当一个主从配置中的master失效之后，sentinel可以选举出一个新的master用于自动接替原master的工作，

主从配置中的其他redis服务器自动指向新的master同步数据。一般建议sentinel采取奇数台，防止某一台

sentinel无法连接到master导致错误切换。

运行流程：

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

2.主观下线：单个哨兵主观上检测到关于master的状态，从sentinel的角度来看，如果发送了ping心跳后，在一定时间内没有收到合法的恢复，就达到了主观下线的条件（配置文件的down-after-milliseconds设置了判断主观下线的时间长度）

3.客观下线：需要一定数量的sentinel，多个哨兵达成一致意见才能确认某一个master挂掉

4.选举出领导者哨兵：当主节点被判断客观下线以后，各个哨兵节点会进行协商，先选举出一个领导者哨兵节点，并且由改领导者节点进行failover故障迁移

领导者哨兵如何选出来：raft算法，基本思路是先到先得，哨兵A向哨兵B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者

5.由领导者哨兵选出master;

（1）新主登基：某一个slave被选中当master（根据权限——根据复制偏移量（谁复制的多）——根据ID（ascall码））

（2）群臣俯首：执行slaveof no one让选出来的从节点成为新的主节点，并且通过slaveof命令让其他节点成为其slave

（3）旧主拜佛：原来的master变成新master的slave

总结：上述的failover操作完全是sentinel操作，不需要人工干预

使用建议：

哨兵节点的数量应该是多个，哨兵本身应该集群，保证高可用

哨兵节点的数量应该是奇数

各个哨兵节点的配置应一致

如果哨兵节点部署在docker等容器里，尤其要注意端口的正确映射

哨兵集群+主从复制，并不能保证数据零丢失（找新的master花几秒，在这几秒时候会出现问题——需要集群）