1.zookeeper都有哪些功能?
2.zookeeper服务器端和客服端怎样保持连接的？
： Zookeeper分为2个部分：服务器端和客户端，客户端只连接到整个ZooKeeper服务的某个服务器上。客户端使用并维护一个TCP连接，通过这个连接发送请求、接受响应、获取观察的事件以及发送心跳。如果这个TCP连接中断，客户端将尝试连接到另外的ZooKeeper服务器。客户端第一次连接到ZooKeeper服务时，接受这个连接的 ZooKeeper服务器会为这个客户端建立一个会话。当这个客户端连接到另外的服务器时，这个会话会被新的服务器重新建立。
3. 启动Zookeeper服务器集群环境后，多个Zookeeper服务器在工作前会选举出一个Leader，在接下来的工作中这个被选举出来的Leader死了，而剩下的Zookeeper服务器会知道这个Leader死掉了，在活着的Zookeeper集群中会继续选出一个Leader，选举出leader的目的是为了可以在分布式的环境中保证数据的一致性。
4.另外，ZooKeeper 支持watch(观察)的概念。客户端可以在每个znode结点上设置一个观察。如果被观察服务端的znode结点有变更，那么watch就会被触发，这个watch所属的客户端将接收到一个通知包被告知结点已经发生变化。若客户端和所连接的ZooKeeper服务器断开连接时，其他客户端也会收到一个通知，也就说一个Zookeeper服务器端可以对于多个客户端，当然也可以多个Zookeeper服务器端可以对于多个客户端，如图所示：
你还可以通过命令查看出，当前那个Zookeeper服务端的节点是Leader，哪个是Follower
5.那么zookeeper就可以理清思路了。
1）：zk客户端注册监听的是zk服务端的节点，即zk客户端监听的是znode节点，不是zk服务端。
2）每个znode节点存储的是小型数据，每个znode节点并有一个路径名字，类似aaa/bb/cc，文件系统路径名字，树形结构。
3）zk客户端监听的就是znode节点名字，
4）当znode名字对应的数据更改后，zk客户端注册监听znode那个，就会收到通知
5）每个znode节点对应的是数据
6)当有事件导致node数据，例如：变更，增加，删除时，Zookeeper就会调用 triggerWatch方法，判断当前的path来是否有对应的监听者(watcher),如果有watcher，会触发其process方法，执行process方法中的业务逻辑，如图所示：
7)(1) 每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识，如/SERVER2节点的标识就为/APP3/SERVER2(2) Znode可以有子znode，并且znode里可以存数据，但是EPHEMERAL类型的节点不能有子节点(3) Znode中的数据可以有多个版本，比如某一个路径下存有多个数据版本，那么查询这个路径下的数据就需要带上版本。(4) znode 可以是临时节点，一旦创建这个 znode 的客户端与服务器失去联系，这个 znode 也将自动删除，Zookeeper 的客户端和服务器通信采用长连接方式，每个客户端和 服务器通过心跳来保持连接，这个连接状态称为 session，如果 znode 是临时节点，这个 session 失效，znode 也就删除了(5) znode 的目录名可以自动编号，如 App1 已经存在，再创建的话，将会自动命名为 App2 (6) znode 可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个功能是zookeeper对于应用最重要的特性，通过这个特性可以实现的功能包括配置的集中管理，集群管理，分布式锁等等。
它提供了一项基本服务：分布式锁服务。由于ZooKeeper的开源特性，后来我们的开发者在分布式锁的基础上，摸索了出了其他的使用方法：配置维护、组服务、分布式消息队列、分布式通知/协调等。
6.ZK的master是怎样选举出来的？
：所有集群中的服务器通过Chubby最终选出一个Master Server ，最后这个Master Server来协调工作。简单来说其原理就是：在一个分布式系统中，有一组服务器在运行同样的程序，它们需要确定一个Value，以那个服务器提供的信息为主/为准，当这个服务器经过n/2+1的方式被选出来后，所有的机器上的Process都会被通知到这个服务器就是主服务器 Master服务器，大家以他提供的信息为准。很想知道Google Chubby中的奥妙，可惜人家Google不开源，自家用。
7.通过Java代码使用zookeeper Zookeeper的使用主要是通过创建其jar包下的Zookeeper实例，并且调用其接口方法进行的，主要的操作就是对znode的增删改操作，监听znode的变化以及处理。
以下为主要的API使用和解释
//创建一个Zookeeper实例，第一个参数为目标服务器地址和端口，第二个参数为Session超时时间，第三个为节点变化时的回调方法 ZooKeeper zk = new ZooKeeper("127.0.0.1:2181", 500000,new Watcher() { // 监控所有被触发的事件 public void process(WatchedEvent event) { //dosomething } }); //创建一个节点root，数据是mydata,不进行ACL权限控制，节点为永久性的(即客户端shutdown了也不会消失) zk.create("/root", "mydata".getBytes(),Ids.OPEN_ACL_UNSAFE, CreateMode.PERSISTENT); //在root下面创建一个childone znode,数据为childone,不进行ACL权限控制，节点为永久性的 zk.create("/root/childone","childone".getBytes(), Ids.OPEN_ACL_UNSAFE,CreateMode.PERSISTENT); //取得/root节点下的子节点名称,返回List<String> zk.getChildren("/root",true); //取得/root/childone节点下的数据,返回byte[] zk.getData("/root/childone", true, null); //修改节点/root/childone下的数据，第三个参数为版本，如果是-1，那会无视被修改的数据版本，直接改掉 zk.setData("/root/childone","childonemodify".getBytes(), -1); //删除/root/childone这个节点，第二个参数为版本，－1的话直接删除，无视版本 zk.delete("/root/childone", -1); //关闭session zk.close(); Zookeeper的主流应用场景实现思路（除去官方示例） (1) 配置管理集中式的配置管理在应用集群中是非常常见的，一般商业公司内部都会实现一套集中的配置管理中心，应对不同的应用集群对于共享各自配置的需求，并且在配置变更时能够通知到集群中的每一个机器。 Zookeeper很容易实现这种集中式的配置管理，比如将APP1的所有配置配置到/APP1 znode下，APP1所有机器一启动就对/APP1这个节点进行监控(zk.exist("/APP1",true)),并且实现回调方法Watcher，那么在zookeeper上/APP1 znode节点下数据发生变化的时候，每个机器都会收到通知，Watcher方法将会被执行，那么应用再取下数据即可(zk.getData("/APP1",false,null));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选举。总结
我们初步使用了一下zookeeper并且尝试着描述了几种应用场景的具体实现思路，接下来的文章，我们会尝试着去探究一下zookeeper的高可用性与leaderElection算法。
参考：http://www.ibm.com/developerworks/cn/opensource/os-cn-zookeeper/
http://hadoop.apache.org/zookeeper/docs/current/
http://rdc.taobao.com/team/jm/archives/448
本文部分转自：http://blog.csdn.net/baidu_23564015/article/details/51252305 感谢作者
zookeeper是基于内存同步数据的，所以集群内的节点其内存中的数据结构是完全相同的，因此效率非常高。
ZooKeeper具备的几个特点决定了它能够用在大型的、分布式的系统当中:
顺序一致性
从同一个客户端发起的事务请求，最终将会严格按照其发起顺序被应用到zookeeper中
原子性
所有事物请求的处理结果在整个集群中所有机器上的应用情况是一致的，即，要么整个集群中所有机器都成功应用了某一事务，要么都没有应用，一定不会出现集群中部分机器应用了改事务，另外一部分没有应用的情况。
单一视图
无论客户端连接的是哪个zookeeper服务器，其看到的服务端数据模型都是一致的。
可靠性
一旦服务端成功的应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会一直保留下来，除非有另一个事务又对其进行了改变。
实时性
zookeeper并不是一种强一致性，只能保证顺序一致性和最终一致性，只能称为达到了伪实时性。
Znode 结构
ZooKeeper命名空间中的Znode，兼具文件和目录两种特点。既像文件一样维护着数据、元信息、ACL、时间戳等数据结构，又像目录一样可以作为路径标识的一部分。每个Znode由3部分组成 :
1、stat：此为状态信息, 描述该Znode的版本, 权限等信息
2、data：与该Znode关联的数据
3、children：该Znode下的子节点
ZooKeeper虽然可以关联一些数据，但并没有被设计为常规的数据库或者大数据存储，相反的是，它用来管理调度数据，比如分布式应用中的配置文件信息、状态信息、汇集位置等等。这些数据的共同特性就是它们都是很小的数据，通常以KB为大小单位。ZooKeeper的服务器和客户端都被设计为严格检查并限制每个Znode的数据大小至多1M，但常规使用中应该远小于此值。
三、节点类型
ZooKeeper中的节点有两种，分别为临时节点和永久节点。节点的类型在创建时即被确定，并且不能改变。
临时节点：该节点的生命周期依赖于创建它们的会话。一旦会话(Session)结束，临时节点将被自动删除，当然可以也可以手动删除。虽然每个临时的Znode都会绑定到一个客户端会话，但他们对所有的客户端还是可见的。另外，ZooKeeper的临时节点不允许拥有子节点。
永久节点：该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。
顺序节点
当创建Znode的时候，用户可以请求在ZooKeeper的路径结尾添加一个递增的计数。这个计数对于此节点的父节点来说是唯一的，它的格式为"d"(10位数字，没有数值的数位用0补充，例如"0000000001")。当计数值大于232-1时，计数器将溢出。
监视器
客户端可以在节点上设置watch，我们称之为监视器。当节点状态发生改变时(Znode的增、删、改)将会触发watch所对应的操作。当watch被触发时，ZooKeeper将会向客户端发送且仅发送一条通知，因为watch只能被触发一次，这样可以减少网络流量。
ZooKeeper有多种记录时间的形式，其中包含以下几个主要属性：
(1) Zxid
致使ZooKeeper节点状态改变的每一个操作都将使节点接收到一个Zxid格式的时间戳，并且这个时间戳全局有序。也就是说，也就是说，每个对节点的改变都将产生一个唯一的Zxid。如果Zxid1的值小于Zxid2的值，那么Zxid1所对应的事件发生在Zxid2所对应的事件之前。实际上，ZooKeeper的每个节点维护者三个Zxid值，为别为：cZxid、mZxid、pZxid。
1、cZxid： 是节点的创建时间所对应的Zxid格式时间戳。
2、mZxid：是节点的修改时间所对应的Zxid格式时间戳。
实现中Zxid是一个64为的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个 新的epoch。低32位是个递增计数。
(2) 版本号
对节点的每一个操作都将致使这个节点的版本号增加。每个节点维护着三个版本号，他们分别为：
1、version：节点数据版本号
2、cversion：子节点版本号
3、aversion：节点所拥有的ACL版本号
ZooKeeper节点属性：
四、ZooKeeper 安装配置
ZooKeeper的工作模式有三种:单机模式、集群模式、伪集群模式。
单机模式：Zookeeper只运行在一台服务器上，适合测试环境；
伪集群模式：就是在一台物理机上运行多个Zookeeper 实例；
集群模式：Zookeeper运行于一个至少有三个节点以上集群中，适合生产环境;
Zookeeper通过复制来实现高可用性，只要集群中半数以上的节点处于可用状态，它就能够保证服务继续。为什么一定要超过半数呢？这跟Zookeeper的复制策略有关：zookeeper确保对znode 树的每一个修改都会被复制到集群中超过半数的节点上。
服务器角色有两种:
1、leader -主节点
2、follower -从节点
在一个集群中通常只有一个leader和多个follower，当leader下线时，follower能根据选举策略，选举一个新的leader保证集群的正常工作。
下面我们来构建一个单机模式的ZooKeeper节点:
可以去Apache的镜像站点下载zookeeper: http://www.apache.org/dyn/closer.cgi/zookeeper/
安装ZooKeeper之前首先需要安装JDK，在oracle官网可以下载到。（建议下载rpm包安装）
1、解压zookeeper
1 2 tar xf zookeeper-3.4.9. tar .gz cd zookeeper-3.4.92、创建配置文件
1 2 3 4 5 # conf/zoo.cfg tickTime=2000 dataDir= /tmp/zookeeper clientPort=21813、启动服务
1 bin /zkServer .sh start
ZooKeeper伪集群模式
ZooKeeper提供了伪集群模式，也就是可以在同一台机器上启动多个zookeeper服务，当手头机器不足时，又需要做实验，提供了很大的便利。
注: 在同一台机器上部署3个zookeeper server时，需要为每个server创建独立的配置文件，并且保证每个配置文件中的端口不能冲突，除了clientPort不同之外，另外，还要在dataDir所对应的目录中创建myid文件来指定对应的zookeeper server 实例。
需要注意的几个配置项:
clientPort端口：如果在1台机器上部署多个server，那么每台机器都要不同的 clientPort，比如 server1是2181,server2是2182，server3是2183
dataDir和dataLogDir：dataDir和dataLogDir也需要区分下，将数据文件和日志文件分开存放，同时每个server的这两变量所对应的路径都是不同的
server.X和myid： server.X 这个数字就是对应，data/myid中的数字。在3个server的myid文件中分别写入了0，1，2，那么每个server中的zoo.cfg都配 server.0 server.2,server.3就行了。因为在同一台机器上，后面连着的2个端口，3个server都不要一样，否则端口冲突
启动命令
1 2 3 4 # 这时使用单机模式的启动命令是不行的，需要在指令后面跟上不同实例的配置文件名称。如下: bin /zkServer .sh start zoo1.cfg bin /zkServer .sh start zoo2.cfg bin /zkServer .sh start zoo3.cfg
五、集群实战 — 构建一个3节点的 ZooKeeper 集群
实验环境:
服务器IPmyid192.168.1.2111192.168.1.2212192.168.1.2313注:
(1) zk服务器集群规模不得小于3个节点
(2) 要求各服务器之间系统时间要保持一致。
为了实现高可用的ZooKeeper服务，应该把zk部署在一个集群中，每台机器只跑一个zk实例。配置方式和前面差不多，只是每台机器上的配置文件 conf/zoo.cfg 完全相同。
创建myid
1 2 3 4 5 6 7 8 9 10 # 为每台机器创建myid文件 # 192.168.1.21 echo 11 > /u01/zookeeper/zookeeper-3 .4.9 /data/myid # 192.168.1.22 echo 12 > /u01/zookeeper/zookeeper-3 .4.9 /data/myid # 192.168.1.23 echo 13 > /u01/zookeeper/zookeeper-3 .4.9 /data/myid
创建配置文件
可以复制 zoo_sample.cfg 到 zoo.cfg 以下为配置文件的参数设置:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 # The number of milliseconds of each tick tickTime=2000 # The number of ticks that the initial # synchronization phase can take initLimit=10 # The number of ticks that can pass between # sending a request and getting an acknowledgement syncLimit=5 # the directory where the snapshot is stored. # do not use /tmp for storage, /tmp here is just # example sakes. dataDir= /u01/zookeeper/zookeeper-3 .4.9 /data # the port at which the clients will connect clientPort=2181 # the maximum number of client connections. # increase this if you need to handle more clients #maxClientCnxns=60 server.11=192.168.1.21:2888:3888 server.12=192.168.1.22:2888:3888 server.13=192.168.1.23:2888:3888
改好配置文件后，同步到集群内的所有节点。
常用配置参数解析:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 dataLogdDir= /path1 # 指定事务日志的存储路径，可以和dataDir在不同设备，这意味着可以使用一个日志的专用磁盘，避免日志IO和快照竞争。 dataDir= /path2 # 运行数据的存放路径 tickTime=2000 # 这个时间是作为Zookeeper服务器之间或客户端与服务器之间维持心跳的时间间隔，每隔tickTime时间就会发送一个心跳；最小 的session过期时间为2倍tickTime maxClientCnxns=0 # 最大的并发连接数限制，设置为0或者不设置该参数，表示不进行连接数的限制。 minSessionTimeout # 最小的会话超时时间，默认值 minSession=2*tickTime maxSessionTimeout # 最大的会话超时时间，默认值 maxSession=20*tickTime initLimit=10 # 此配置表示，允许follower(相对于Leaderer言的“客户端”)连接并同步到Leader的初始化连接时间，以tickTime为单位。当初始化连接时间超过该值，则表示连接失败。 syncLimit=5 # 此配置项表示Leader与Follower之间发送消息时，请求和应答时间长度。如果follower在设置时间内不能与leader通信，那么此follower将会被丢弃。 # 集群模式最关键的配置参数 server.11=192.168.1.21:2888:3888 # server.myid=ip:leader_port:inner_port # myid 为服务器编号，用于标识服务器，这个值必须和dataDir目录下myid文件中的值保证一致 # ip 为当前服务器IP， # leader_port Leader的端口 # inner_port zk服务器之间内部通信端口 # 同一个集群内的服务器，需要把该集群内的服务器列表信息都写在配置文件中。
启动服务 & 查看节点的角色分配情况
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 # 192.168.1.21 bin /zkServer .sh start bin /zkServer .sh status # ZooKeeper JMX enabled by default # Using config: /u01/zookeeper/zookeeper-3.4.9/bin/../conf/zoo.cfg # Mode: leader # 192.168.1.22 bin /zkServer .sh start bin /zkServer .sh status # ZooKeeper JMX enabled by default # Using config: /u01/zookeeper/zookeeper-3.4.9/bin/../conf/zoo.cfg # Mode: follower # 192.168.1.23 bin /zkServer .sh start bin /zkServer .sh status # ZooKeeper JMX enabled by default # Using config: /u01/zookeeper/zookeeper-3.4.9/bin/../conf/zoo.cfg # Mode: follower
由此可见，集群已经正常运行;
六、ZooKeeper的四字命令
客户端可以通过nc或telnet连接ZooKeeper Server提交指令
简单用例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 # 检查服务器状态是否正常 echo ruok | nc localhost 2181 imok # 输出服务器配置信息 echo conf | nc localhost 2181 clientPort=2181 dataDir= /u01/zookeeper/zookeeper-3 .4.9 /data/version-2 dataLogDir= /u01/zookeeper/zookeeper-3 .4.9 /data/version-2 tickTime=2000 maxClientCnxns=60 minSessionTimeout=4000 maxSessionTimeout=40000 serverId=11 initLimit=10 syncLimit=5 electionAlg=3 electionPort=3888 quorumPort=2888 peerType=0 # 输出服务器状态信息 echo stat | nc localhost 2181 Zookeeper version: 3.4.9-1757313, built on 08 /23/2016 06:50 GMT Clients: /127 .0.0.1:60822[0](queued=0,recved=1,sent=0) Latency min /avg/max : 0 /1/1591 Received: 200338 Sent: 200389 Connections: 1 Outstanding: 0 Zxid: 0x200498db5 Mode: follower Node count: 166
七、ZooKeeper Client 简单操作
9个基本操作指令:
简单用例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 # 连接 ZooKeeper 服务器 bin /zkCli .sh -server localhost:2181 # 查看根下有哪些节点 [zk: localhost:2181(CONNECTED) 1] ls / [controller_epoch, controller, brokers, zookeeper, admin, isr_change_notification, consumers, config] # 查看 brokers 下有哪些子节点 [zk: localhost:2181(CONNECTED) 4] ls /brokers [ids, topics, seqid] # 在根下创建一个 "tuchao" 节点，并设置数据为 "hello zookeeper" [zk: localhost:2181(CONNECTED) 5] create /tuchao "hello zookeeper" # 查看是否创建成功 [zk: localhost:2181(CONNECTED) 6] ls / [controller_epoch, controller, brokers, zookeeper, tuchao, admin, isr_change_notification, consumers, config] # 查看 /tuchao 中的数据 [zk: localhost:2181(CONNECTED) 7] get /tuchao hello zookeeper cZxid = 0x20049ab24 ctime = Sun Oct 09 15:45:02 CST 2016 mZxid = 0x20049ab24 mtime = Sun Oct 09 15:45:02 CST 2016 pZxid = 0x20049ab24 cversion = 0 dataVersion = 0 aclVersion = 0 ephemeralOwner = 0x0 dataLength = 15 numChildren = 0 # 可以看到刚刚设置的数据。 # 修改 /tuchao 中的数据为 "Happy birthday" [zk: localhost:2181(CONNECTED) 8] set /tuchao "Happy birthday" cZxid = 0x20049ab24 ctime = Sun Oct 09 15:45:02 CST 2016 mZxid = 0x20049b2cc mtime = Sun Oct 09 15:51:17 CST 2016 pZxid = 0x20049ab24 cversion = 0 dataVersion = 1 # 可以发现，当数据变更时，数据版本号增加了。 aclVersion = 0 ephemeralOwner = 0x0 dataLength = 14 numChildren = 0 # 再查看一次 /tuchao 中的数据 [zk: localhost:2181(CONNECTED) 9] get /tuchao Happy birthday cZxid = 0x20049ab24 ctime = Sun Oct 09 15:45:02 CST 2016 mZxid = 0x20049b2cc mtime = Sun Oct 09 15:51:17 CST 2016 pZxid = 0x20049ab24 cversion = 0 dataVersion = 1 aclVersion = 0 ephemeralOwner = 0x0 dataLength = 14 numChildren = 0 # 给 /tuchao 创建一个子节点 /tuchao/abc1 [zk: localhost:2181(CONNECTED) 10] create /tuchao/abc1 "abc1 node" Created /tuchao/abc1 [zk: localhost:2181(CONNECTED) 11] ls /tuchao [abc1] # 删除节点 /tuchao/abc1 [zk: localhost:2181(CONNECTED) 0] delete /tuchao/abc1 [zk: localhost:2181(CONNECTED) 1] ls /tuchao [] # 查看命令帮助，输入 h [zk: localhost:2181(CONNECTED) 2] h ZooKeeper -server host:port cmd args stat path [ watch ] set path data [version] ls path [ watch ] delquota [-n|-b] path ls2 path [ watch ] setAcl path acl setquota -n|-b val path history redo cmdno printwatches on|off delete path [version] sync path listquota path rmr path get path [ watch ] create [-s] [-e] path data acl addauth scheme auth quit getAcl path close connect host:port
本文部分转自http://tchuairen.blog.51cto.com/3848118/1859494 感谢作者
转载于:https://www.cnblogs.com/panxuejun/p/7233112.html
相关资源：DirectX修复工具V4.0增强版