Redis6.x学习笔记（五）哨兵

前言

最近学习Redis6.x，特做笔记以备忘，与大家共学。课程是从私塾在线下载的，他们把架构师课程都放出来了，大家可以去下载学习，不要钱的，地址是http://sishuok.com/freecourses.html?frombwr5,课程很不错，值得学习！关键是不要钱，嘻嘻！

哨兵（sentinel）概述

哨兵是Redis 复制集 集群的重要组件，主要实现：

1：集群监控：监控主从数据库运行是否正常
2：故障转移：当主数据库出现故障时，自动将从数据库转换成为主数据库
3：配置中心：客户端通过连接哨兵来获得当前Redis服务的主节点地址
4：消息通知：哨兵可以将故障转移的结果发送给客户端

注意：使用Redis-sentinel，redis实例必须在非集群模式下运行

开启哨兵功能

建立一个sentinel.conf文件，里面设置要监控的主数据库的名字，形如：
sentinel monitor 监控的主数据库的名字 127.0.0.1 6380 1

表示哨兵判断主节点是否发生故障的最低票数
（1）这个文件的内容，在运行期间会被sentinel动态进行更改
（2）可以同时监控多个主数据库，一行一个配置即可

哨兵配置详解

1：bind：服务监听地址，用于客户端连接，默认本机地址
2：protected-mode：安全保护模式
3：port：监听的端口号
4：daemonize：是否以后台daemon方式运行
5：pidfile：pid文件位置
6：logfile：log文件位置
7：dir：工作目录
8：sentinel monitor <master-name> <ip> <port> <quorum>：
	设置要监控的master服务器
9： sentinel auth-pass <master-name> <password>：连接master服务的密码
10： sentinel down-after-milliseconds <master-name> <milliseconds>：
	指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线
11： sentinel parallel-syncs <master-name> <nums>：
	表示允许并行同步的slave个数，当Master挂了后，哨兵会选出新的Master，
	此时，剩余的slave会向新的master发起同步数据
12： sentinel failover-timeout <master-name> <milliseconds>：
	故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，
	表示故障转移失败
13： sentinel notification-script <master-name> <script-path> ：
	配置当某一事件发生时所需要执行的脚本
14： sentinel client-reconfig-script <master-name> <script-path>：
	客户端重新配置主节点参数脚本

哨兵基本原理之自动发现

哨兵互相之间的相互自动发现，是通过redis的pub/sub系统实现的，每个哨兵都会往__sentinel__:hello这个channel里发送一个消息，这时候所有其他哨兵都可以消费到这个消息，并感知到其他的哨兵的存在。

每隔两秒钟，每个哨兵都会往自己监控的某个master+slave对应的__sentinel__:hello channel里发送一个消息，内容是自己的host、ip和runid还有对这个master的监控配置。

每个哨兵也会去监听自己监控的每个master+slaves对应的__sentinel__:hello channel，然后去感知到同样在监听这个master+slave的其他哨兵的存在。

每个哨兵跟其他哨兵交换对master的监控配置，互相进行监控配置的同步

哨兵基本原理之选举

quorum：确认客观下线的最少的哨兵数量
majority：授权进行主从切换的最少的哨兵数量

每次一个哨兵要做主备切换，首先需要quorum数量的哨兵认为master客观下线，然后选举出一个哨兵来做切换，这个哨兵还需要得到majority哨兵的授权，才能正式执行切换

选举领导者哨兵

当主节点被判断客观下线以后，各个哨兵节点会进行协商，选举出一个领导者哨兵节点，并由该领导者节点对其进行故障转移操作。

监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法

Raft算法的基本思路是先到先得：即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者

哨兵基本原理之故障转移

故障转移（Slave选举成为Master）

选举出的领导者哨兵，开始进行故障转移操作，大体可以分为3个步骤：

1：在从节点中选择新的主节点：选择的原则是，首先过滤掉不健康的从节点；然后选择优先级最高的从节点(由slave-priority指定)；如果优先级无法区分，则选择复制offset最大的从节点；如果仍无法区分，则选择runid最小的从节点

2：更新主从状态：通过slaveof no one命令，让选出来的从节点成为主节点；并通过slaveof命令让其他节点成为其从节点

3：将已经下线的主节点设置为新的主节点的从节点，当其重新上线后，它会成为新的主节点的从节点

哨兵基本原理之配置传播

configuration epoch

新的master选出过后，执行切换的那个哨兵，会从要切换到的新master那里得到一个configuration epoch，这就是一个version号，每次切换的version号都必须是唯一的。

如果第一个选举出的哨兵切换失败了，那么其他哨兵，会等待failover-timeout时间，然后接替继续执行切换，此时会重新获取一个新的configuration epoch，作为新的version号

Configuration传播

哨兵完成master切换之后，会在自己本地更新生成最新的master配置，然后同步给其他的哨兵，就是通过之前说的pub/sub消息机制。

这时version号就很重要了，因为各种消息都是通过一个channel去发布和监听的，所以一个哨兵完成一次master的切换之后，新的master配置是跟着新的version号的。

其他的哨兵都是根据版本号的大小来更新自己的master配置的

哨兵使用建议

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

后记

我会持续的把我学习Redis6.x过程的笔记记录下来，跟大家一起学习。希望能坚持下去！