Redis系列——哨兵挂了，redis 还能正常工做吗？

​

 前言

redis 主挂掉了，怎么将请求转移到从上去，若是从是多个，从是怎么进行选举的呢？

那么就要看咱们今天的主角了，redis哨兵，redis哨兵可以帮助咱们自动的完成选主和故障转移操做，此次仍是会多画图，来加深你们都这个过程的记忆和理解。

redis哨兵都干了什么

redis哨兵是一个运行的特殊的redis进程，他主要有三个使命：

• 监控
• 选主
• 通知

监控的是什么

哨兵主要是监听主库和从库是否存活，怎么进行监控？ 哨兵会按期的给从库发送PING命令，若是从库没有在设定的时间内回复哨兵，那么就会认为从库下线了。哨兵也会按期的给主库发送PING命令进行通讯，若是主库也没有在设定的时间内回复哨兵，那么就会认为主库也“下线了”。【注意我这里只是为了说明下监控的方式，真正判断的主库下线不是这样的】。

看图说话：

​

能够看到图中redis-2 slave 是灰色，表示已经down掉了，此时并无正常返回给哨兵响应，因此被标记为下线状态了。

主库的监控

这里为何要单独来讲下主库的监控呢？由于主库监控，不能说哨兵没有收到PING的响应，那么就认为主库就下线了，由于主库的选举是一个很复杂的过程，会有耗时和通讯的开销，因此咱们不能简单认为哨兵没有收到PING的响应，那么就直接判断主库下线了，而后就进行选举，若是是从库能够的，由于从库下线了，对于主从集群来讲，影响不会很大。

在主库压力比较大，或者网络阻塞了，出现抖动了，这个是并无在设定的时间内回复给哨兵响应，那么此时武断的认为主库"下线了"，此时就出现了误判，明明不须要进行选主，不须要进行通知，此时白白浪费的资源、同时带来了开销。

看图说话：

在网络畅通的状况下，哨兵发了一个PING给主库

​

此时网络阻塞，变成了红色，PONG，没有在设定的时间内返回

​

网络恢复顺畅，哨兵重试，在设定的时间内返回响应

​

经过上面三幅图，其实就能够看出，网络阻塞的状况下，会出现误判的状况。

那么reids是怎么判断主库下线的呢？其实redis采用哨兵集群的方式，让哨兵集群中的每一个哨兵都和主库进行通讯，若是多数都没有在设定的时间内响应给哨兵，由于多个哨兵都出现网络不稳定的状况几率就大大下降了，那么此时这个主库就认为是下线了。下面咱们来细细的说下这个过程，同时引入哨兵集群也解决了哨兵单点的问题。

主库的下线判断

这个过程分为主观下线和客观下线。

主观下线：指的是一个哨兵在设定的时间内，没有收到主库的响应，那么此时是这个哨兵主观的认为主库下线了，并不能认为真正的下线。

客观下线：指的是，当多数哨兵在设定的时间内，都没有收到主库的响应，那么此时就能够认为主库真的下线，称为客观事实了。

继续看图说话：

下图中只有哨兵B，没有在设定的时间内，收到响应，判断为主观下线了，可是其余哨兵A和哨兵C都能在设定的时间内收到响应，因此仍是线上状态，少数服从多数，此时结论仍是上线状态。

​

下图中哨兵B和哨兵C，都没有在设定的时间内收到响应，即便哨兵A收到正常的响应，那么此时已经构成多数状况下的主观下线，此时就能够判断为客观下线了。

​

选主

上面的我相信你们已经很清楚，redis的怎么判断主库的下线了，那么此时redis须要从剩下的全部的从库中再次选举出一个新的主库，来接收后面来的写请求。

reids哨兵会对从库们进行打分，谁的分数高，那么它就是新的master了，下面来详细说选主的过程。

哨兵在进行打分以前，先会在从库进行筛选，把不合格的从库筛选掉，留下优秀的种子选手来进行参赛打分。

那么筛选的依据是什么呢？

哨兵会把标记为下线的从库和主从之间网络不畅的从库筛选掉，看下图你就明白了：

​

在主从模式下，若是主从之间网络断开的次数和超时时间超过down-after-milliseconds 的设置，那么就会认为该从库网络不健康了，不稳定了。

接下来就会从剩下的优秀从库内进行打分，打分最高者为新的Master，

打分会从三个层级进行打分，记住只会比较一个层级的分数，只要在当前的层级分数最高就能够了，若是分数相同，再比下一个层级，以此类推。

第一轮：比较从库的优先级

你能够手动设置从库的优先级，经过slave-priority进行设置，数字越小，级别越高。若是这个层次，有优先级级别最高的出现，那么就选此从库作为Master，选举就结束了，若是优先级相同，那么进入下一轮打分。 看图：

​

第二轮：与主库的同步进度越接近

确定是从库的数据越新，那么选择它做为新的Master，才最有意义了。那怎么才能知道哪一个从库才是最新的呢？

从库会记录本身同步主库的进度，这个参数为slave_repl_offset, 是累加的，也就是这个值越大，那么它们谁同步的数据就是最新的，得分就是最高的，选举就结束了，若是复制进度相同，那么还须要进入下一轮，比较ID。 看图：

​

第三轮：ID号越小，得分越高

比较本身的ID【redis在启动的时候，会给本身分配一个ID】，ID越小，本身得分就越高。

​

最多经历三轮打分，主库就会被从新选出，那么哨兵就会通知其余从库执行replicaof 指向新的主库，进行主从切换，这里有一个细节，须要注意，不知道你没有想到，就是由哪一个哨兵来执行主从切换呢？

哨兵选举Leader

其实由哪一个哨兵来进行发号施令，进行主从切换，这个哨兵是须要进行选举的其实由哪一个哨兵来进行发号施令，进行主从切换，这个哨兵是须要进行选举的。

本篇前面说过，判断主库是否下线是须要进行主观下线和客观下线两个过程，本身先标记为主观下线，当多数都标记为主观下线的时候，那么就认为客观下线了，那么这个多数应该是多少呢，实际上是经过quorum配置项配置的，若是咱们有三个哨兵，quorum 配置为2 ，那么除了本身判断主观下线，还须要一个哨兵也须要判断为主观下线，那么此时才会进入客观下线了，这个判断的过程，其实就是一个投票的过程，包括本身给本身投一票，还包括向其余实例发送is-master-down-by-addr 命令，询问其余实例，本身判断的这个主库是否是下下了，若是获得对方的响应，那么本身的票数就累加，哨兵投过票了，就不会给其余哨兵再次投票了。

这里具体看图：

​

这个图只是简单的为了说明，哨兵B和哨兵C都发现了redis Master 为主观下线了，可是哨兵B 优先给其余哨兵发了is-master-down-by-addr命令，并获得了哨兵C的回复，那么加上本身给本身的投票，那么就是得票数为2 ，大于等于 quorum的配置值 2，此时主库标记为客观下线.

若是哨兵B 要想成为Leader，那么还要同时知足获得的票数大于等于哨兵（n/2 + 1）数量才能够成为leader，这里因为咱们有三个哨兵，票数过半的话，也就是大于等于2，因此此时哨兵B能够成为Leader了。

因此称为leader要知足的条件为：

• 获得的票数要达到配置的quorum阀值。
• 得到哨兵半数以上的票数。

通知

哨兵B Leader 能够主持主从切换了,通知其余从库执行replicaof 到新的Master，主从切换完成以后，还会通知链接redis 的客户端，告诉它们新的Master的地址和端口。

这里在说下是怎么通知redis 客户端 Master要换新的ip和端口了呢？

其实redis客户端能够定于哨兵的主从切换事件，当完成主从切换后，哨兵就发送这个事件的结果，那么订阅了这个事件的redis客户端都会收到通知，此时redis客户端就能够更新到新的Master的地址了。

若是出现网络断开或者抖动，没有收到订阅事件的通知，那么其实还能够调用哨兵提供的接口，进行从新拉取。

通知模型：

​

总结

今天主要是熟悉哨兵的工做原理和过程，下面来作下总结：

哨兵都干了什么？

监控、选主、通知。

监控：

监控主从节点是否下线，从节点能够简单认为没有收到响应就直接下线，由于从节点下线通常不会影响到集群的使用。

主节点的下线，分为主观下线和客观下线，只有在多数都认为是主观下线了，才认为是客观下线了。

选主：

首先进行筛选，把标记为下线的从库，网络不稳定的从库晒出掉。
接下来进行打分，主要会分三个阶段：分别从 从库的优先级、复制进度、ID大小来进行打分。

通知：

通知其余从库执行replicaof 到新的Master，主从切换完成以后，还会通知链接redis 的客户端，告诉它们新的Master的地址和端口。

哨兵选举过程：

哨兵投票机制：

a：哨兵实例只有在本身断定主库下线时，才会给本身投票，而其余的哨兵实例会把票投给第一个来要票的请求，其后的都拒绝。
b：若是出现多个哨兵同时发现主库下线并给本身投票，致使投票选举失败，就会触发新一轮投票，直至成功。

哨兵成为Leader的必要条件：

a：得到半数以上的票数。
b：获得的票数要达到配置的quorum阀值。

注意的点

在master关掉 到 主从切换完成，通知完客户端，这个期间，全部的写请求是不能处理的，由于master已经挂掉了，若是采用的是读写分离，全部的读请求就是能够正常处理的，读请求会被分到从库上去。若是此时想让业务感知不到异常，能够采起相应的降级策略，可让写请求先写入到mq中，等待恢复以后，再写入到新的master就能够了。

这里在强调一下哨兵进行主从切换的前提条件，必需要选择出哨兵Leader，由Leader进行通知从进行主从切换和通知客户端更换新的Master的地址和端口。

在这里举个例子，若是有5个哨兵，quorum 配置为2，那么要想成为Leader，那么得到票数必需要达到2 才能判断一个主库为客观下线，同时得到票数也要大于等于(n/2) + 1 的票数，也就是得到3以上才能够。若是此时有3个哨兵故障了，即便你得到了2票，能判断为客观下线，那么因为没有过半的哨兵数量，也是没法选举出Leader ，也就没法进行下面的过程了，此时集群就玩完了。

问题

这里给你们留一个问题，咱们知道能够经过下面命令进行哨兵集群的搭建：

sentinel monitor <master-name> <ip> <redis-port> <quorum>

这里只是设置了 ip 和端口，以及quorum值，那么整个集群之间是怎么创建通讯，进而能后续的选举leader作准备，同时它又是怎么得到从库的ip和端口列表，进而来作后续的从库的监控。

两个问题：

• 集群怎么创建通讯的？
• 集群怎么获取的从库列表？

 

 一直想整理出一份完美的面试宝典，可是时间上一直腾不开，这套一千多道面试题宝典，结合今年金三银四各类大厂面试题，以及 GitHub 上 star 数超 30K+ 的文档整理出来的，我上传之后，毫无心外的短短半个小时点赞量就达到了 13k，说实话仍是有点难以想象的。

一千道互联网 Java 工程师面试题

内容涵盖：Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、Redis、MySQL、Spring、SpringBoot、SpringCloud、RabbitMQ、Kafka、Linux等技术栈（485页）

​

《Java核心知识点合集（283页）》

内容涵盖：Java基础、JVM、高并发、多线程、分布式、设计模式、Spring全家桶、Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、MongoDB、Redis、MySQL、RabbitMQ、Kafka、Linux、Netty、Tomcat、数据库、云计算等

​

《Java中高级核心知识点合集（524页）》

​

《Java高级架构知识点整理》

​

​ ​

 因为篇幅限制，详解资料太全面，细节内容太多，因此只把部分知识点截图出来粗略的介绍，每一个小节点里面都有更细化的内容!

须要的小伙伴，能够一键三连，下方获取免费领取方式！

​

 

 

​