如果我们不用哨兵，如何实现主从故障的转移呢？这事儿得手动来实现：
1、在从节点slave-1执行 slaveof no one ，将从节点变为主节点；
2、其它的节点，执行 slaveof slave-1的ip port，变为slave-1的从节点，并从新节点复制数据；
当然，有了哨兵机制我们就不用这么费事儿了，它的原理就是用raft算法实现选举机制，选出一个哨兵节点(哨兵也有主节点)来完成转移和通知；
哨兵有三个定时监控任务完成对各节点的发现和监控：
任务1，每个哨兵节点每10秒会向主节点和从节点发送info命令获取最新拓扑结构图，哨兵配置时只要配置对主节点的监控即可(sentinel monitor mymaster 192.168.1.3 26379 2)，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到
任务2，每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish和subscribe来完成的；
任务3，每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据
主观下线和客观下线：
主观下线：刚我知道知道哨兵节点每隔1秒对主节点和从节点、其它哨兵节点发送ping做心跳检测，当这些心跳检测时间超过down-after-milliseconds时，哨兵节点则认为该节点错误或下线，这叫主观下线；这可能会存在错误的判断。
客观下线：当主观下线的节点是主节点时，此时该哨兵3节点会通过指令sentinel is-masterdown-by-addr寻求其它哨兵节点对主节点的判断，当超过quorum（法定人数）个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意下线操作，也就说是客观下线
领导者哨兵选举流程：
a、每个在线的哨兵节点都可以成为领导者，当它确认（比如哨兵3）主节点下线时，会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；
b、当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者；
c、如果哨兵3发现自己在选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举…………
故障转移机制
A，由Sentinel节点定期监控发现主节点是否出现了故障，sentinel会向master发送心跳PING来确认master是否存活，如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了，会要求其他sentinel确认该节点是否丢失，如果确认，则认为是客观下线，的确不可用了，开始进行故障转移；
B，当主节点出现故障，此时3个Sentinel节点共同选举了Sentinel3节点为领导，负载处理主节点的故障转移,
C，由Sentinel3领导者节点执行故障转移，过程和主从复制一样，但是自动执行
流程： 1，将slave-1脱离原从节点，升级主节点，
2，将从节点slave-2指向新的主节点
3，通知客户端主节点已更换
4，将原主节点（oldMaster）变成从节点，指向新的主节点
D，故障转移后的redis sentinel的拓扑结构图
哨兵机制－故障转移详细流程
A，过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点
B，选择salve-priority从节点优先级最高（redis.conf）
C，选择复制偏移量最大，指复制最完整的从节点
哨兵部分，over
