首先感谢“吧喱公路”的引导，打开了我对哨兵的理解思路，再次谢谢。
Redis的哨兵（sentinel）
哨兵适用于非集群结构的redis环境，比如：redis主从环境。
关于哨兵集群，我这里就不做实验了，网上有大量的配置方法。
哨兵集群的核心思想，就是解决哨兵的单点故障问题。
个人认为，有做哨兵集群的经费，不如直接做个redis集群了。
环境描述：（主从从结构）
master：192.168.2.100：6379 #单节点sentinel运行在这个环境上
slave：192.168.2.200:6379
savle：192.168.2.201:6379
redis安装路径：/usr/local/redis-3.0.6-6379
redis.conf关键配置：（这里不絮诉基本配置了，主从配置参考：https://blog.51cto.com/13690439/2118890）
master：
# vim redis.conf
requirepass "123456" //设置连接master密码
masterauth "123456" //登录master时，调用该参数
slave：
# vim etc/redis.conf
slaveof 192.168.2.100 6379 //指定主库IP和端口
requirepass "123456" //之所以3个redis都这样写，是为了故障切换后，info replication显示slave0信息
masterauth 123456 //登录master时，调用该参数
哨兵关键配置：（sentinel.conf）
# vim sentinel.conf
port 26379 //端口
sentinel monitor mymaster 192.168.2.100 6379 1
//master-name可以自定义、监听IP：port 几个sentinel认为故障时，才算真正的故障
sentinel down-after-milliseconds mymaster 3000
//哨兵发送PING消息，等待PONG消息的时间，超过设定时间表示故障；毫秒
sentinel failover-timeout mymaster 10000
//故障转移（failover）超时时间，超过设定时间表示故障转移失败；毫秒
sentinel auth-pass mymaster 123456 //设置连接master需要的密码
启动master的redis:
# redis-server redis.conf
启动哨兵：（新开一个xshell）
# redis-sentinel sentinel.conf
启动slave的redis:
# redis-server redis.conf
哨兵的输出：
# Sentinel runid is e49df1197325687d9a40508c00f466a8c6e596db
//哨兵ID
# +monitor master mymaster 192.168.2.100 6379 quorum 1
//+monitor：增加了一个master监控，后面就是master的信息
* +slave slave 192.168.2.200:6379 192.168.2.200 6379 @ mymaster 192.168.2.100 6379
//+salve：增加了一个salve监控，后面是salve的信息
* +slave slave 192.168.2.201:6379 192.168.2.201 6379 @ mymaster 192.168.2.100 6379
//+salve：增加了一个salve监控，后面是salve的信息
master上登录redis：
# redis-cli -h 192.168.2.100 -p 6379 -a 123456
192.168.2.100:6379> set name zhangsan
OK
192.168.2.100:6379> set age 26
OK
192.168.2.100:6379> set home beijing
OK
192.168.2.100:6379> keys *
1) "name"
2) "home"
3) "age"
salve上登录redis：（两个salve登录查看，数据同步正常）
# redis-cli -h 192.168.2.200 -p 6379 -a 123456
192.168.2.200:6379> keys *
1) "name"
2) "home"
3) "age"
停止master的redis：（注意观察哨兵的输出）
# ps -ef |grep redis
root 11467 1 0 17:12 ? 00:00:00 redis-server *:6379
root 11473 4650 0 17:12 pts/1 00:00:00 redis-sentinel *:26379 [sentinel]
root 11513 4339 0 17:16 pts/0 00:00:00 grep --color=auto redis
# kill 11467
哨兵的输出：
# +sdown master mymaster 192.168.2.100 6379
//+sdown：master节点挂了。后面是master信息
# +odown master mymaster 192.168.2.100 6379 #quorum 1/1
# +new-epoch 14
# +try-failover master mymaster 192.168.2.100 6379
//开始恢复故障
# +vote-for-leader e49df1197325687d9a40508c00f466a8c6e596db 14
//投票选举节点的哨兵信息，因为我们就一个哨兵，所以就是自己 leader
# +elected-leader master mymaster 192.168.2.100 6379
//选举节点后替换谁
# +failover-state-select-slave master mymaster 192.168.2.100 6379
//开始为故障的master选举
# +selected-slave slave 192.168.2.200:6379 192.168.2.200 6379 @ mymaster 192.168.2.100 6379
//节点选举结果，选中192.168.2.200:6379来替换master
* +failover-state-send-slaveof-noone slave 192.168.2.200:6379 192.168.2.200 6379 @ mymaster 192.168.2.100 6379
//确认节点选举结果
* +failover-state-wait-promotion slave 192.168.2.200:6379 192.168.2.200 6379 @ mymaster 192.168.2.100 6379
//选中的节点正在升级为master
# +promoted-slave slave 192.168.2.200:6379 192.168.2.200 6379 @ mymaster 192.168.2.100 6379
//选中的节点已成功升级为master
# +failover-state-reconf-slaves master mymaster 192.168.2.100 6379
//切换故障master的状态
* +slave-reconf-sent slave 192.168.2.201:6379 192.168.2.201 6379 @ mymaster 192.168.2.100 6379
//
* +slave-reconf-inprog slave 192.168.2.201:6379 192.168.2.201 6379 @ mymaster 192.168.2.100 6379
//其他节点同步故障master信息
* +slave-reconf-done slave 192.168.2.201:6379 192.168.2.201 6379 @ mymaster 192.168.2.100 6379
//其他节点完成故障master的同步
# +failover-end master mymaster 192.168.2.100 6379
//故障恢复完成
# +switch-master mymaster 192.168.2.100 6379 192.168.2.200 6379
//master从192.168.2.100:6379 变为 192.168.2.200:6379
* +slave slave 192.168.2.201:6379 192.168.2.201 6379 @ mymaster 192.168.2.200 6379
//其他节点指定新的master
* +slave slave 192.168.2.100:6379 192.168.2.100 6379 @ mymaster 192.168.2.200 6379
//故障master指定新的master
# +sdown slave 192.168.2.100:6379 192.168.2.100 6379 @ mymaster 192.168.2.200 6379
//192.168.2.100:6379宕机，待恢复
启动master的redis（注意观察哨兵的输出）
# redis-server redis.conf
哨兵的输出：
# -sdown slave 192.168.2.100:6379 192.168.2.100 6379 @ mymaster 192.168.2.200 6379
//故障master节点已经恢复
* +convert-to-slave slave 192.168.2.100:6379 192.168.2.100 6379 @ mymaster 192.168.2.200 6379
//故障master节点变为salve，他的master为192.168.2.200:6379
现在我们查看主从的状态：
192.168.2.100上查看：
# redis-cli -h 192.168.2.100 -p 6379 -a 123456
192.168.2.100:6379> info replication
# Replication
role:slave
master_host:192.168.2.200
master_port:6379
master_link_status:up
192.168.2.100:6379> set ab 123
(error) READONLY You can't write against a read only slave.
192.168.2.100:6379> get name
"zhagnsan"
192.168.2.201上查看：
# redis-cli -h 192.168.2.201 -p 6379 -a 123456
192.168.2.201:6379> info replication
# Replication
role:slave
master_host:192.168.2.200
master_port:6379
master_link_status:up
192.168.2.201:6379> set ab 123
(error) READONLY You can't write against a read only slave.
192.168.2.201:6379> get name
"zhagnsan"
192.168.2.200上查看：
# redis-cli -h 192.168.2.200 -p 6379 -a 123456
192.168.2.200:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.2.201,port=6379,state=online,offset=24990,lag=1
slave1:ip=192.168.2.100,port=6379,state=online,offset=24990,lag=0
192.168.2.200:6379> set ab 123
OK
192.168.2.200:6379> keys *
1) "name"
2) "home"
3) "age"
4) "ab"
总结：通过哨兵（sentinel）实现了主从从环境高可用效果。
master在宕机后，通过哨兵自动将其中一个salve提升为master，切换过程中，数据保存完整。
但我们也发现，原master不能继续插入key了， 而客户端连接还是会连原master，
这时，我们就需要在数据库连接池做一些规则设置了。
由于目前我能力有限，无法解释连接池问题，还请见谅。
另外有需要云服务器可以了解下创新互联cdcxhl.cn，海内外云服务器15元起步，三天无理由+7*72小时售后在线，公司持有idc许可证，提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案，具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势，专为企业上云打造定制，能够满足用户丰富、多元化的应用场景需求。
