年底了，这一个月下来每天加班搞技术规划和年底总结，对程序员来讲，每年年底些PPT应该是最痛苦的了吧，比代码难多了有木有！！
周六周日去上课，今天终于把pmp考完了，接下来终于可以静下心来写博客啦！
上周更到了redis的redis主从复制，今天继续学习redis的哨兵机制。在了解哨兵机制之前，我们先了解下什么是高可用。
一、什么是高可用？
=============
1、什么是高可用
redis已经实现主从复制了，即使挂了一台或者服务硬盘坏掉，数据存在同步备份。那它还不是高可用吗？当然！不是~
高可用的定义一般有以下两个解释：
解释1：它与被认为是不间断操作的容错技术有所不同。是目前企业防止核心系统因故障而无法工作的最有效保护手段
解释2：高可用一般指服务的冗余，一个服务挂了，可以自动切换到另外一个服务上，不影响客户体验。
主要就是当我们服务存在异常的时候，可以自动进行容错或者抵抗异常，从而达到不影响到用户正常使用的一种技术
2、主从复制是否高可用分析
1，主从复制，若主节点出现问题，则不能提供服务，需要人工修改配置将从变主
A，主节点(master)故障，从节点slave-1端执行 slaveof no one后变成新主节点；
B，其它的节点成为新主节点的从节点，并从新节点复制数据；
C，需要人工干预，无法实现高可用。
2，主从复制主节点的写能力单机，能力有限
3，单机节点的存储能力也有限
因此，主从复制并不能满足我们高可用的要求。
二、什么是哨兵机制
=============
Sentinel（哨兵）是Redis 的高可用性解决方案：由一个或多个Sentinel 实例 组成的Sentinel 系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。
原理：当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性
三、redis哨兵机制的实现
==================
1、哨兵主要任务
哨兵主要有三个定时监控任务完成对各节点的发现和监控。
**任务1：**每个哨兵节点每10 秒会向主节点和从节点发送info 命令获取最拓扑结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到
任务2，每个哨兵节点每隔2 秒会向redis 数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish 和subscribe 来完成的；
任务3，每隔1 秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping 命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据
2、哨兵发现服务下线
哨兵主观下线
主观下线：刚我知道哨兵节点每隔 1 秒对主节点和从节点、其它哨兵节点发送 ping 做心跳检测，当这些心跳检测时间超过 down-after-milliseconds 时，哨兵节点则认为该节点 错误或下线，这叫主观下线；当然这但不代表这个master真的不能用(有可能网络波动导致该哨兵与服务连接异常)，所以主观下线是不可靠的，可能存在误判
哨兵客观下线
客观下线：当主观下线的节点是主节点时，此时该哨兵3 节点会通过指令sentinelis-masterdown-by-addr 寻求其它哨兵节点对主节点的判断，当超过quorum（法定人数）个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意下线操作，也就说是客观下线
一般来说客观下线满足大多数原则，因此是可靠的判断。
