目录
本博文主要总结关于哨兵的一些理论知识，主要关注点有一下几个方面：
一、哨兵解决了什么问题？
二、哨兵是如何解决“问题一”的？
三、如何使用哨兵？
四、Redis Sentinel客户端实现的原理是什么？Java如何操作Redis Sentinel？
二、哨兵是如何解决“问题一”的？
这个就要从哨兵的原理说起了。下面主要从三个定时监控任务、主/客观下线、领导者Sentinel节点选举、故障转移这四个方面总结。
2.1 、主从模式哨兵部署
（1）哨兵节点的数量尽量为大于等于3的奇数，提高对故障判断的准确性。
（2）哨兵节点不应该部署在一台物理机器上。
（3）哨兵节点集合可以只监控一个主节点，也可以监控多个主节点。
下图可发现：哨兵不仅监控着主节点和从节点，还监控着其他哨兵节点。
2.2、三个定时监控任务
第一个任务：获取最新的主从拓扑结构
每隔10秒，每个哨兵会向master节点和slave节点发送info命令，获取最新的主从拓扑结构。
第二个任务：发现新的哨兵节点、哨兵节点之间交换这节点的状态
每隔2秒，每隔哨兵会向master节点的_sentinel_:hello频道上发送该哨兵节点对master节点的判断，以及当前sentinel节点的信息。因为，每个哨兵节点都订阅了master节点的_sentinel_:hello频道，其他哨兵节点就可以了解其他哨兵节点的信息，以及其他哨兵节点对主节点的判断。
第三个任务：判断master节点、slave节点、其他哨兵节点是否在线
每隔1秒，每个哨兵节点会向master节点、slave节点、其他哨兵节点发送一条ping命令，做心跳检测，来确认这些节点是否可达。
2.3、主观下线与客观下线
2.3.1、主观下线
在第三个定时任务写道，每个哨兵节点会对matser节点、slave节点、其他哨兵节点定时发送ping命令，当这些节点超过sentinel.conf文件配置的down-after-milliseconds时，该哨兵就会做出失败的判定，此为主观下线。即自己ping不通了就判定是下线了，可能会存在误判。因此，才有了客观下线，多数人判定下线了才是真的下线。
在哨兵实例上有这样一个配置文件，即sentinel.conf文件，其中down-after-milliseconds就是心跳检测的超时时间：
#13秒超时
sentinel down-after-milliseconds pmaster 130002.3.2、客观下线
当一个哨兵节点A发现下线的是master节点，就会向其他哨兵节点发送一个sentinel is-master-down-by-addr命令，询问其他节点对该addr主节点的状态判断，当超过sentinel.conf配置的quorum个数。此时，哨兵节点A就会对该master节点做出客观下线的决定了。
在哨兵实例上有这样一个配置文件，即sentinel.conf文件，下面就是代表该哨兵监控的是master的名字是pmaster，ip地址是127.0.0.1，端口号是6379，最后的2就是：代表要判断主节点最终不可达（主节点下线）所需要的票数。
sentinel monitor pmaster 127.0.0.1 6379 2注意：当从节点、哨兵节点主观下线后，没有后续的故障转移操作。
2.3.3、介绍sentinel is-master-down-by-addr命令的使用方法
sentinel is-master-down-by-addr <ip> <port> <current_epoch> <ruuid>ip：主节点的ip地址
port：主节点的端口号
current_epoch：当前哨兵配置的纪元
runid：此参数有两种类型，不同类型决定了此API作用不同。
当runid等于 * 时，作用是哨兵节点直接交换对主节点下线的决定；
当runid等于当前哨兵节点的runid时，作用是当前哨兵节点希望目标哨兵节点同意自己成为leader的请求，这里就与下一节的领导者选举有关了。
例如，当一个哨兵节点向其他哨兵节点发送一下命令
sentinel is-master-down-by-addr 127.0.0.1 6379 0 *收到其他哨兵的返回结果包括是三个参数：
down_state：目标哨兵节点对于主节点的主观下线判断，1代表下线，0代表在线。
leader_runid：等于 * 时，代表返回结果只是用来判断主节点是否下线；当等于具体的runid，代表目标哨兵同意runid的哨兵成为负责故障转移工作的领导者。
2.4、领导者哨兵节点选举
到此为止，已经客观判断了主节点下线了，是不是立刻就执行故障转移了呢？不是，现在还需要选举一个哨兵作为领导者，来专门负责故障转移的工作。
Redis选举领导者的算法是Raft算法，该算法不在这里介绍。该算法可参考GitHub主页：https://raft.github.io/
选举领导者的大致思路：
（1）首先，每个在线的哨兵节点都有资格成为了领导者。当某一个哨兵节点A主观判断主节点下线时，就会向其他哨兵节点发送sentinel is-master-down-by-addr命令，并请求将自己设置为领导者。这里，就需要将runid设置为自己的runid。
（2）收到命令的哨兵节点，如果没有同意过其他哨兵节点的sentinel is-master-down-by-addr命令，就会同意该请求，否则拒绝。因为，每个哨兵只有这么一张票，投了别人，就再没有投其他哨兵的机会了。
（3）如果哨兵节点A发现自己的票数已经大于或等于max(quorum, num(sentinels)/2+1)，哨兵节点A就成为了领导者。
（4）如果此过程没有选举出领导者，将进行下一次选举。
一般，选举过程非常快，谁先完成客观下线判断，谁就是领导者。
2.5、故障转移
到此，我们选择出了领导者，来负责故障转移。具体转移步骤如下：
（1）在从节点选出一个节点作为新的主节点。
（a）过滤掉“不健康”（主观下线、断线）、5秒内没有回复过哨兵节点的ping命令、与主节点失联超过down-after-milliseconds*10秒的从节点。
（b）选择slave-priority最高的从节点列表。如果存在则返回，否则继续下一步。slave-priority代表从节点的优先级，它是在sentinel.conf文件设置的，其数值越小，优先级越高。但是为0，永远不会被选择为主节点的。
（c）选择复制偏移量最大的从节点（复制的最完整），如果存在则返回，否则继续。
（d）选择runid最小的从节点。
（2）领导者会对（1）选出来的新节点做slaveof no one命令，让其成为主节点。
（3）领导者向剩余的从节点发送命令，让它们成为新主节点的从节点，这里的复制规则就与sentinel.conf文件在的参数parallel-syncs有关。
（4）哨兵节点集合将原来的主节点更新为从节点，并保持对其关注，当其恢复后命令它去复制新的主节点。
在第（1）步中选出最好的从节点流程图：
关于其他Redis Sentinel机制与用法：
下一篇：Redis哨兵原理总结（三）将介绍哨兵部署、Redis节点的conf文件和哨兵节点的conf文件解释、哨兵日志解释