看图说话：
可以看到图中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，才最故意义了。那怎么才能知道哪个从库才是最新的呢？
我们之前上一篇redis主从事理，从库会记录自己同步主库的进度，这个参数为 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和端口列表，进而来做后续的从库的监控。
原文链接：https://juejin.cn/post/6986567805386620941
