新Redis主实例，会从原来的slave，晋级为master。这个晋级实例的选择并不是随机的，而是有着一定规则的，以后有机会再介绍。
其它Redis从实例
其它Redis从实例，将会改变集群中的master。
配置变化其实，更为直接的观察，可以查看配置。
其实，我刚开始了解哨兵时，我非常好奇一个现象。那就是原Redis主实例，在重新上线后，再次加入集群的流程是怎样的？其中的持久化信息（如IP等）是保存在哪里的？
经过一番思考后，我查看了Redis配置与哨兵配置，才发现这一切都在配置中有所体现：
Redis配置哨兵机制下，Redis配置的变化，有两个时间。一个是哨兵启动时，另一个是主从切换时。
红框标记的部分，表示该Redis实例，从172.26.40.224（master）处，进行复制。
如果是Redis主实例，那么其配置的红框部分则为：
# Generated by CONFIG REWRITE dir "/root" 哨兵配置
由于哨兵保留了整个集群的信息，所以它可以自由控制集群中各个实例节点的状态。
这也解释了原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.224 6379,2代表两个及以上哨兵认定为死亡，才认为是真的死亡，即客观下线。 sentinel monitor mymaster 172.26.40.224 6379 2 # 发送心跳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其实就是修改了 sentinel monitor mymaster 172.26.40.224 6379 2 ，
数字1改为2，是为了确保故障转移的客观性（详情了解主观下线与客观下线）。
IP地址的变换，是因为现在的master是172.26.40.224而已。
启动只需要通过以下命令：
/developer/redis-5.0.3/src/redis-sentinel /developer/redis/conf/sentinel.conf依次启动多个哨兵实例（甚至可以在一台服务器上启动，那就需要修改哨兵配置中的端口号）
校验启动后，通过以下命令验证各个哨兵实例：
/developer/redis-5.0.3/redis-cli -p 26380 info sentinel如果看到以下页面，则表示启动成功：
