zookeeper客户端（zookeeper客户端工具）

本篇文章给大家谈谈zookeeper客户端，以及zookeeper客户端工具对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、Zookeerper相关
• 2、如何获取zookeeper的客户端信息
• 3、为什么dubbo使用ZkClient作为zookeeper的客户端
• 4、Zookeeper客户端Curator使用详解

Zookeerper相关

Zookeeper是一种分布式协调服务。所谓分布式协调服务就是在分布式系统中共享配置、协调锁资源，提供命名服务。

Zookeeper的数据模型和数据结构当中的树类似，很像文件系统的目录。Zookeeper的数据存储也是基于节点，这种节点叫做Znode。Znode的引用方式是路径引用，类似于文件路径：/动物/人

常见的API：

create 创建节点

delete 删除节点

exists 判断节点是否存在

getData 获取一个节点的数据

getChildren 获取节点下的所有节点

Zookeeper客户端在请求读操作的时候，可以选择是否设置Watch。Watch理解成是注册在特定Znode上的触发器。当这个Znode发生改变，即调用了create、delete、setData方法时，会触发Znode上注册的对应事件，请求Watch的客户端会接收到异步通知。

具体交互过程：

1、客户端调用getData方法，watch参数是true。服务端接到请求，返回节点数据。并且在对应的哈希表里插入被Watch的Znode路径，以及Watcher数组。

2、当被Watch的Znode已删除，服务端会查找哈希表，根据key找到该Znode对应的所有Watcher，异步通知客户端，并且删除哈希表中对应的Key-Value。

为了防止单机故障，Zookeeper可以维护一个集群。Zookeeper Service集群时一主多从结构。

更新数据时，先更新到主节点（节点指服务器，而不是Znode），再同步到从节点。

读取数据时，直接读取任意从节点。

为保证主从节点的数据一致性，Zookeeper采用了ZAB协议，这种协议非常类似于一致性算法Paxos和Raft。

ZAB即Zookeeper Atomic Broadcast，有效解决了Zookeeper集群崩溃恢复以及主从同步数据的问题。

Zab协议既不是强一致性，也不是弱一致性，而是处于两者之间的单调一致性。它依靠敏首事务ID和版本号，保证了数据的更新和读取是有序的。

ZAB协议所的三种节点状态：

1）Looking：选举状态

2）Following：Follower节点（从节点）所处的状态

3）Leading：Leader节点（主节点）所处状态

三种算法：leaderElection/AuthFastLeaderElection/FastLeaderElection

1）Leader election

3）Discovery

4）Synchronization

Zookeeper常规情况下更新数据的时候，由Leader广播到所有Follower。其过程如下：

1）客户端发出写入数据请求给任意Follower

2）Follower把写入数据请求转发给Leader

3）Leader采用二阶段族枝提交方式，先发送Propose广播给Follower。

4）Follower接到Propose消息，写入日志成功后，返回ACK消息给Leader

5）Leader接到半数以上ACK消息，返回成功给客户端，兆拿敏并且广播Commit请求给Follower。

原文链接：

[img]

如何获取zookeeper的客户端信息

如何使用

Zookeeper 作为一个分布式的服务框架，主要用来解决分布式集群中应用系统的一致性问题，它能提供基于类似于文件系统的目录节点树方式的数据存储，但是 Zookeeper 并不是用来专门存储数据的，它的作用主要是用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理，后面将会详细介绍 Zookeeper 能够解决的一些典型问题，这里先介绍一下，Zookeeper 的操作接口和简单使用示例。

常用接口列表

客户端要连接 Zookeeper 服务器可以通过创建 org.apache.zookeeper. ZooKeeper 的一个实例对象，然后调用这个类提供的接口来和服务器交互。

前面说了 ZooKeeper 主要是用来维护和监控一个目录节点树中存储的数据的销让状态，所有我们能够操作 ZooKeeper 的也和操作目录节点树大体一样，如创建一个目录节点，给某个掘册目录节点设亏散局置数据，获取某个目录节点的所有子目录节点，给某个目录节点设置权限和监控这个目录节点的状态变化。

为什么dubbo使用ZkClient作为zookeeper的客户端

本笑历文内容并非原创，使用资料均来自互联网雀升汪。 dubbo使用了zkClient而不是使用zookeeper本身顷仔的客户端与zookeeper进行交互，为什么呢？ 先看看zookeeper本身自带的客户端的问题。 1 ） ZooKeeper的Watcher是一次性的，用过了需要再注册； 2 ） sessi

Zookeeper客户端Curator使用详解

[TOC]

维护多个博客比较麻烦，和博客园放弃维护，后续在个人博客持续更新：

Curator是Netflix公司开源的一套zookeeper客户端框架，解决了很多Zookeeper客户端非常底层的细节开发工作，包括连接重连、反复注册Watcher和NodeExistsException异常等等。Patrixck Hunt（Zookeeper）以一句“Guava is to Java that Curator to Zookeeper”给Curator予高度评价。

引子和趣闻：

Zookeeper名字的由来是比较有趣的，下面的片段摘抄自《从PAXOS到ZOOKEEPER分布式一致性原理与实践》一书：

Zookeeper最早起源于雅虎的研究院的一个研究小组。在当时，研究人员发现，在雅虎内部很多大型的系统需要依赖一个类似的系统进行分布式协调，但是这些系统往往存在分布式单点问题。所以雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架。在立项初期，考虑到很多项目都是用动物的名字来命名的(例如著名的Pig项目)，雅虎的工程师希望给这个项目也取一个动物的名字。时任研究院的首席科学家Raghu Ramakrishnan开玩笑说：再这样下去，我们这儿就变成动物园了。此话一出，大家纷纷表示就叫动物园管理员吧——因为各个以动物命名的分布式组件放在一起，雅虎的整个分布式系统看上去就像一个大型的动物园了，而Zookeeper正好用来进行分布式环境的协调——于是，Zookeeper的名字由此诞生了。

Curator无疑是Zookeeper客户端中的瑞士军刀，它译作"馆长"或者''管纯世理者''，不知道是不是开发小组有意而为之，笔者猜测有可能这样命名的原因是说明Curator就是Zookeeper的馆长(脑洞有点大：Curator就是动物园的园长)。

Curator包含了几个包：

curator-framework： 对zookeeper的底层api的一些封装

curator-client： 提供模皮一些客户端的操作，例如重试策略等

curator-recipes： 封装了一些高级特性，如：Cache事件监听、选举、分布式锁、分布式计数器、分布式Barrier等

Maven依赖(使用curator的版本：2.12.0，对应Zookeeper的版本为：3.4.x， 如果跨版本会有兼容性问题，很有可能导致节点操作失败 )：

一个例子如下：

newClient静态工厂方法包含四个主要参数：

核心参数变为流式设置，一个列子如下：

为了实现不同的Zookeeper业务之间的隔离，需要为每个业务分配一个独立的命名空间（ NameSpace ），即指定一个Zookeeper的根路径（官方术语： 为Zookeeper添加“Chroot”特性 ）。例如（下面的例子）当客户端指定了独立命名空间为“/base”，那么该客户端对Zookeeper上的数据节点的操作都是基于该目录进行的。通过设置Chroot可以将客户端应用与Zookeeper服务端的一课子树相对应，在多个应用共用一个Zookeeper集做码肢群的场景下，这对于实现不同应用之间的相互隔离十分有意义。

当创建会话成功，得到client的实例然后可以直接调用其start( )方法：

Zookeeper的节点创建模式：

**创建一个节点，初始内容为空 **

注意：如果没有设置节点属性，节点创建模式默认为持久化节点，内容默认为空

创建一个节点，附带初始化内容

创建一个节点，指定创建模式（临时节点），内容为空

创建一个节点，指定创建模式（临时节点），附带初始化内容

创建一个节点，指定创建模式（临时节点），附带初始化内容，并且自动递归创建父节点

这个creatingParentContainersIfNeeded()接口非常有用，因为一般情况开发人员在创建一个子节点必须判断它的父节点是否存在，如果不存在直接创建会抛出NoNodeException，使用creatingParentContainersIfNeeded()之后Curator能够自动递归创建所有所需的父节点。

删除一个节点

注意，此方法只能删除 叶子节点 ，否则会抛出异常。

删除一个节点，并且递归删除其所有的子节点

删除一个节点，强制指定版本进行删除

删除一个节点，强制保证删除

guaranteed()接口是一个保障措施，只要客户端会话有效，那么Curator会在后台持续进行删除操作，直到删除节点成功。

注意： 上面的多个流式接口是可以自由组合的，例如：

读取一个节点的数据内容

注意，此方法返的返回值是byte[ ];

读取一个节点的数据内容，同时获取到该节点的stat

更新一个节点的数据内容

注意：该接口会返回一个Stat实例

更新一个节点的数据内容，强制指定版本进行更新

注意：该方法返回一个Stat实例，用于检查ZNode是否存在的操作. 可以调用额外的方法(监控或者后台处理)并在最后调用forPath( )指定要操作的ZNode

注意：该方法的返回值为ListString,获得ZNode的子节点Path列表。 可以调用额外的方法(监控、后台处理或者获取状态watch, background or get stat) 并在最后调用forPath()指定要操作的父ZNode

CuratorFramework的实例包含inTransaction( )接口方法，调用此方法开启一个ZooKeeper事务. 可以复合create, setData, check, and/or delete 等操作然后调用commit()作为一个原子操作提交。一个例子如下：

上面提到的创建、删除、更新、读取等方法都是同步的，Curator提供异步接口，引入了 BackgroundCallback 接口用于处理异步接口调用之后服务端返回的结果信息。 BackgroundCallback 接口中一个重要的回调值为CuratorEvent，里面包含事件类型、响应吗和节点的详细信息。

CuratorEventType

响应码(#getResultCode())

一个异步创建节点的例子如下：

注意：如果#inBackground()方法不指定executor，那么会默认使用Curator的EventThread去进行异步处理。

提醒：首先你必须添加curator-recipes依赖，下文仅仅对recipes一些特性的使用进行解释和举例，不打算进行源码级别的探讨

重要提醒：强烈推荐使用ConnectionStateListener监控连接的状态，当连接状态为LOST，curator-recipes下的所有Api将会失效或者过期，尽管后面所有的例子都没有使用到ConnectionStateListener。

Zookeeper原生支持通过注册Watcher来进行事件监听，但是开发者需要反复注册(Watcher只能单次注册单次使用)。Cache是Curator中对事件监听的包装，可以看作是对事件监听的本地缓存视图，能够自动为开发者处理反复注册监听。Curator提供了三种Watcher(Cache)来监听结点的变化。

Path Cache用来监控一个ZNode的子节点. 当一个子节点增加， 更新，删除时， Path Cache会改变它的状态， 会包含最新的子节点， 子节点的数据和状态，而状态的更变将通过PathChildrenCacheListener通知。

实际使用时会涉及到四个类：

通过下面的构造函数创建Path Cache:

想使用cache，必须调用它的 start 方法，使用完后调用 close 方法。 可以设置StartMode来实现启动的模式

......to be continue

关于zookeeper客户端和zookeeper客户端工具的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。