高可用性的高性能协调服务Zookeeper简单介绍以及整理

作者: admin 分类: Zookeeper 发布时间: 2018-03-08 13:47  阅读: 377 views

Zookeeper是一种高可用性的高性能协调服务。使用Zookeeper可以提供一组工具,使之在构建分布式应用时能够对部分失败进行正确处理。

它具有以下特点

1.简单.

Zookeeper是一个精简的文件系统,提供一些简单的操作和一些额外的抽象操作,如排序\通知

2.富有变现力.

Zookeeper的基本操作是一组丰富的构件,可用于实现多种协调数据结构和协议。如:分布式队列、分布式所、一组节点中的master处理

3.高可用性(减少停工时间)

Zookeeper运行于一组机器智商,并且在设计上具有高可用性,可以完全依赖。

4.松耦合交互方式

在Zookeeper支持的交互过程中,参与者不需要彼此了解。如:Zookeeper可以用于实现“数据汇集”机制,让进城在不了解其他进程的情况下能够彼此发现并进行信息交互。参与的各方可以不必同时存在,因为一个进程可以在Zookeeper中留下一条信息,在进程借宿后,另外一个进程可以读取这条消息。

Zookeeper中的组成员关系

理解Zookeeper的一种方法就是将其看作一个具有高可用性特征的文件系统。这个文件系统没有文件和目录。而是统一使用“节点”的概念,称为znode.znode既可以作为保存数据的容器,也可以作为保存其他znode的容器。所有的znode构成了一个层次化的命名空间,一种自然的建立组成员列表的方式就是利用这种层次关系,创建一个以组名为节点名的znode作为父节点,然后以组成员名(服务器名)的节点来创建来作为子节点的znode.

Zookeeper是一个具有高可用性的高性能协调服务

1. 数据模型

Zookeeper维护着一个树形层次结构,树中的节点被称为znode。znode可以用于存储数据,并且有一个与之关联的ACL(access control list)。Zookeeper被设计用来实现协调服务,而不是用于大容量数据存储。因此,一个znode能存储的数据限制在1MB以内。

Zookeeper的数据访问具有与原子性。

znode通过路径被引用。

在zookeeper中,路径由Unicode字符串构成,并有限制.

2.操作

Zookeeper中的更新操作是有条件的。使用delete或setData操作时必须提供被更新znode的版本号,如果不匹配,更新操作会失败。更新操作是非阻塞操作,因此一个更新失败的客户端可以决定是否充实,或执行其他操作,不会阻塞其他进城的执行。

虽然Zookeeper可以被看作是一个文件系统,但出于简单性的需要,有一些文件系统的基本操作被摒弃了。Zookeeper文件较小且总是被整体读写,因此没有必要提供打开、关闭或查找操作。

3. 实现

Zookeeper服务有两种不同的运行模式,一种是“独立模式”,即只有一个Zookeeper服务器。该模式较为简单,比较适合于测试环境,但是不能保证高可用性和可恢复性。在生产环境中的 ZooKeeper通常以“复制模式”运行于一个计算机集群上,这个计算机集群被称为一个“集合体”。ZooKeeper通过复制来实现高可用性,只要集合体中半数以上的机器出于可用状态,它就能够提供服务。

从概念上来说,zookeeper是非常简单的:它所做的就是确保对znode树的每一个修改都会被复制到集合体中超过半数的机器上。如果少于半数的机器出现故障,则最少有一台机器会保存最新的状态,其余的副本最终也会更新到这个状态。但这个简单想法的实现不简单。Zookeeper使用Zab协议,该协议包括两个可以无限重复的阶段。

阶段一:领导者选举

集合体中的所有机器通过一个选择过程来选出一台被称为“领导者”的机器,其他的机器被称为“跟随者”,一旦半数以上的跟随者已经将其状态与领导者同步,则表明这个阶段已经完成。

阶段二:原子广播

所有的写请求都会被转发给领导者,再由领导者将更新广播给跟随者。当半数以上的跟随者已经将吸怪持久化之后,领导才会提交这个更新,然后客户端才会收到一个更新成功的响应。

4.一致性

理解Zookeeper的实现有助于理解其服务所提供的一致性保证。

一个跟随者可能滞后于领导者几个更新。这也表明在一个修改被提交之前,只需要集合体中半数以上机器已经将该修改持久化即可。对于ZooKeeper来说,理想的情况就是将客户端都连接到于领导者状态一致的服务器上。但客户端无法对此控制,自己无法知道是否连接到领导者。

每一个对znode树的更新都被赋予了一个全局唯一的ID,称为zxid.Zookeeper要求对所有的更新进行编号并排序,它决定了分布式系统的执行顺序,如zxid的 z1小于z2,则z1一定发生在z2前。

 

Zookeeper中通过以下几点保证了数据的一致性。

a.顺序一致性

来自任意特定客户端的更新都会按其发送顺序被提交。

b.原子性

每个更新要不成功,要不失败。

c.单一系统映像

一个客户端无论连接到哪一台服务器,它看到的都是同样的系统视图。

d. 持久性

一个更新一旦成功,其结果就会持久存在并且不会被撤销

e.及时性

任何客户端所看到的滞后系统视图都是有限的,不会超过几十秒。

5. 会话

每个Zookeeper客户端的配置中都包括集合体中服务器的列表。在启动时,客户端会尝试连接到列表中的一台服务器。如果失败,会连接到另一台服务器。

一旦客户端与一台Zookeeper服务器建立连接,这台服务器就会为该客户端创建一个新的会话。每个会话都会有一个超时的时间设置,这个设置由创建会话的应用来设定。如果服务器在超时时间段内没有收到任何请求,则相应的会话会过期。一旦一个会话已过期,就无法重新打开,并且任何与该会话相关联的短暂znode都会丢失。

只要一个会话空闲超过一定时间,都可以通过客户端发送ping请求来保持会话不过期。(ping请求是由Zookeeper的客户端库自动发送,因此在代码中不需要考虑如何维护会话)。这个时间长度的设置应当足够度低,以便检测出服务器故障,并在会话超时的时间段内重新连接到另一台服务器。

ZooKeeper客户端可以自动地进行故障切换,切换至另一台ZooKeeper服务器,并且关键的是,另一台服务器接替故障服务器之后,所有的会话仍然是有效的。在故障切换过程中,应用程序将受到断开连接和连接至服务的通知。这说明了ZooKeeper应用中处理连接丢失异常的重要性。

6.状态

Zookeeper对象在其生命周期中会经历集中不同的状态,可以在任何时刻通过getState()查询对象的状态。

zookeeper的watcher对象肩负着双重责任:一方面可以用户获得zookeeper状态变化的相关通知;另一方面可以用户获得znode变化的相关通知。

 

ZooKeeper的应用构建

配置服务是分布式应用所需要的基本服务之一,它使集群中的机器可以共享配置信息中的那些公共的部分。Zookeeper可以作为一个具有高可用性的配置存储器,允许分布式应用的参与者检索和更新配置文件。

 

JAVA api中的每一个ZooKeeper操作都在其throws子句中声明了两种类型的异常。

1. InterruptedException异常

2. KeeperException异常(状态异常,可恢复异常,不可恢复异常)


   原创文章,转载请标明本文链接: 高可用性的高性能协调服务Zookeeper简单介绍以及整理

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!

发表评论

电子邮件地址不会被公开。 必填项已用*标注

更多阅读