sentinel机制也就是我们一直说的哨兵机制，这种机制其实很常见的，一般情况下为了保证集群高可用都采用类似的机制，下文来学习一下redis的哨兵机制。
sentinel启动命令
redis-sentinel sentinel.conf
sentinel机制图示
过程：
多个sentinel发现并确认master有问题
选举出一个sentinel作为领导
选出一个slave作为master
通知其余slave成为新的master的slave
通知客户端主从变化
等待老的master复活成为新的master的slave
创建sentinel.conf配置文件
port 26379
daemonize yes
# sentinel announce-ip <ip>
# sentinel announce-port <port>
dir /opt/redis-4.0.11/data
sentinel monitor mymaster 127.0.0.1 6379 2
# sentinel auth-pass <master-name> <password>
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
# sentinel notification-script <master-name> <script-path>
配置文件说明：
- port :当前Sentinel服务运行的端口
- dir : Sentinel服务运行时使用的临时文件
- sentinel monitor master001 192.168.110.10163792:Sentinel去监视一个名为master001的主redis实例，这个主实例的IP地址为本机地址192.168.110.101，端口号为6379，而将这个主实例判断为失效至少需要2个 Sentinel进程的同意，只要同意Sentinel的数量不达标，自动failover就不会执行3.sentinel monitor master001 192.168.110.10163792:Sentinel去监视一个名为master001的主redis实例，这个主实例的IP地址为本机地址192.168.110.101，端口号为6379，而将这个主实例判断为失效至少需要2个 Sentinel进程的同意，只要同意Sentinel的数量不达标，自动failover就不会执行
- sentinel down-after-milliseconds master001 30000:指定了Sentinel认为Redis实例已经失效所需的毫秒数。当实例超过该时间没有返回PING，或者直接返回错误，那么Sentinel将这个实例标记为主观下线。只有一个 Sentinel进程将实例标记为主观下线并不一定会引起实例的自动故障迁移：只有在足够数量的Sentinel都将一个实例标记为主观下线之后，实例才会被标记为客观下线，这时自动故障迁移才会执行
- sentinel parallel-syncs master001 1：指定了在执行故障转移时，最多可以有多少个从Redis实例在同步新的主实例，在从Redis实例较多的情况下这个数字越小，同步的时间越长，完成故障转移所需的时间就越长
- sentinel failover-timeout master001 180000：如果在该时间（ms）内未能完成failover操作，则认为该failover失败
- sentinel notification-script <master-name > <script-path>：指定sentinel检测到该监控的redis实例指向的实例异常时，调用的报警脚本。该配置项可选，但是很常用.
三个定时任务
（1）每隔10s每个sentinel会对master节点和slave节点执行info命令
作用就是发现slave节点，并且确认主从关系，因为redis-Sentinel节点启动的时候是知道
master节点的，只是没有配置相应的slave节点的信息
（2）每隔两秒，sentinel都会通过master节点内部的channel来交换信息（基于发布订阅）
作用是通过master节点的频道来交互每个Sentinel对master节点的判断信息
（3） 每隔一秒每个sentinel对其他的redis节点（master，slave，sentinel）执行ping操作，对于master来说
若超过30s内没有回复，就对该master进行主观下线并询问其他的Sentinel节点是否可以客观下线
故障转移过程
1. 领导者选举
作用：选举出一个sentenel节点作为领导者去进行故障转移操作。
过程：
1). 每个做主观下线的sentinel节点向其他sentinel节点发送上面那条命令，要求将它设置为领导者。
2). 收到命令的sentinel节点如果还没有同意过其他的sentinel发送的命令（还未投过票），那么就会同意，否则拒绝。
3). 如果该sentinel节点发现自己的票数已经过半且达到了quorum的值，就会成为领导者。
4). 如果这个过程出现多个sentinel成为领导者，则会等待一段时间重新选举。
2. 选出新的master节点
redis sentinel会选一个合适的slave来升级为master，那么，如何选择一个合适的slave呢？顺序如下：
1). 选择slave-priority最高的slave节点（默认是相同）。
2). 选择复制偏移量最大的节点。
3). 如果以上两个条件都不满足，选runId最小的（启动最早的）。
3. 更改slave节点的master节点
当选举出新的master节点后，会将其余的节点变更为新的master节点的slave节点，如果原有的master节点重新上线，成为新的master节点的slave节点。
4. 通知客户端
当所有节点配置结束后，sentinel会通知客户端节点变更信息。
5. 客户端连接新的master节点
客户端收到节点信息后，会连接新的master节点。