标题:
ZooKeeper 基础知识、部署和应用程序(1)
[打印本页]
作者:
look_w
时间:
2018-6-23 08:46
标题:
ZooKeeper 基础知识、部署和应用程序(1)
简介让我们首先讨论一下为什么想使用 ZooKeeper。ZooKeeper是一个面向分布式系统的构建块。当设计一个分布式系统时,一般需要设计和开发一些协调服务:
名称服务
—名称服务是将一个名称映射到与该名称有关联的一些信息的服务。电话目录是将人的名字映射到其电话号码的一个名称服务。同样,DNS服务也是一个名称服务,它将一个域名映射到一个 IP地址。在分布式系统中,您可能想跟踪哪些服务器或服务在运行,并通过名称查看其状态。ZooKeeper暴露了一个简单的接口来完成此工作。也可以将名称服务扩展到组成员服务,这样就可以获得与正在查找其名称的实体有关联的组的信息。
锁定
—为了允许在分布式系统中对共享资源进行有序的访问,可能需要实现分布式互斥(distributedmutexes)。ZooKeeper 提供一种简单的方式来实现它们。
同步
—与互斥同时出现的是同步访问共享资源的需求。无论是实现一个生产者-消费者队列,还是实现一个障碍,ZooKeeper都提供一个简单的接口来实现该操作。您可以在 Apache ZooKeeper维基上查看示例,了解如何做到这一点(参阅 )。
配置管理
— 您可以使用 ZooKeeper集中存储和管理分布式系统的配置。这意味着,所有新加入的节点都将在加入系统后就可以立即使用来自ZooKeeper 的最新集中式配置。这还允许您通过其中一个 ZooKeeper客户端更改集中式配置,集中地更改分布式系统的状态。
领导者选举
—分布式系统可能必须处理节点停机的问题,您可能想实现一个自动故障转移策略。ZooKeeper通过领导者选举对此提供现成的支持。
虽然可以从头开始设计和实现所有这些服务,但调试任何问题、竞争条件或死锁都需要执行额外的工作,并且很难实现。就像您不会在代码中随处编写自己的随机数发生器或哈希函数一样,这里有一个要求:人们不应该在每次有需要时就到处从头编写自己的名称服务或领导者选举服务。此外,您可以相对容易地一起解决一个非常简单的组成员服务,但是,要编写它们来提供可靠性、复制和可扩展性,可能需要做更多的工作。这导致了Apache ZooKeeper 的开发和开源,Apache ZooKeeper是一个针对分布式系统的、开箱即用的、可靠的、可扩展的、高性能的协调服务。
InfoSphere® BigInsights™ QuickStart Edition 是 IBM 的大数据产品,以开源的 Apache Hadoop项目为基础。它包括 ZooKeeper 和其他大数据技术,以及增加了该平台的价值的 IBM技术。在本文中,我们只是使用了 ZooKeeper,但是,如欲了解有关 InfoSphereBigInsights 的更多信息,请参阅 ,其中包括一个下载产品的链接。
ZooKeeper虽然是一个针对分布式系统的协调服务,但它本身也是一个分布式应用程序。ZooKeeper遵循一个简单的客户端-服务器模型,其中
客户端
是使用服务的节点(即机器),而
服务器
是提供服务的节点。ZooKeeper服务器的集合形成了一个 ZooKeeper
集合体(ensemble)
。在任何给定的时间内,一个 ZooKeeper客户端可连接到一个 ZooKeeper 服务器。每个 ZooKeeper服务器都可以同时处理大量客户端连接。每个客户端定期发送 ping 到它所连接的 ZooKeeper服务器,让服务器知道它处于活动和连接状态。被询问的 ZooKeeper 服务器通过 ping确认进行响应,表示服务器也处于活动状态。如果客户端在指定时间内没有收到服务器的确认,那么客户端会连接到集合体中的另一台服务器,而且客户端会话会被透明地转移到新的ZooKeeper 服务器。
图 1 描述了ZooKeeper 的客户端-服务器架构。
图 1. ZooKeeper 的客户端-服务器架构
ZooKeeper 有一个类似于文件系统的数据模型,由
znodes
组成。可以将 znodes(ZooKeeper 数据节点)视为类似 UNIX的传统系统中的文件,但它们可以有子节点。另一种方式是将它们视为目录,它们可以有与其相关的数据。每个这些目录都被称为一个znode。图 2显示的图代表与两个城市中的运动队相同的层次结构。
图 2. 该图表示了两个城市中的运动队的层次结构
znode 层次结构被存储在每个 ZooKeeper服务器的内存中。这实现了对来自客户端的读取操作的可扩展的快速响应。每个 ZooKeeper服务器还在磁盘上维护了一个事务日志,记录所有的写入请求。因为 ZooKeeper服务器在返回一个成功的响应之前必须将事务同步到磁盘,所以事务日志也是 ZooKeeper中对性能最重要的组成部分。可以存储在 znode 中的数据的默认最大大小为 1 MB。因此,即使ZooKeeper的层次结构看起来与文件系统相似,也不应该将它用作一个通用的文件系统。相反,应该只将它用作少量数据的存储机制,以便为分布式应用程序提供可靠性、可用性和协调。
当客户端请求读取特定 znode的内容时,读取操作是在客户端所连接的服务器上进行的。因此,由于只涉及集合体中的一个服务器,所以读取是快速和可扩展的。然而,为了成功完成写入操作,要求ZooKeeper 集合体的严格意义上的多数节点都是可用的。在启动 ZooKeeper服务时,集合体中的某个节点被选举为领导者。当客户端发出一个写入请求时,所连接的服务器会将请求传递给领导者。此领导者对集合体的所有节点发出相同的写入请求。如果严格意义上的多数节点(也被称为
法定数量(quorum)
)成功响应该写入请求,那么写入请求被视为已成功完成。然后,一个成功的返回代码会返回给发起写入请求的客户端。如果集合体中的可用节点数量未达到法定数量,那么ZooKeeper 服务将不起作用。
InfoSphere BigInsights Quick StartEditionZooKeeper 是 InfoSphere BigInsights(IBM 基于Hadoop 的产品)中的一个组件。Quick Start Edition 是一个免费的、可下载的InfoSphere BigInsights 版本。使用 Quick StartEdition,您可以尝试使用 ZooKeeper 和 IBM 开发的特性来提高开源 Hadoop的价值,比如 Big SQL、文本分析和BigSheets。引导式学习可让您的体验尽可能地顺畅,包括按部就班、自订进度的教程和视频,可帮助您开始让Hadoop 为您所用。没有时间或数据限制,您可以自行安排时间,在大量数据上试验。请 、 和 。
法定数量是通过严格意义上的多数节点来表示的。在集合体中,可以包含一个节点,但它不是一个高可用和可靠的系统。如果在集合体中有两个节点,那么这两个节点都必须已经启动并让服务正常运行,因为两个节点中的一个并不是严格意义上的多数。如果在集合体中有三个节点,即使其中一个停机了,您仍然可以获得正常运行的服务(三个中的两个是严格意义上的多数)。出于这个原因,ZooKeeper的集合体中通常包含奇数数量的节点,因为就容错而言,与三个节点相比,四个节点并不占优势,因为只要有两个节点停机,ZooKeeper服务就会停止。在有五个节点的集群上,需要三个节点停机才会导致 ZooKeeper服务停止运作。
现在,我们已经清楚地了解到,节点数量应该是奇数,让我们再来思考一下 ZooKeeper集合体中需要有多少个节点。读取操作始终从连接到客户端的 ZooKeeper服务器读取数据,所以它们的性能不会随着集合体中的服务器数量额变化而变化。但是,仅在写入法定数量的节点时,写入操作才是成功的。这意味着,随着在集合体中的节点数量的增加,写入性能会下降,因为必须将写入内容写入到更多的服务器中,并在更多服务器之间进行协调。
ZooKeeper 的美妙之处在于,想运行多少服务器完全由您自己决定。如果想运行一台服务器,从ZooKeeper 的角度来看是没问题的;只是您的系统不再是高度可靠或高度可用的。三个节点的ZooKeeper集合体支持在一个节点故障的情况下不丢失服务,这对于大多数用户而言,这可能是没问题的,也可以说是最常见的部署拓扑。不过,为了安全起见,可以在您的集合体中使用五个节点。五个节点的集合体让您可以拿出一台服务器进行维护或滚动升级,并能够在不中断服务的情况下承受第二台服务器的意外故障。
因此,在 ZooKeeper集合体中,三、五或七是最典型的节点数量。请记住,ZooKeeper集合体的大小与分布式系统中的节点大小没有什么关系。分布式系统中的节点将是 ZooKeeper集合体的客户端,每个 ZooKeeper服务器都能够以可扩展的方式处理大量客户端。例如,HBase(Hadoop上的分布式数据库)依赖于 ZooKeeper实现区域服务器的领导者选举和租赁管理。您可以利用一个相对较少(比如说,五个)节点的ZooKeeper 集合体运行有 50 个节点的大型 HBase 集群。
欢迎光临 电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/)
Powered by Discuz! 7.0.0