什么是哨兵（Sentinel）
65 哥：码哥，虽然我没女朋友，但是，未雨绸缪我要掌握这个哨兵模式，防止当深夜与女朋友么么哒被打扰，你快说说哨兵的实现原理吧。
搭建实例采用三个哨兵形成集群，三个数据节点（一主两从）方式搭建，如下图所示：
65 哥你听过「武当派」创始人张三疯么？Redis 主从架构就好比一个武当，掌门人就是 Master。掌门人如果挂了，需要从武当七侠里面选举能人担当掌门人。这就需要一个部门能监控掌门人的生死和武当其他弟子的生命状态，并且能够通过投票从武当弟子中选举一个能者担任新掌门，接着再举行新闻发布会向世界宣布新掌门的信息。这个「部门」就是哨兵。
哨兵在选举新掌门会遇到以下几个问题：
- 如何判断掌门真的挂了，有可能假死；
- 到底选择哪一个武当子弟作为新掌门？
- 通过新闻发布会将新掌门的相关信息通知到所有武当弟子（slave 和 master）和整个武林（客户端）。
哨兵部门主要负责的任务是：监控整个武当、选择新掌门，通知整个武当和整个武林。
哨兵机制的主要任务
哨兵是 Redis 的一种运行模式，它专注于对 Redis 实例（主节点、从节点）运行状态的监控，并能够在主节点发生故障时通过一系列的机制实现选主及主从切换，实现故障转移，确保整个 Redis 系统的可用性。结合 Redis 的 官方文档，可以知道 Redis 哨兵具备的能力有如下几个：
- 监控：持续监控 master 、slave 是否处于预期工作状态。
- 自动切换主库：当 Master 运行故障，哨兵启动自动故障恢复流程：从 slave 中选择一台作为新 master。
- 通知：让 slave 执行 replicaof ，与新的 master 同步；并且通知客户端与新 master 建立连接。
哨兵也是一个 Redis 进程，只是不对外提供读写服务，通常哨兵要配置成单数，为啥呢？且听「码哥字节」慢慢分析。
65 哥：那到底「哨兵」这个神秘部门是如何实现这三个能力的？
我们先从全局观看哨兵，简要的了解整个运作流程，接着再针对每一个任务详细分析。首先从监控开始…...
监控
Sentinel 只是武当弟子中的特殊部门，在默认情况下，Sentinel 通过飞鸽传书以每秒一次的频率向所有武当弟子、掌门与哨兵（包括 Master、Slave、其他 Sentinel 在内）发送 PING 命令，如果 slave 没有在在规定时间内响应「哨兵」的 PING 命令，「哨兵」就认为这哥们可能嗝屁了，就会将他记录为「下线状态」；
假如 master 掌门没有在规定时间响应 「哨兵」的 PING 命令，哨兵就判定掌门下线，开始执行「自动切换 master 掌门」的流程。
PING 命令的回复有两种情况：
- 有效回复：返回 +PONG、-LOADING、-MASTERDOWN 任何一种；
- 无效回复：有效回复之外的回复，或者再指定时间内返回任何回复。
65 哥：哨兵如何判断「掌门」嗝屁呢？掌门诈尸咋办？
为了防止掌门「假死」，「哨兵」设计了「主观下线」和「客观下线」两种暗号。
主观下线
哨兵利用 PING 命令来检测掌门、 slave 的生命状态。如果是无效回复，哨兵就把这个哥们标记为「主观下线」。检测到的是武当小弟，也就是 slave 角色。那么就直接标记「主观下线」。
因为 master 掌门还在，slave 的嗝屁对整个武当影响不大。依然可以对外开会，比武论剑、吃香喝辣…...
如果检测到是 master 掌门完蛋，这时候哨兵不能这么简单的标记「主观下线」，开启新掌门选举。
因为有可能出现误判，掌门并没有嗝屁，一旦启动了掌门切换，后续的选主、通知开发布会，slave 花时间与新 master 同步数据都会消耗大量资源。
所以「哨兵」要降低误判的概率，误判一般会发生在集群网络压力较大、网络拥塞，或者是主库本身压力较大的情况下。
既然一个人容易误判，那就多个人一起投票判断。哨兵机制也是类似的，采用多实例组成的集群模式进行部署，这就是哨兵集群。引入多个哨兵实例一起来判断，就可以避免单个哨兵因为自身网络状况不好，而误判主库下线的情况。
同时，多个哨兵的网络同时不稳定的概率较小，由它们一起做决策，误判率也能降低。
客观下线
判断 master 是否下线不能只有一个「哨兵」说了算，只有过半的哨兵判断 master 已经「主观下线」，这时候才能将 master 标记为「客观下线」，也就是说这是一个客观事实，掌门真的嗝屁了，华佗再世也治不好了。
只有 master 被判定为「客观下线」，才会进一步触发哨兵开始主从切换流程。
主观下线与客观下线的区别
简单来说，主观下线是哨兵自己认为节点宕机，而客观下线是不但哨兵自己认为节点宕机，而且该哨兵与其他哨兵沟通后，达到一定数量的哨兵都认为该哥们嗝屁了。
这里的「一定数量」是一个法定数量（Quorum），是由哨兵监控配置决定的，解释一下该配置：
# sentinel monitor <master-name> <master-host> <master-port> <quorum> # 举例如下： sentinel monitor mymaster 127.0.0.1 6379 2
这条配置项用于告知哨兵需要监听的主节点：
- sentinel monitor：代表监控。
- mymaster：代表主节点的名称，可以自定义。
- 192.168.11.128：代表监控的主节点 ip，6379 代表端口。
- 2：法定数量，代表只有两个或两个以上的哨兵认为主节点不可用的时候，才会把 master 设置为客观下线状态，然后进行 failover 操作。
「客观下线」的标准就是，当有 N 个哨兵实例时，要有 N/2 + 1 个实例判断 master 为「主观下线」，才能最终判定 Master 为「客观下线」，其实就是过半机制。
自动切换主库
65 哥：既然判断 master 客观下线了，那就要从选出一个新掌门人了吧。
「哨兵」的第二个任务，选择新 master 掌门。需要从武当弟子中按照一定规则选择一个牛逼人物作为新掌门，完成选任掌门后，新 master 带领众弟子一起吃香喝辣。
按照一定的「筛选条件」 + 「打分」策略，选出「最强王者」担任掌门，也就是通过一些条件海选过滤一些「无能之辈」，接着将通过海选的靓仔全都打分排名，将最高者选为新 master。
如图所示：
网络经常断开的靓仔也不可取，你想，即使变成 master，可是很快网络出了故障，又得重新选择新 master，这不闹着玩么，得排除掉！
筛选条件
65 哥：那都有哪些筛选条件呀？
- 从库当前在线状态，下线的直接丢弃；
- 评估之前的网络连接状态 down-after-milliseconds * 10：如果从库总是和主库断连，而且断连次数超出了一定的阈值（10 次），我们就有理由相信，这个从库的网络状况并不是太好，就可以把这个从库筛掉了。
打分
过滤掉不合适的 slave 之后，则进入打分环节。打分会按照三个规则进行三轮打分，规则分别为：
- slave 优先级，通过 slave-priority 配置项，给不同的从库设置不同优先级（后台有人没办法），优先级高的直接晋级为新 master 掌门。
slave_repl_offset与master_repl_offset进度差距（谁的武功与之前掌门的功夫越接近谁就更牛逼），如果都一样，那就继续下一个规则。其实就是比较 slave 与旧 master 复制进度的差距；
- slave runID，在优先级和复制进度都相同的情况下，ID 号最小的从库得分最高，会被选为新主库。 （论资排辈，根据 runID 的创建时间来判断，时间早的上位）；
通知
65 哥：为哈还要召开新闻发布会呢？
重新选举新 master 掌门这种事情，何等大事，怎能不告知天下。再者其他 slave 弟子也要知道新掌门是谁，一起追随新掌门吃香喝辣大保健。
最后一个任务，「哨兵」将新 「master 掌门」的连接信息发送给其他 slave 武当弟子，并且让 slave 执行 replacaof 命令，和新「master 掌门」建立连接，并进行数据复制学习新掌门的所有武功。
除此之外，「哨兵」还需要将新掌门的连接信息通知整个武林（客户端），使得让所有想拜访、讨教的人能找到新任掌门，这样诸多事宜才能交给新掌门做决定（将读写请求转移到新 master）。
哨兵的主要任务与实现目标
