Redis哨兵比主从复制多了 sentinel 节点，当主节点出现故障的时候，有 sentinel 自动完成故障发现和转移，并通知应用方，实现高可用。
哨兵如何监控节点？
哨兵有三个定时监控任务完成对各节点的发现和监控。
- 每隔10秒，发一次info
- 每隔2秒发一次，publish/subscribe
- 每隔1秒发一次ping（主要靠这种方式）
故障转移
哨兵什么时候可以判断一个节点挂了呢？哨兵也是一个集群，当其中一个哨兵发一个 ping 给 mater 节点，发现在一定时间范围内没有收到 master 的响应，这个哨兵就会认为节点挂了，这个叫做主观下线。一个哨兵是有可能看差匹的，所以主观下线不能确定节点真的已经挂了，还需要其他节点确认。
发现某个节点 ping 不通的哨兵，会通知其它哨兵去检查这个节点是不是真的挂了。如果其他节点也 ping 不通这个节点，那就是哨兵一致认为这个节点挂了，这叫做客观下线。
当 sentinel 集群确认一个 master 节点已经挂了，就会选举一个节点负责故障转移。
接着被选举为 leader 的 sentinel3 就会执行故障转移，过程就和主从复制一样：
- slave-1执行：slaveof no one 解除从节点身份，变为新master
- slave-2 变成新 master 的从节点 slaveof new master
- 同样，若原主节点恢复，也变成新主节点的从节点
- 通知应用程序，新主节点的地址
整个过程如下所示：
如何安装与部署 Redis Sentinel
监控一个 redis 主节点
我们以3个Sentinel节点、2个从节点、1个主节点为例进行安装部署。
先搭建好主从：
先搭建好一主两从redis的主从复制：
A主节点6379节点（/usr/local/bin/conf/redis6379.conf）：
修改 requirepass 12345678，注释掉bind 192.168.42.111
B从节点redis6380.conf和redis6381.conf:
修改 requirepass 12345678 ,注释掉#bind 192.168.42.111,
加上masterauth 12345678 ,加上slaveof 192.168.42.111 6379
注意：当主从起来后，主节点可读写，从节点只可读不可写
哨兵机制核心配置
redis sentinel哨兵机制配置(也是3个节点)：
/usr/local/bin/conf/sentinel_26379.conf
/usr/local/bin/conf/sentinel_26380.conf
/usr/local/bin/conf/sentinel_26381.conf
将三个文件的端口改成: 26379 26380 26381
sentinel monitor mymaster 192.168.42.111 6379 2 //监听主节点6379
sentinel auth-pass mymaster 12345678 //连接主节点时的密码
三个配置除端口外，其它一样
配完此脚本，哨兵机制可正常启动运行。
哨兵其它配置
sentinel monitor mymaster 192.168.42.111 6379 2 //监控主节点的IP地址端口
sentinel auth-pass mymaster 12345678 //sentinel连主节点的密码
sentinel config-epoch mymaster 2 //执行故障转移时， 最多可以有多少个从节点同时对新的主节点进行数据同步
sentinel leader-epoch mymaster 2
sentinel failover-timeout mymaster 180000 //故障转移超时时间180s，
a,如果转移超时失败，下次转移时时间为之前的2倍；
b,从节点变主节点时，从节点执行slaveof no one命令一直失败的话，当时间超过180S时，则故障转移失败
c,从节点复制新主节点时间超过180S转移失败
sentinel down-after-milliseconds mymaster 300000//sentinel节点定期向主节点ping命令
启动sentinel服务:
./redis-sentinel conf/sentinel_26379.conf &
./redis-sentinel conf/sentinel_26380.conf &
./redis-sentinel conf/sentinel_26381.conf &
RedisSentinel节点测试
测试：kill -9 6379 杀掉6379的redis服务
看日志是分配6380 还是6381做为主节点，当6379服务再启动时，已变成从节点
假设6380升级为主节点:
进入6380>info replication
role:master
打开sentinel_26379.conf等三个配置，
sentinel monitor mymaster 192.168.42.111 6380 2 //有2个sentinel认为master下线
打开redis6379.conf等三个配置, slaveof 127.0.0.1 6380,也变成了6380
注意：生产环境建议让redis Sentinel部署到不同的物理机上。
坑点：sentinel monitor mymaster 192.168.42.111 6379 2
//切记将IP不要写成127.0.0.1
不然使用JedisSentinelPool取jedis连接的时候会变成取127.0.0.1 6379的错误地址
监控两个 redis 主节点
我们以3个Sentinel节点、2个从节点、2个主节点为例进行安装部署
原配置加上一句：sentinel monitor mymasterB 192.168.1.112 6379 2。
部署建议
a，sentinel节点应部署在多台物理机（线上环境）
b，至少三个且奇数个sentinel节点
c，3个sentinel可同时监控一个主节点或多个主节点，当监听N个主节点较多时，如果sentinel出现异常，会对多个主节点有影响，同时还会造成sentinel节点产生过多的网络连接，一般线上建议还是， 3个sentinel监听一个主节点
哨兵 API
命令：redis-cli -p 26379 //进入哨兵的命令模式，使用redis-cli进入
26379> sentinel masters或sentinel master mymaster
26379> sentinel slaves mymaster
26379> sentinel sentinels mymaster //查sentinel节点集合(不包括当前26379)
26379> sentinel failover mymaster //对主节点强制故障转移，没和其它节点协商
./redis-cli -p 26380 shutdown //关闭
客户端连接
远程客户端连接时，要打开protected-mode no
在使用工程redis-sentinel，调用jedis查询的流程如下：
1，将三个sentinel的IP和端口 加入JedisSentinelPool
2，根据IP和地址创建JedisSentinelPool池对象
3，在这个对象创建完后，此时该对象已把redis的主节点