内容参考蒋德钧老师讲义
哨兵其实就是一个运行在特殊模式下的redis进程，主从库实例运行的同时，它也在运行。哨兵主要负责的就是三大任务：监控、选主和通知。
我们先看监控。监控是指哨兵进程在运行时，周期性地给所有地主从库发送PING命令，检测他们是否仍然在线运行。如果从库没有在规定时间内响应哨兵地PING命令，哨兵就会把它标记为"下线状态"；同样，如果主库也没有在规定时间内响应哨兵地PING命令，哨兵就会判定主库下线，然后开始自动切换主库地流程。
这个流程首先是执行哨兵的第二个任务，选主。主库挂了以后，哨兵就需要很多个从库里，按照一定的规则选择一个从库实例，把它作为新的主库。这一步完成后，现在的集群里就有了新的主库。
然后，哨兵会执行最后一个任务:通知。在执行通知任务时，哨兵会把新主库的连接信息发送给其他从库，让他们执行slaveof命令，和新主库建立连接并进行数据复制。同时，哨兵会把新主库的连接信息发送到客户端，让客户端把请求操作发送到主库上。
在这三个任务中，通知任务相对简单，哨兵只需要把新主库信息发送从库和客户端，让他们和新主库建立连接即可，并不涉及决策的逻辑。但是在监控和选主这两个任务中，哨兵需要做出两个决策：
- 在监控任务中，哨兵需要判断主库是否处于下线状态
- 在选主任务中，哨兵也要决定选主哪个从库实例作为主库。
接下来，先说说如何判断主库的下线状态。
首先要知道的是，哨兵对主库的下线判断有“主观下线”和“客观下线”两种。那么，为什么会存在这两种判断呢？他们的区别和联系是什么呢？
主观下线和客观下线
哨兵进程会使用PING命令检测它自己和主、从库的网络连接情况，用来判断实例的状态。如果哨兵发现主库或从库对PING命令的响应超时了，那么哨兵就会先把他标记为“主观下线”。
如果检测的是从库，那么，哨兵简单地把它标记为“主观下线”就行了，因为从库地下线影响一般不太大，集群地对外服务不会间断。
但是，如果检测地是主库，那么，哨兵还不能简答地把它标记为"主观下线"，开启主从切换。因为很可能存在这么一种情况：那就是哨兵误判了，其实主库并没有故障。可是一旦启用了主从切换，后续地选主和通知操作都会带来额外地计算和通信开销。
为了避免这些不必要地开销，我们需要特别注意误判地情况。
首先，我们需要知道啥叫误判。很简单，就是主库实际并没有下线，但是哨兵误以为它下线了。误判一般会发生在集群网络压力较大、网络拥塞，或者是主库本身压力较大地情况下。
一旦哨兵判断主库下线了，就会开始选择新主库，从库也需要花时间和新主库进行数据同步，这个过程本身就有数据开销，例如，哨兵要花时间选出新主库，从库也需要花时间和新主库同步。而在误判地情况下，主库本身根本就不需要进行切换地，所以这个过程地开销是没有价值地。正是因为这样，我们需要判断是否有误判，以及减少误判。
那怎么减少误判呢？在日常生活中，当我们要对一些重要的事情做判断时，经常会和家人朋友商量一下，然后再做决定。
哨兵机制也是类似的，它通常会采用多实例组成的集群模式进行部署，这也被称为哨兵集群。引入多个哨兵实例一起来进行判断，这样就可以避免单个哨兵因为自身网络状况不佳，而误判主库下线的情况。同时，多个哨兵的网络同时不稳定的概率较小，由他们一起做决策，误判率也能降低。
在判断主库是否下线时，不能由一个哨兵说了算，只有大多数的哨兵实例，都判断主库已经“主观下线”了，主库才会被标记为“客观下线”，这个叫法也是表明主库下线成为了一个客观事实。这个判断原则就是：少数服从多数。同时，这会进一步触发哨兵开始主从切换的流程。
如图所示，redis主从集群有一个主库，三个从库，还有三个哨兵实例。在图片的左边，哨兵2判断主库为“主观下线”，但哨兵1和哨兵3却判断主库时上线状态，此时，主库仍然被判断为上线状态。在图片的右边，哨兵1和哨兵2都判断主库为“主观下线”，此时，即使哨兵3仍然判断主库为上线状态，主库也被标记为“客观下线”了。
简单来说，“客观下线”的标准就是，当有N和哨兵实例时，最后要有 N/2+1个实例判断主库“主观下线”，才能最终判断主库为“客观下线”。这样一来，就可以减少误判的概率，就可以避免误判带来的无谓的主从切换。
如何选择新主库
一般来说，哨兵选择新主库的过程称为“筛选+打分”。简单来说，我们在多个从库中，先按照一定的筛选条件，把不符合条件的从库去掉。然后，我们再按照一定的规则，给剩余的从库逐渐打分，将得分高的从库选择为新主库。
在刚刚的这段话里，需要注意两个“一定”，现在我们要考虑这里的“一定”具体是指什么。
首先来看筛选的条件。
一般情况下，我们肯定要先保证所选的从库线程仍然在线运行。不过，在选主时从库正常在线，这只能表明从库的现状良好，并不代表他就是最适合做主库的。
设想一下，如果在选主时，一个从库正常运行，我们把它选为新主库开始使用了。可是，很快他就出现了网络故障，此时，就得重新选主了。这显然不是我们期望的结果。
所以，在选主时，除了要检查从库当前的状态，还要判断它之前的网络连接状态。如果从库总是和主库断连，而且断连次数超过了一定阈值，我们就有理由相信，这个从库的网络状况并不是太好，就可以把这个从库筛选掉。
具体怎么判断呢？你使用配置项down-after-milliseconds*10.其中，down-after-milliseconds是我们设定主从库断连的最大连接超时时间。如果在down-after-milliseconds毫秒内，主从节点都没有通过网络联系上，我们就可以认为主从节点断联了。如果发生断连的次数超过了10次，就说明这个从库的网络状况不好，不适合做新主库。
好了，这样就过滤掉了不适合做主库的从库，完成了筛选工作。
接下来就是要为从库打分了。我们可以按照三个规则依次进行三轮打分，这三个规则分别是从库优先级、从库复制进度以及从库ID号。只要在某一轮中，由从库得分最高，那么他就是主库了，选主过程到此结束。如果没有出现得分最高的从库，那么就像继续进行下一轮。
第一轮：优先级最高的从库得分高
用户可以通过slave-priority 配置项，给不同的从库设置不同的优先级。比如，你有两个从库，他们的内存大小不一样，你可以手动给内存大的实例设置一个高优先级。在选主的时候，哨兵会给优先级高的从库打高分，如果有一个从库优先级高，那么它就是新主库了。如果从库的优先级都一样，那么哨兵就开始第二轮打分。
第二轮：和旧主库同步程度最接近的从库得分最高
这个规则的依据就是，如果选择和旧主库同步最接近的那个从库作为主库，那么，这个新主库上就有最新的数据。
如何判断从库和旧主库间的同步进度呢？
上一节说过，主从同步时有个命令传播过程。在这个过程中，主库会用master_repl_offset记录当前的最新写操作在repl_backlog_buffer 中的位置，而从库的slave_repl_offset这个值记录了当前的复制进度。
此时，我们想要找的从库，它的slave_repl_offset需要最接近master_repl_offset。如果在所有从库中，有从库的slave_repl_offset最接近master_repl_offset，那么它的得分就最高，可以最为新的主库。
就像下图所示，旧主库的master_repl_offset是1000，从库1、2和3的slave_repl_offset分别是950、990和900，那么，从库2就应该被选为新主库。
当然，如果有两个从库slave_repl_offset值大小是一样的(例如：从库1和从库2的slave_repl_offset值都是990)，我们就需要给他们进行第三轮打分。
第三轮：ID号小的从库得分高
每个实例都会有一个ID，这个ID就类似于这个的从库标号。目前mredis在选主库时，有一个默认的规定：在优先级和复制进度都相同的情况下，ID号最小的从库得分最高，就会被选择为新主库
到这里选主的过程就完成了。