背景说明：
这里采用1主2从的redis集群，3个sentinel搭建高可用redis集群。
一，关于搭建redis-sentinel高可用之前，我们必须要了解redis主从搭建redis-sentinel的基础。
redis-sentinel功能：
- 监控：哨兵不断的检查master和slave是否正常的运行。
- 通知：当监控的某台Redis实例发生问题时，可以通过API通知系统管理员和其他的应用程序。
- 自动故障转移：如果一个master不正常运行了，哨兵可以启动一个故障转移进程，将一个slave升级成为master，其他的slave被重新配置使用新的master，并且应用程序使用Redis服务端通知的新地址。
- 配置提供者：哨兵作为Redis客户端发现的权威来源：客户端连接到哨兵请求当前可靠的master的地址。如果发生故障，哨兵将报告新地址。
二， redis主从安装
详情见
https://www.cnblogs.com/lin1/p/10403333.html
三，安装redis-sentinel , 我这边3个节点都是在一台服务器上。
cd /usr/local/src
wget http://download.redis.io/releases/redis-3.0.7.tar.gz
tar -zxvf redis-3.0.7.tar.gz
cd redis-3.0.7
make
make PREFIX=/usr/local/redis-3.0.7 install
ln -s /usr/local/redis-3.0.7 /usr/local/redis
mkdir -p /usr/local/redis/conf
cp sentinel.conf /usr/local/redis/conf/sentinel-26379.conf (复制源码中的哨兵配置文件)
mkdir -p /usr/local/redis/logs
vim /usr/local/redis/conf/sentinel-26379.conf ，改成如下： 10.211.55.7是redis的主，mymaster是随意取的名字
port 26379 dir "/tmp" logfile "/usr/local/redis/logs/sentinel-26379.log" daemonize yes sentinel monitor mymaster 10.211.55.7 6379 2 sentinel auth-pass mymaster linlin sentinel down-after-milliseconds mymaster 15000 sentinel failover-timeout mymaster 120000 sentinel parallel-syncs mymaster 1 #发生切换之后执行的一个自定义脚本：如发邮件、vip切换等 #sentinel notification-script <master-name> <script-path>
vim /usr/local/redis/conf/sentinel-26380.conf
port 26380 dir "/tmp" logfile "/usr/local/redis/logs/sentinel-26380.log" daemonize yes sentinel monitor mymaster 10.211.55.7 6379 2 sentinel down-after-milliseconds mymaster 15000 sentinel failover-timeout mymaster 120000 sentinel auth-pass mymaster linlin sentinel config-epoch mymaster 0 #发生切换之后执行的一个自定义脚本：如发邮件、vip切换等 #sentinel notification-script <master-name> <script-path>
vim /usr/local/redis/conf/sentinel-26381.conf
port 26381 dir "/tmp" logfile "/usr/local/redis/logs/sentinel-26381.log" daemonize yes sentinel monitor mymaster 10.211.55.7 6379 2 sentinel down-after-milliseconds mymaster 15000 sentinel failover-timeout mymaster 120000 sentinel auth-pass mymaster linlin sentinel config-epoch mymaster 0 #发生切换之后执行的一个自定义脚本：如发邮件、vip切换等 #sentinel notification-script <master-name> <script-path>
三，启动redis-sentinel
cd /usr/local/redis/bin
./redis-sentinel ../conf/sentinel-26379.conf
./redis-sentinel ../conf/sentinel-26380.conf
./redis-sentinel ../conf/sentinel-26381.conf
启动之后 sentinel节点的配置文件，会默认生成部分配置段，该配置段其实就是标注从节点和master节点已经sentinel节点的。
当然，如果发生故障转移，redis中的配置也会发生变化。
四，查看日志，简单分析
sentinel-26379的日志，其他节点类似，这也是我们为什么没在redis-sentinel节点中配置从节点和其他sentinel节点的原因。他们会通过消息订阅进行数据交换。
五，模拟故障，查看故障是否转移
master端自动down掉，为此，这边直接使用kill命令演示。
master端：已经kill掉master端进程
查看日志：
master(6379)端日志： 无日志生成
slalve1 (6380)端日志：
丢失连接，放弃原先储存的master信息，并尝试继续连接，但是一直被拒绝。拒绝的时间31s,进行故障转移的时间为47s,故障转移完成时间为48s。（为啥这么快，其实跟我redis没有数据有很大关系 哈哈）
slave2 (6381)端日志：
sentinel-26379端日志：
sentinel-26380端日志：
sentinel-26381端日志:
从上述日志可以发现，故障已经转移，10.211.55.7 6381已经成为新的master,而原先的6379已经被下线了，但是仍然被关注中。
登陆最新的master端查看：
上述，就是故障转移成功了。接下来我们启动最早的master，查看是否会重新加入到redis集群中。
如下，可以发现原先的master,已经成为slave了。
以上，就是redis sentinel集群搭建的过程。测试过，如果一个sentinel挂掉，自动转移还是可以的哦。