Zookeeper 作为一个分布式的服务框架,主要用来解决分布式集群中应用系统的一致性问题,它能提供基于类似于文件系统的目录节点树方式的数据存储,但是 Zookeeper 并不是用来专门存储数据的,它的作用主要是用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化,从而可以达到基于数据的集群管理,后面将会详细介绍 Zookeeper 能够解决的一些典型问题,这里先介绍一下,Zookeeper 的操作接口和简单使用示例。
常用接口列表
客户端要连接 Zookeeper 服务器可以通过创建 org.apache.zookeeper. ZooKeeper 的一个实例对象,然后调用这个类提供的接口来和服务器交互。
前面说了 ZooKeeper 主要是用来维护和监控一个目录节点树中存储的数据的状态,所有我们能够操作 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/testchildpath1","1".getbytes(), ids.open_acl_unsafe,createmode.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", "testrootdata".getbytes(),ids.open_acl_unsafe, createmode.persistent);
// 创建一个子目录节点
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选举。
Hadoop|
Apache Pig|
Apache Kafka|
Apache Storm|
Impala|
Zookeeper|
SAS|
TensorFlow|
人工智能基础|
Apache Kylin|
Openstack|
Flink|
MapReduce|
大数据|
云计算|
用户登录
还没有账号?立即注册
用户注册
投稿取消
文章分类: |
|
还能输入300字
上传中....