redis主从集群中的哨兵机制
1 redis主从集群中的哨兵机制（哨兵通常是集群）
redis哨兵（Sentinel）机制，用来解决redis单节点部署中的故障恢复问题。实现redis集群的健康检测和自动恢复功能。
（1）监控：Sentinel会不断检查你的master和slave是否按预期工作。
（2）自动故障恢复：如果master节点故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主节点。但是此时RedisClient（java客户端）不知道主从节点的地址变化，所以RedisClient会直接找Sentinel，从而知道最新的主从节点地址。
（3）通知：Sentinel充当redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端。
1.1 服务状态监控
Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个redis实例发送ping命令（看是否有对应的pong回应）
（1）主观下线：（某台Sentinel个人认为这个redis实例下线了）：
如果某sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。
（2）客观下线：（真实下线了）
若超过指定数量（quorum ：可在配置文件中配置）的sentinel都认为该实例主观下线，则该实例客观下线，quorum值最好超过Sentinel实例数量的一半。
1.2 选举新的master规则（此时有2台redis的slave）
一旦发现master故障，sentinel需要在slave中选择一个作为新的master，选择依据如下：
（1）先会判断slave节点与master节点断开时间长短（说明丢失的数据越多），如果超过指定值（down-after-milliseconds*10： 可在配置文件中配置）则会排除该slave节点。
（2）然后判断slave节点的slave-priority值，越小优先级越高，如果是0则永不参与选举。（这个值都是1，相当于没有）
（3）如果slave-priority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高。
（4）最后是判断slave节点的运行id大小（redis自动生成的id），越小优先级越高。
1.3 实现故障转移
选中了其中一个slave为新的master后，故障的转移步骤如下：
（1）sentinel给选中slave节点发送slaveof no one命令，让该节点成为master节点。
（2）sentinel给所有其他的slave节点发送slaveof 新的master节点ip 端口号 命令，让这些slave成为master节点的从节点，开始从新的master上同步数据。
（3）最后故障的节点怎么办：sentinel会强制修改该节点的配置文件，加上slaveof 新master节点的ip 端口号，这样故障节点恢复后，会自动成为新master的slave节点。
2 搭建哨兵集群
在redis安装目录中，创建一个sentinel.conf文件
指定主节点
依次启动3个redis节点中的sentinel哨兵：
redis-sentinel redis1/sentinel.conf
redis-sentinel redis2/sentinel.conf
redis-sentinel redis3/sentinel.conf