标签：zookeeper zk ZooKeeper znode 数据 节点 客户端
zookeeper是什么？
分布式应用程序的分布式协调服务，它通过提供简单的原语，让分布式应用基于这些简单的分布式原语实现更高级别的同步，配置维护，分组和命名。以熟悉的文件系统目录树结构作为数据模型，运行该在Java环境下。
众所周知，协调服务很难做好，它们特别容易出现竞争条件和死锁等错误。zk的动机就是减轻分布式应用从头开始实现协调服务的责任。
设计目标
- zk是简单的。zk允许分布式进程通过共享的分层命名空间相互协调。该命名空间的组织形式类似于标准的文件系统。命名空间由数据寄存器组成--zk术语称为znode，它们类似于文件和目录。但是和传统文件不同的是它们存储在内存中，这意味着zk能实现高吞吐和低延迟。
zk的实现非常重视高性能，高可用，严格有序的访问。ZooKeeper 的性能方面意味着它可以用于大型分布式系统。可靠性方面使其不会成为单点故障。严格的排序意味着可以在客户端实现复杂的同步原语。 - zk是可复制的。和被zk协调的分布式进程一样，zk本身也是可以通过复制实现分布式的。组成zk集群的server之间必须相互了解，它们在内存中维护状态，在持久存储中维护事务日志和快照。只要大多数server可用，那么zk集群就是可用的。
client连接到单个zk-server，并维护一个TCP链接。通过该链接发送请求，获取响应，获取监听事件并发送心跳，如果TCP链接中断，client将连接不同的服务器。 - zk是顺序的。zk使用反映所有zk事务顺序的数字标记每个更新。后续的操作可以使用该顺序来实现更高级别的抽象。
- zk是快速的。它在以读取为主的工作负载中非常开，表现最佳的读写比例为10:1。
数据模型和分层命名空间
zk提供的命名空间像是一个标准的文件系统。每个路径代表zk命名空间的一个节点。节点和临时节点
zk命名空间中每个节点都可以拥其关联的数据以及子节点。这就好像是文件也可以拥有目录的文件系统。（zk设计用来存储协调数据：状态信息、配置、位置信息等，所以每个节点存储的数据通常很小，1M以内）我们使用术语 znode 来明确我们正在谈论 zk的 数据节点。 Znode 维护一个统计结构，其中包括数据更改、ACL 更改和时间戳的版本号，以允许缓存验证和协调更新。每次 znode 的数据更改时，版本号都会增加。例如，每当客户端检索数据时，它也会收到数据的版本。 存储在命名空间中每个 znode 的数据是原子读取和写入的。读取获取与 znode 关联的所有数据字节，写入替换所有数据。每个节点都有一个访问控制列表 (ACL)，它限制谁可以做什么。 ZooKeeper 也有临时节点的概念。只要创建 znode 的会话处于活动状态，这些 znode 就存在。当会话结束时，znode 被删除。协调更新和监控
ZooKeeper 支持监控的概念。客户端可以在 znode 上设置监视。当 znode 发生变化时，watch 将被触发并移除。当 watch 被触发时，客户端会收到一个数据包，说明 znode 已更改。如果客户端和其中一个 ZooKeeper 服务器之间的连接断开，客户端将收到本地通知。zk的保证
ZooKeeper 非常快速且非常简单。但是，由于它的目标是成为构建更复杂服务（例如同步）的基础，因此它提供了一组保证。这些都是：- 顺序一致性 - 来自客户端的更新将按照它们发送的顺序应用。
- 原子性 - 更新成功或失败。没有部分结果。
- 单一系统映像 - 客户端将看到相同的服务视图，而不管它连接到的服务器如何。即使客户端故障转移到具有相同会话的不同服务器，客户端也永远不会看到系统的旧视图。
- 可靠性 - 应用更新后，它将从那时起持续存在，直到客户端覆盖更新。
- 及时性——系统的客户视图保证在一定的时间范围内是最新的。数据最终一致性。
简单的API
ZooKeeper 的设计目标之一是提供一个非常简单的编程接口。因此，它仅支持以下操作： 1. create ：在tree中的某个位置创建一个节点 2. delete : 删除一个节点 3. exists ：测试节点是否存在于某个位置 4. 获取数据：从节点读取数据 5. 设置数据：将数据写入节点 6. 获取子节点：检索节点的子节点列表 7. sync ：等待数据传播实现
zk 组件展示了 zk 服务的高级组件。除了Request Processor之外，组成 ZooKeeper 服务的每个服务器都复制自己的每个组件的副本。 replicated database 是包含整个数据树的内存数据库。更新被记录到磁盘以便恢复，写入操作，先序列化到磁盘，再应用到数据库。 每个 ZooKeeper 服务器都服务于客户端。客户端仅连接到一台服务器以提交请求。从每个服务器数据库的本地副本为读取请求提供服务。改变服务状态的请求，写请求，由协处理。 作为协议的一部分，来自客户端的所有写入请求都被转发到单个服务器，称为leader。其余的 ZooKeeper 服务器，称为follower，接收来自领导者的消息提议并同意消息传递。消息传递层负责在失败时替换领导者并将追随者与领导者同步。 ZooKeeper 使用自定义原子消息传递协议。由于消息传递层是原子的，ZooKeeper 可以保证本地副本永远不会发散。当领导者收到一个写请求时，它会计算系统在应用写时的状态，并将其转换为捕获这个新状态的事务。应用场景
统一配置管理：zk保证了单一镜像，也就是不管连接哪一个server，看到的视图都相同。且每个znode可以保证1M的数据。所以可以使用zk来实现统一配置管理。
分组管理：zk提供的命名空间像是一个标准的文件系统。每个路径代表zk命名空间的一个节点。所以可以使用不同的目录层级来实现分组管理。
统一命名：zk保证在并发情况下创建同一个znode的版本管理，不会丢失。
分布式锁：使用zk提供的临时节点概念，节点和会话绑定在一起。从而实现分布式锁。且省略了考虑锁过期和client挂掉的情况。
常见问题
zk和redis的区别？同样实现的分布式锁有什么区别，怎么选择？
zk的集群怎么保证高可用？
kafka是怎么使用zk的？
标签：zookeeper,zk,ZooKeeper,znode,数据,节点,客户端 来源： https://www.cnblogs.com/drink-milk/p/16127858.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。