如未做特殊说明,本文均为原创,转载请注明出处。
前言
哨兵机制的使用场景。
现在很多时候我们的服务需要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的服务
浏览器访问(开启Nginx 反响代理并且使用轮询机制实现负载均衡)。
这个时候将8080
主节点关掉,
这里可以清楚明白地看出zookeeper 实现了类似于Redis中的哨兵模式。
加油!