这样就提高了系统扩展性，因为不再受限于Redis从实例设置。但如果Redis主实例挂了，就比较尴尬了。不过，我们也可以继续深入去进行Redis主实例监听，从而便于进行主从切换等。
而这儿，就引出了哨兵机制。
（不是只谈安装嘛。但是一时忍不住，就简单谈一下自己的思路哈）
哨兵机制正如其名，哨兵机制类似于一个Redis主从集群的代理，对应用程序透明，从而避免应用程序与Redis集群机制的高度耦合。
说个人话，哨兵会根据Redis集群情况，自行进行主从切换，从而确保为应用程序提供有效的Redis缓存服务。
接下来就开始Redis哨兵机制的部署吧。
启动Redis主从集群Redis哨兵机制是基于Redis主从集群的。所以首先，需要根据前面的操作步骤，安装并启动Redis主从集群。
前面有详谈，这里不再赘述。
哨兵机制的配置话不多说，直接上配置：
# 配置文件：sentinel.conf，在sentinel运行期间是会被动态修改的 # sentinel如果重启时，根据这个配置来恢复其之前所监控的redis集群的状态 # 绑定IP #bind 0.0.0.0 # 后台运行 daemonize yes # 默认yes，没指定密码或者指定IP的情况下，外网无法访问 protected-mode no # 哨兵的端口，客户端通过这个端口来发现redis port 26380 # 哨兵自己的IP，手动设定也可自动发现，用于与其他哨兵通信 # sentinel announce-ip # 临时文件夹 dir "/developer/redis/tmp" # 日志 logfile "/developer/redis/logs/sentinel-26380.log" # sentinel监控的master的名字叫做mymaster,(redis的master服务器，哨兵需要通过这个master获取集群信息）初始地址为 172.26.40.223 6379,2代表两个及以上哨兵认定为死亡，才认为是真的死亡，即客观下线。由于目前是单个哨兵，所以设置为1，即主观下线等同客观下线。 #sentinel monitor mymaster 172.26.40.223 6379 2 sentinel monitor mymaster 172.26.40.223 6379 1 # 发送心跳PING来确认master是否存活 # 如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了 sentinel down-after-milliseconds mymaster 1000 # 如果在该时间（ms）内未能完成failover操作，则认为该failover失败 sentinel failover-timeout mymaster 3000 # 指定了在执行故障转移时，最多可以有多少个从Redis实例在同步新的主实例，在从Redis实例较多的情况下这个数字越小，同步的时间越长，完成故障转移所需的时间就越长（因为越多的从实例同步新主实例，新主实例的负载压力越大，对外提供的服务能力就越弱） sentinel parallel-syncs mymaster 1 启动哨兵然后就是通过以下命令，启动哨兵：
/developer/redis-5.0.3/src/redis-sentinel /developer/redis/conf/sentinel.conf启动后，光从控制台的回馈是看不到任何东西的。
校验需要通过以下命令进行校验：
/developer/redis-5.0.3/src/redis-cli -p 26380 info sentinel如果看到以下页面，表示哨兵正常启动：
其实，还有一个验证方式，那就是查看哨兵配置（因为哨兵正常启动后，会将持久化信息，保存在配置中）。
详见下图：
从图中可以看到，不仅新增了两个从服务器的信息（哨兵通过info命令，与master交互获得），还改动了原来的几处配置（生成myid，替代ip:port等）。
哨兵机制的自动主从切换正如前面提到的，哨兵机制可以自动进行主从切换。
接下来会阐述一下哨兵机制进行主从切换的内在，不感兴趣的朋友可以直接跳过。
就拿上面的服务器状态，进行尝试，直接关闭Redis主实例。
原Redis主实例其中最引人瞩目的，自然是原Redis主实例的变化，详见下图：
可以看出，在原Redis主实例刚启动时，它还是独立的Redis单机实例。
但是在稍等一会儿（如十秒）后，原Redis主实例就会加入原来的集群中，成为原来集群的一个slave。
新Redis主实例再就是新Redis主实例的变化：