从redis的主从配置可以发现，里边没有提供高可用机制。如果master挂了，slave是不会自动选举出一个master接替工作的，显然这是不能接受的。而哨兵机制就是用来解决此问题的。
哨兵的配置跟启动：
1、redis文件夹下有sentinel.conf文件，复制三份，分别命名为sentinel26379.conf、sentinel26380.conf跟sentinel26381.conf。
2、哨兵配置文件默认端口为26379，将三个配置文件端口分别改为26379、26380跟26381。
3、三个配置文件均设置所监控的主节点：sentinel monitor mymaster 192.168.1.3 26379 2
4、关闭保护模式，protected-mode no
5、将redis的主从三个机器的redis启动。
6、启动三个哨兵：
./redis-sentinel /work/redis-4.0.6/mymaster_slave/sentinel26379.conf &
./redis-sentinel /work/redis-4.0.6/mymaster_slave/sentinel26380.conf &
./redis-sentinel /work/redis-4.0.6/mymaster_slave/sentinel26381.conf &
7、redis-cli -h 192.168.1.3 -p 26379 登录其中一个哨兵，执行：sentinel master mymaster，正常启动后结果如下：
测试高可用性：
1、用info replication命令可以查看到当前redis主节点为6379，从节点为6380跟6381
2、关闭主节点6379，可以看到redis开始的时候一直在控制台输出信息：
然后大约20秒，删除信息如下：
从输出的日志可以看到，哨兵检测到master节点6379失去连接，开始多次进行跟主节点连接，多次均失败后开始选举主节点，然后切换主节点，然后从节点连接主节点开始数据同步；
这时候，如果原主节点再次连接，会先跟当前的哨兵进行沟通，发现已经有主节点后会修改自身节点为slave，然后以slave的身份进行运行。
新选举出的6381主节点：
再次连入6379，变为从节点(开始的跟哨兵沟通并进行切换的过程忘记截图了，，，，，)
而且，在master选举后，配置文件中的slaveof 192.xxx.xx.xx port也会随之更改。
