一、哨兵简介
如果master宕机了，哨兵会找一个slave作为master，通知其他所有的slave连接新的master，启动新的master与slave，进行数据同步（全量复制*N+部分复制 *N）
这个过程有几个问题：谁来确认master宕机了？用什么方法找一个master？修改配置后，原始的master恢复了怎么办？
哨兵（sentinel) ：是一个对主从结构中的每台服务器进行监控的分布式系统 ，当出现故障时通过投票机制选择新的master，并将所有slave连接到新的master；哨兵也是一台redis服务器，只是不提供数据服务，通常哨兵配置数量为奇数（防止投票时打平）
哨兵的作用
- 监控：不断地进行master存活检测、master与slave运行情况检测
- 通知（提醒）：当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知
- 自动故障转移：断开宕机的master与slave连接，选取一个slave作为master，将其他slave连接到新的master，并告知客户端新的服务器地址
二、配置哨兵模式
配置一拖二的主从结构，配置三个哨兵（配置相同，端口不同），配置文件为Redis根目录下的sentinel.conf
启动哨兵
redis-sentinel sentinel-端口号.conf
1. 编写哨兵的配置文件
bash
# 哨兵服务占用的端口
port 26379
# dir存放哨兵工作日志
dir /tmp
# mymaster：表示哨兵监控的master，名字可以任意取
# 2：如果有2个哨兵认为mymaster挂了，那这个master就真的挂了，通常设置为哨兵总数的一半 + 1
sentinel monitor mymaster 127.0.0.1 6379 2
# mymaster 30000ms没响应，哨兵就认为mymaster挂了
sentinel down-after-milliseconds mymaster 30000
# 新的master选出来后，一次和几个slave进行数据同步
# 这个值越小，对服务器压力越小，同步速度越慢；这个值越大，对服务器压力越大，同步速度越快
sentinel parallel-syncs mymaster 1
# 如果同步时间超过180000ms，就认为数据同步超时
sentinel failover-timeout mymaster 180000
修改一下哨兵日志目录
修改端口，生成另外两个哨兵的配置文件。三个哨兵使用的端口分别是26379、26380、26381
2. 编写redis服务器的配置文件
查看redis服务器配置文件，6379为master，6380为slave
生成6381的slave
3. 启动redis服务器以及哨兵
启动一主两从三个redis服务器
启动26379哨兵
通过客户端登录已启动的26379哨兵服务器
在哨兵服务器上不能执行数据操作，只能执行哨兵对应的一些指令，我们输入info命令查看信息
info输出的信息中，我们可以看到哨兵监视的master以及master对应的slave数量，以及当前监视此master的哨兵数量
查看一下当前启动的26379哨兵对应的配置文件，发现配置文件改变了
启动26380哨兵
我们再查看一下26379哨兵的配置文件
此时26379哨兵服务器端也有2638哨兵监视master的提示信息。我们现在知道了，每启动一个新的哨兵去监视同一个master，哨兵之间都可以相互识别
同理，3个哨兵监视同一个master，三个哨兵的配置文件以及终端提示信息都是相互的，都能互相检测到
4. 验证哨兵的作用
如果master宕机了，哨兵会找一个slave作为master，通知其他所有的slave连接新的master。我们演示一下这个功能
我们先退出master
我们在哨兵配置文件中设置的是，30000ms内master没有响应，哨兵则认为master已经宕机，30000ms后，哨兵1的终端有如下提示信息：
作为master的6379下线后，主要过程就是所有哨兵都去确认6379是否真的下线，都确定6379下线后开始投票，从slave中选出新的master，然后为其他的slave更改master。并把下线的旧6379master设置为slave，后面6379上线后直接就是slave
我们启动6379 redis服务器
查看26379的提示信息，发现6379成为slave
三、哨兵工作原理
哨兵在进行主从切换过程中经历三个阶段：监控、通知、故障转移
- 监控：同步信息
- 通知：保持联通
- 故障转移：发现问题、竞选sentinel、优选新master、新master上任，其他slave切换master，原master恢复后成为slave
1. 监控
用于同步各个节点的状态信息
- 哨兵给其他哨兵发ping，获取各个sentinel的状态（是否在线）
- 获取master的状态和master属性，包括runid、role等
- 根据master中的slave信息，再找各个slave获取它们的详细信息，包括slave的runid、role、master_host、master_port、offset等
接下来详细说一下，哨兵、master和slave之间如何交换信息的
这时第一个哨兵上线连接master，拿到master的info，同时master也拿到哨兵的info。然后根据从master拿到的有关slave的信息，去连接slave，然后再拿到slave的info，至此第一个哨兵拿到了master和所有slave的info
然后第二个哨兵上线连接master，从master拿到info，从master的info就可以知道当前主从环境中master、slave、sentinel的数量以及ip:port，然后这个哨兵就去找其他的slave和sentinel交换信息
拿信息的同时会在sentinel之间建立发布-订阅通道，以共享info
第三个sentinel连接master上线后，就会获取当前所有的master、slave、sentinel的info，并加入sentinel的发布-订阅通道
2. 通知
sentinel会轮流询问master和slave的信息，然后在sentinel的朋友圈发布，其他sentinel进行订阅
3. 故障转移
首先sentinel1不断询问master，一直没响应，直到超过哨兵配置文件中的时间则认为这个master挂了，于是sentinel1把master的状态标记为sdown（主观下线），然后会在朋友圈发信息说master挂了
于是其他sentinel也不断询问master，看看有无回应。如果超过半数的sentinel后觉得master挂了，那就把master的状态标记为odown（客观下线）
master一旦标记为odown，sentinels就会开会，通过一定的算法选出一个sentinel去从slave中挑选新的master
现在sentinel会根据以下原则选出新的master：在线的、响应快的、与原master信息交互多的、offset大的（数据同步及时）、runid等等
选出新的master后，sentinel会做如下操作：
- 给新的master发送salve of no one，断开新master与原master的主从关系
- 向其他slave发送新master的ip:port，让其他slave重新确定master