Zookeeper的主流应用场景实现思路(除去官方示例)
(1)配置管理
集中式的配置管理在应用集群中是非常常见的,一般商业公司内部都会实现一套集中的配置管理中心,应对不同的应用集群对于共享各自配置的需求,并且在配置变更时能够通知到集群中的每一个机器。
Zookeeper很容易实现这种集中式的配置管理,比如将APP1的所有配置配置到/APP1 znode下,APP1所有机器一启动就对/APP1这个节点进行监控(zk.exist("/APP1",true)),并且实现回调方法Watcher,那么在zookeeper上/APP1 znode节点下数据发生变化的时候,每个机器都会收到通知,Watcher方法将会被执行,那么应用再取下数据即可(zk.getData("/APP1",false,null));
以上这个例子只是简单的粗颗粒度配置监控,细颗粒度的数据可以进行分层级监控,这一切都是可以设计和控制的。
(2)集群管理
应用集群中,我们常常需要让每一个机器知道集群中(或依赖的其他某一个集群)哪些机器是活着的,并且在集群机器因为宕机,网络断链等原因能够不在人工介入的情况下迅速通知到每一个机器。
Zookeeper同样很容易实现这个功能,比如我在zookeeper服务器端有一个znode叫/APP1SERVERS,那么集群中每一个机器启动的时候都去这个节点下创建一个EPHEMERAL类型的节点,比如server1创建/APP1SERVERS/SERVER1(可以使用ip,保证不重复),server2创建/APP1SERVERS/SERVER2,然后SERVER1和SERVER2都watch /APP1SERVERS这个父节点,那么也就是这个父节点下数据或者子节点变化都会通知对该节点进行watch的客户端。因为EPHEMERAL类型节点有一个很重要的特性,就是客户端和服务器端连接断掉或者session过期就会使节点消失,那么在某一个机器挂掉或者断链的时候,其对应的节点就会消失,然后集群中所有对/APP1SERVERS进行watch的客户端都会收到通知,然后取得最新列表即可。
另外有一个应用场景就是集群选master,一旦master挂掉能够马上能从slave中选出一个master,实现步骤和前者一样,只是机器在启动的时候在APP1SERVERS创建的节点类型变为EPHEMERAL_SEQUENTIAL类型,这样每个节点会自动被编号,例如
zk.create("/testRootPath/testChildPath2","2".getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);
zk.create("/testRootPath/testChildPath3","3".getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);
// 创建一个子目录节点
zk.create("/testRootPath/testChildPath4","4".getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL_SEQUENTIAL);
System.out.println(zk.getChildren("/testRootPath", false));
打印结果:[testChildPath10000000000, testChildPath20000000001, testChildPath40000000003, testChildPath30000000002]
// 创建一个子目录节点
zk.create("/testRootPath/testChildPath1","1".getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL);
zk.create("/testRootPath/testChildPath2","2".getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL);
zk.create("/testRootPath/testChildPath3","3".getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL);
// 创建一个子目录节点
zk.create("/testRootPath/testChildPath4","4".getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.EPHEMERAL);
System.out.println(zk.getChildren("/testRootPath", false));
打印结果:[testChildPath2, testChildPath1, testChildPath4, testChildPath3]
我们默认规定编号最小的为master,所以当我们对/APP1SERVERS节点做监控的时候,得到服务器列表,只要所有集群机器逻辑认为最小编号节点为master,那么master就被选出,而这个master宕机的时候,相应的znode会消失,然后新的服务器列表就被推送到客户端,然后每个节点逻辑认为最小编号节点为master,这样就做到动态master选举。
总结
我们初步使用了一下zookeeper并且尝试着描述了几种应用场景的具体实现思路,接下来的文章,我们会尝试着去探究一下zookeeper的高可用性与leaderElection算法。
相关推荐
网上对zk的使用场景也有不少介绍,本文将结合作者身边的项目例子,系统的对zk 的使用场景进行归类介绍。 值得注意的是,zk并不 是生来就为这些场景设计,都是后来众多开发者根据框架的特性,摸索出来的典型使用方法...
Zookeeper使用场景及详解,优劣之分
ZooKeeper应用场景
08.zookeeper应用场景举例--服务器上下线动态感知--配置文件同步管理.mp4
1、master选举:mastersel 2、数据的发布和订阅:subscribe 3、负载均衡:balance 4、分布式锁:lock 5、分布式队列:queue 6、命名服务:nameservice 资料来自极客学院
配置维护大型分布式场景中,对相同配置的集群服务器集中进行配置管理,各服务器在zookeeper中注册watcher监听,发布者更新配置后,zookeeper向订
课程概要:分布式集群管理分布式注册中心分布式JOB分布式锁一、 分布式集群管理分布式集群管理的需求:主动查看线上服务节点查看服务节点资源使用情况服务离线通知服务
ZooKeeper 典型的应用场景详解
zookeeper经典应用场景
值得注意的是,ZK 并非天生就是为这些应用场景设计的,都是后来众多开发者根据其框架的特性,利用其提供的一系列 API 接口(戒者称为原语集),摸索出来的典型使用方法。因此,也非常欢迎读者分享你在 ZK 使用上的...
1、master选举:mastersel 2、数据的发布和订阅:subscribe 3、负载均衡:balance 4、分布式锁:lock 5、分布式队列:queue 6、命名服务:nameservice 演示代码下载(代码来自极客学院演示demo):
ZooKeeper 是一个高可用的分布式数据管理不系统协调框架。基于对 Paxos 算法的实现,使该框架...网上对 ZK 的应用场景也有丌少介绉,本文将结合作者身边的项目例子,系统地对 ZK 的应用场景迚行一个分门归类的介绉。
2. Zookeeper经典应用场景实战(一)
Zookeeper是一个高可用的分布式数据管理和协调框架,并且能够很好的...Zookeeper的应用场景主要有以下几种 1.数据发布/订阅 2.负载均衡 3.命名服务 4.分布式协调/通知 5.集群管理 6.Master选举 7.分布式锁 8.分布式队列
zookeeper 典型使用场景实践 归档.zip
zookeeper客户端原理代码操作应用场景。