骏马金龙

网名骏马金龙,钟情于IT世界里的各种原理和实现机制,强迫症重症患者。爱研究、爱翻译、爱分享。特借此一亩三分田记录自己成长点滴!!!
我本问道人,道心不坚,必将与道无缘!

翻译:ZooKeeper OverView

ZooKeeper系列文章:https://www.cnblogs.com/f-ck-need-u/p/7576137.html#zk

 


ZooKeeper: 分布式协调服务

ZooKeeper是一个开源的为分布式应用提供分布式协调的服务。它公开了一组简单的原语,分布式应用程序可以基于这些原语实现更高级别的服务,包括同步、维护配置、组和命名。它的设计易于编程,它使用一个遵循文件系统中常见的目录树结构的数据模型。它在Java环境中运行,对Java和C都有绑定。

协调服务是出了名的难。它们特别容易出错,如竞态条件和死锁。ZooKeeper背后的动机是让分布式应用从零开始实现一站式协调服务。

设计目标

ZooKeeper很简单。通过共享一个类似于标准文件系统结构的层次名称空间,Zookeeper允许分布式进程进行各自的协调。名称空间中包含了注册数据——即所谓的znodes,它们类似于文件和目录。Zookeeper不像文件系统,目的是数据存储,Zookeeper的数据存放在内存中,这意味着zookeeper具有高吞吐量和低延迟的优点。

ZooKeeper非常注重高性能、高可用性、严格有序的访问。ZooKeeper的性能方面意味着它可以在大型分布式系统中使用。可靠性方面使它不会出现单点故障。严格有序意味着可以在客户端实现复杂的同步原语。

ZooKeeper是复制的。与它所协调的分布式进程一样,ZooKeeper本身也打算在一组主机上进行复制。

组成ZooKeeper的每个server之间都必须互相了解。每个server都维护状态信息(state)的内存映像,以及持久存储中的事务日志和快照。只要ZooKeeper中的大多数server可用,ZooKeeper服务就可用。

每个client连接到ZooKeeper集群中的某个server。客户端会与之建立TCP连接,通过该TCP连接来发送请求、获取响应、获取观察事件(watch events)以及发送心跳。如果TCP连接中断,客户端将连接到另一个server。

ZooKeeper是有序的。ZooKeeper给每次更新都贴上一个数字,这个数字反映了所有ZooKeeper事务的顺序。后续操作可以使用这个顺序来实现高级抽象,例如同步原语。

ZooKeeper速度很快,特别是在"以读为主"的工作负载中尤其快速。ZooKeeper应用程序可用在数千台机器上运行,在多读少写(比率在10:1左右)的环境中表现最好。

数据模型和有层次的名称空间

ZooKeeper提供的名称空间非常类似于标准文件系统。名称是由斜线(/)分隔的路径元素序列。在ZooKeeper名称空间中的每一个节点都是通过一条路径来标识的。

节点和临时节点

与标准文件系统不同的是,ZooKeeper名称空间中的每个节点(路径)都可以有与之关联的数据,子节点也如此(译注:即节点的路径自身携带数据)。这就像是一个既文件也目录的文件系统。(ZooKeeper的目的是存储协调数据:状态信息、配置、位置信息等,所以每个节点存储的数据通常都很小,一般都是kb级别的)。我们使用术语znode来明确说明我们正在讨论ZooKeeper数据节点。

znode维护一个包含数据更改版本号、ACL更改版本号和时间戳版本号的stat结构,以便能够做缓存验证和协调更新。每当znode的数据发生变化,版本号就会增加。例如,客户端每次检索数据的同时,也会接收数据的版本信息。

名称空间中,每个znode上存储的数据的读、写操作都是原子性的。读操作会获取与znode关联的所有数据,写操作会替换所有数据。每个节点都有一个访问控制列表(ACL),限制谁可以做什么。

ZooKeeper也有临时节点(ephemeral nodes)的概念。只要创建这些znode的会话(session)是活动的,这些znode就存在。当会话结束时,znode被删除。当您想要实现[tbd]时,临时节点非常有用。

协调更新和watch

ZooKeeper支持观察(watch)的概念。客户端可以在znode上设置一个watch。当znode更改时,将触发并删除一个watch。当watch被触发时,客户端会收到一个通知znode已更改的数据包。如果客户端和ZooKeeper server之间的TCP连接中断了,客户端将收到本地通知。这些可用于[tbd]。

ZooKeeper的保证

ZooKeeper快速又简单。但由于它的目标是作为构建更复杂服务(如同步)的基础,所以它要实现一些保证。包括:

  • 序列的一致性:(Sequential Consistency)来自客户端的更新将按照发送的顺序进行应用。
  • 原子性:(Atomicity)更新要么成功,要么失败。没有部分成功、失败的结果。
  • 单系统映像:(Single System Image)无论连接到ZooKeeper中的哪个server,客户端都将看到相同的服务视图。
  • 可靠性:(Reliability)一旦应用了更新,它将一直持续到有客户端对它做了覆盖更新。
  • 时效性:(Timeliness)保证客户端看到的视图在一定的时间范围内是最新的。

更多信息,以及如何使用它们,请参见[tbd]。

Simple API

ZooKeeper的一个设计目标是提供非常简单的编程接口。因此,它只支持以下几个操作:

  1. create:在树中的某个位置创建一个节点。
  2. delete:删除一个节点。
  3. exists:测试一个节点是否存在。
  4. get data:读取节点数据。
  5. set data:向节点中写入数据。
  6. get children:检索某节点的子节点列表。
  7. sync:等待要传播的数据。

更深入内容,以及如何使用它们实现更高级别的操作,请参阅[tbd]。

Implementation

下图显示了ZooKeeper服务的高层组件。除了request processor,构成ZooKeeper Service的每个server都复制自己的每个组件副本。

replicated database是包含整个数据树(data tree)的内存数据库。每次发起的更新都会将其记录到磁盘中的日志,以便以后能够进行恢复(recovery),在更新真正应用到内存数据库之前,还会先将更新序列化到磁盘中。

每个ZooKeeper server都会为客户端提供服务。客户端连接到一个server来提交request。对于read request,每个server会从本地database的副本中提供服务。对于write request,这些请求会更改服务状态,它们由协商协议(agreement procotol)来处理。

作为协商协议(agreement procotol)的一部分,所有来自客户端的write request都被转发到一个称为leader的server上。ZooKeeper中的其它server,都称为follower,它们接收来自leader的消息,并传递那些达成一致的消息。消息层(messaging layer)负责在leader故障时选举新的leader,并剩余的follower和新的leader保持同步。

ZooKeeper使用一个自定义的原子消息传递协议。由于该消息层是原子性的,ZooKeeper可以保证本地副本永远不会出现分歧。当leader收到write request时,它会计算当写操作被执行时系统状态,并将其转换为带有该状态的事务

ZooKeeper的使用

ZooKeeper的编程接口很简单。但有了它,您可以实现更高级的操作,比如同步原语、组成员关系(group membership)、所有权(ownership)等等。更多信息请参阅[tbd]。

ZooKeeper性能

ZooKeeper具有高性能。真的如此吗?雅虎ZooKeeper的开发团队的研究结果已经表明确实如此。(参见下图)。当读操作比写操作更频繁时,ZooKeeper的性能非常高,因为写操作会调用所有节点的状态同步。(协调服务的典型情况就是多读少写)。

注意:在3.2版本中,r/w的性能比3.1版本提高了大约2倍。

posted @ 2018-06-26 20:44  骏马金龙  阅读(...)  评论(...编辑  收藏