如未做特殊说明，本文均为原创，转载请注明出处。
前言
哨兵机制的使用场景。
现在很多时候我们的服务需要7*24小时工作，假如一台机器挂了，我们希望能有其它机器顶替它继续工作。此类问题现在多采用master-salve模式，也就是常说的主从模式，正常情况下主机提供服务，备机负责监听主机状态，当主机异常时，可以自动切换到备机继续提供服务(这里有点儿类似于数据库主库跟备库，备机正常情况下只监听，不工作)，这个切换过程中选出下一个主机的过程就是master选举。
对于以上提到的场景，传统的解决方式是采用一个备用节点，这个备用节点定期给当前主节点发送ping包，主节点收到ping包后会向备用节点发送应答ack，当备用节点收到应答，就认为主节点还活着，让它继续提供服务，否则就认为主节点挂掉了，自己将开始行使主节点职责。
Redis中的哨兵机制实现主从复制。
哨兵机制
哨兵机制的目的：
为了主从选举策略，实现高可用。
zookeeper 是如何实现哨兵机制的呢？
为什么zookeeper可是实现哨兵机制？
在zookeeper的独特的树状结构中，并且同一层级下保证唯一性，并且拥有临时节点和watcher事件监听机制。
/**
* 使用zookeeper 的临时节点，和监听事件功能实现 哨兵机制
*
* @author by Assume
* @date 2019/3/30 21:14
*/
@Component
@Slf4j
public class electionZookeeper implements ApplicationRunner {
private static final String ADDR = "127.0.0.1:2181";
private ZkClient zkClient = new ZkClient(ADDR);
// 节点-- 争抢节点
private String path = "/election";
@Value("${server.port}")
private String serverPort;
@Override
public void run(ApplicationArguments args) throws Exception {
log.info("项目启动完成。。。");
// 创建临时节点
createEphemeral();
// 创建事件监听
zkClient.subscribeDataChanges(path, new IZkDataListener() {
@Override
public void handleDataChange(String dataPath, Object data) throws Exception {
}
@Override
public void handleDataDeleted(String dataPath) throws Exception {
// 主节点挂了，通知其它节点进行争抢（创建节点），重新选举
log.info("主节点挂了");
createEphemeral();
}
});
}
private void createEphemeral() {
try {
zkClient.createEphemeral(path, serverPort);
// 创建成功将标志改为true
ElectionMaster.ISSURVIVAL = true;
log.info("serverPort：{},选举成功....", serverPort);
} catch (Exception e) {
// 否则
ElectionMaster.ISSURVIVAL = false;
}
}
}
/**
* 定义一个单例 标记
*
* @author by Assume
* @date 2019/3/30 21:21
*/
@Component
public class ElectionMaster {
public static Boolean ISSURVIVAL = false;
}
上述两个类都交给spring管理，启动三个端口分别为8080、8081、8082的服务
8080选举成功
浏览器访问（开启Nginx 反响代理并且使用轮询机制实现负载均衡）。
第一次访问
其它两个从节点
这个时候将8080主节点关掉，
zookeeper监听到该事件
这里可以清楚明白地看出zookeeper 实现了类似于Redis中的哨兵模式。
加油！
