接下来我们就介绍一下哨兵模式，我们会从以下几个方面进行介绍：
- 哨兵简介
- 启用哨兵模式
- 哨兵工作原理
假如master主机“宕机”了，我们要做的就是把宕机的master干掉，然后从剩余的slave中选出一个master
下图是挑选出新的master
在主master宕机到选择出新的master，中间经历了什么。如下：
- 将宕机的master下线
- 找一个slave作为master
- 通知所有的slave连接新的master
- 启动新的master与slave
- 全量复制*N+部分复制*N（重启后有可能是N台slave全量复制+部分复制）
那么问题来了……
谁来确认master宕机了？
找一个主？怎么找法？
修改配置后，原始的主恢复了怎么办？
这个时候哨兵就来了
哨兵
哨兵（sentinel）是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master并将所有slave连接到新的master
哨兵的作用
1.监控
不断的检查master和slave是否正常运行
Master存活检测、master与slave运行情况检测
2.通知（提醒）
当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知
3.自动故障转移
断开master与slave连接，选取一个slave作为master，将其他slave连接到新的master，并告知客户端新的服务器地址
注意：哨兵也是一台redis服务器，只是不提供数据服务
通常哨兵配置数量为单数
配置哨兵
- 配置一拖二主从结构
- 配置三个哨兵（配置相同，端口不同）
参看sentinel.conf
- 启动哨兵
redis-sentinel sentinel-端口号.conf
查看配置文件
cat sentinel.conf |grep -v “#” |grep -v “^$” > ./conf/sentinel-26379.conf
上面的的命令是过滤掉#的注释和换行，然后将这个文件中过滤后的内容复制到后面的文件中
哨兵工作原理
阶段一：监控阶段
用于同步各个节点的状态信息
获取各个sentinel的状态（是否在线）
获取master的状态
Master属性
runid
role：master
各个slave的详细信息
获取所有slave的状态（根据master中的slave信息）
Slave属性
runid
role：slave
master_host、master_port
offset
……
阶段二：通知阶段
阶段三：故障转移阶段
主观下线：一台sentinel认为挂了
客观下线：超过半数sentinel认为挂了
sentinel1认为master挂了，然后标志主观下线，然后它在sentinel圈内传播，然后sentinel2、sentinel3向master发起呼叫，如果超过半数没有回应，则标志其为客观下线。
然后清理队伍，清理队伍之前先选择一个领头的master
首先会把挂掉的ip、端口发到内部群里，然后说一下自己参与过的竞选次数，然后告诉别人自己的runid，让大家选自己，比如1和4同时将信息发到内部群里，2先接到谁的就把这一票投给谁。按照这个机制，最后会得到一个投票的结果。如果没有得到一个好的结果，然后竞选次数增加一，继续竞选
发送：SENTINEL is-master-down-by-addr ……
挂掉的ip
挂掉的端口
竞选次数
自己的runid
下面我们来看整个过程图
sentinel1和sentinel4同时向sentinel2发送信息，让选自己
sentinel2很尴尬，都是好哥们，它会根据接收的先后顺序去选择
其他哨兵也同样投票
最终sentinel1以绝对的优势胜出，当选皇帝
最后sentinel1成功当选处置人选。
然后开始处置
服务器列表中挑选备选master
不在线的（OUT）
响应慢的（OUT）
与原master断开时间久的（OUT）
优先原则
优先级
offset(优先级一样，看偏移量)
runid(如果偏移量一样，则论资排)
发送指令（sentinel）
向新的master发送slaveof no one
向其他slave发送slaveof新masterIP端口
总结：
- 监控
同步信息
- 通知
保持联通
- 故障转移
发现问题
竞选负责人
优选新master
新master上任，其他slave切换master，原master作为slave故障恢复后连接