大数据之Zookeeper概述

Zookeeper概述

Zookeeper是一个开放源码的分布式应用程序协调服务，是 Google的Chubby一个开源的实现，是 Hadoop和 HBASE的重要组件。主要解决分布式应用一致性问题。

1.分布式应用

分布式应用能够在给定时间（同时）在网络中的多个系统上运行，经过协调它们以快速有效的方式完成特定任务。一般来讲，对于复杂而耗时的任务，非分布式应用（运行在单个系统中）须要几个小时才能完成，而分布式应用经过使用全部系统涉及的计算能力能够在几分钟内完成。

经过将分布式应用配置为在更多系统上运行，能够进一步减小完成任务的时间。分布式应用正在运行的一组系统称为集群，而在集群中运行的每台机器被称为节点。

分布式应用有两部分， Server（服务器） 和 Client（客户端） 应用程序。服务器应用程序其实是分布式的，并具备通用接口，以便客户端能够链接到集群中的任何服务器并得到相同的结果。 客户端应用程序是与分布式应用进行交互的工具。

 

 

分布式应用的优势

• 可靠性 - 单个或几个系统的故障不会使整个系统出现故障。
• 可扩展性 - 能够在须要时增长性能，经过添加更多机器，在应用程序配置中进行微小的更改，而不会有停机时间。
• 透明性 - 隐藏系统的复杂性，并将其显示为单个实体/应用程序。

分布式应用的挑战

• 竞争条件 - 两个或多个机器尝试执行特定任务，实际上只需在任意给定时间由单个机器完成。例如，共享资源只能在任意给定时间由单个机器修改。
• 死锁 - 两个或多个操做等待彼此无限期完成。
• 不一致 - 数据的部分失败。

       分布式应用程序提供了不少好处，但它们也抛出了一些复杂和难以解决的挑战。ZooKeeper框架提供了一个完整的机制来克服全部的挑战。

2. Zookeeper简介

       Zookeeper是一个可以高效开发和维护分布式的开放源码的应用协调服务。是Google的 Chubby一个开源的实现，是 Hadoop和 HBASE的重要组件。Zookeeper是一个为分布式应用提供一致性服务的软件，提供的功能包括维护配置信息、名字服务、分布式同步、组服务等。ZooKeeper框架最初是在“Yahoo!"上构建的，用于以简单而稳健的方式访问他们的应用程序。 后来，Apache ZooKeeper成为Hadoop，HBase和其余分布式框架使用的有组织服务的标准。

首先咱们对上一个段落作一个解释。

1. Zookeeper是一个开放源代码的软件。
2. Zookeeper是一个管理“分布式应用程序”的软件。什么是分布式应用程序服务？咱们知道，Hadoop中的组件，如hdfs、MapReduce/yarn、hbase、double、kafka都是分布式服务。如MapReduce就是一个分布式服务，MapReduce会将所作的工做分发给Hadoop集群中的多台服务器共同实现。如何对分布式服务作协调，管理这些运行在不一样电脑上的任务？就须要一个对分布式应用程序作协调的服务，这就是Zookeeper的工做。
3. Zookeeper能够实现对分布式应用程序作一致性服务，什么是一致性服务？好比咱们对A服务器上的一个数据进行了修改，这个数据同时在D服务器和M服务器有两个备份，这时就要对D服务器和M服务器有两个备份都进行修改，这就是一致性服务。Zookeeper就能够实现这么一个一致性服务。
4. Zookeeper实现的强一致性服务。一致性服务分为3类，分别是：

• 强一致性：a发生变化，b马上就发生变化
• 弱一致性：a发生变化，b过一会会发生变化
• 最终一致性：a发生变化，b最终也会发生变化     

    Zookeeper能够实现马上的数据一致性，即强一致性。

       你们知道，Hadoop生态系统中的组件，都喜欢起动物的名称。如Hadoop、Hive、Pig等。而Zookeeper中文意思是动物园管理员，就是管理Hadoop生态系统。

　　　5.       ZooKeeper的好处

       如下是使用ZooKeeper的好处：

• 简单的分布式协调过程
• 同步 - 服务器进程之间的相互排斥和协做。此过程有助于Apache HBase进行配置管理。
• 有序的消息
• 序列化 - 根据特定规则对数据进行编码。确保应用程序运行一致。这种方法能够在MapReduce中用来协调队列以执行运行的线程。
• 可靠性
• 原子性 - 数据转移彻底成功或彻底失败，但没有事务是部分的。

3 .Zookeeper的选举机制

看看下面的图表。它描述了ZooKeeper的“客户端-服务器架构”。

 

 

配置多个实例共同构成一个Zookeeper集群对外提供服务以达到水平扩展的目的，集群中的每一台电脑都称为服务器(Server)，每一个服务器上的数据是相同的，每个服务器都可以对外提供读和写的服务，这点和redis是相同的，即对客户端来说每一个服务器都是平等的。zookeeper集群通常须要奇数台服务器，为何是奇数台服务器？由于咱们须要经过选举机制选出领导者(leader)，因此必须是奇数台服务器。

Zookeeper提供了三种选举机制：

•  LeaderElection
• AuthFastLeaderElection
• FastLeaderElection

默认的算法是FastLeaderElection，因此这篇主要分析它的选举机制。

 

客户端(client)是请求发起方。服务器分为不一样的角色，有领导者(leader)，也有学习者(learner)。角色的不一样是在选举中产生的，下面是选举的流程。

目前有5台服务器，每台服务器均没有数据，它们的编号分别是A,B,C,D,E按编号依次启动，它们的选择举过程以下：

• 服务器A启动，给本身投票，而后发投票信息，因为其它机器尚未启动因此它收不到反馈信息，服务器A的状态一直属于Looking(选举状态)。
• 服务器B启动，给本身投票，同时与以前启动的服务器A交换结果，因为服务器B的编号大因此服务器B胜出，但此时投票数没有大于半数，因此两个服务器的状态依然是Looking(选举状态)。
• 服务器C启动，给本身投票，同时与以前启动的服务器A,B交换信息，因为服务器C的编号最大因此服务器C胜出，此时投票数正好大于半数，因此服务器C成为领导者(Leader)，服务器A,B成为小弟。
• 服务器D启动，给本身投票，同时与以前启动的服务器A,B,C交换信息，尽管服务器D的编号大，但以前服务器C已经胜出，因此服务器D只能成为小弟。
• 服务器E启动，后面的逻辑同服务器E成为小弟。

这里的小弟就是学习者(learner)。学习者(learner)分为两类，可以参与投票的就是跟随者(follower)，不然就是观察者(observer)。

服务器有如下状态。

• LOOKING：竞选状态。
• FOLLOWING：随从状态，同步leader状态，参与投票。
• OBSERVING：观察状态，同步leader状态，不参与投票。
• LEADING：领导者状态。

下面是选举的简易流程图。

 

 

如下是选举状态图

 

描述Leader选择过程当中的状态变化，这是假设所有实例中均没有数据，假设服务器启动顺序分别为：A,B,C。

 

角色	描述
服务器(Server)	领导者(Leader)	服务器节点，负责进行投票的发起和决议，更新系统状态。
学习者(Learner)	跟随者(Follower)	服务器节点，用于接收客户端请求并向客户端返回结果，在选举过程当中能参与投票。
观察者(Observer)	当集群节点数目逐渐增大为了支持更多的客户端，须要增长更多Server，然而Server增多，投票阶段延迟增大，影响性能。为了权衡伸缩性和高吞吐率，引入Observer。 服务器节点，能够接收客户端链接，将写请求转发给Leader节点。但Observer不能参与投票，只同步Leader的状态。Observer的目的是为了扩展系统，提升读取速度。
客户端(Client)	请求发起方

4. Zookeeper的读写机制

Zookeeper是分布式应用程序的协调程序。分布式应用程序运行在集群上，客户端对一台服务器的请求完成后修改了数据并将数据同步到其余备份，而且须要将结果告知集群中全部电脑，这个由分布式应用程序自身实现吗？能够，可是也能够由另外一个协调程序完成这个功能，Zookeeper就是这么一个协调程序。下面咱们介绍如下Zookeeper写流程。下面咱们见下图。

 

 

 

 

客户端首先和一个Server或者Observer（能够认为是一个Server的代理）通讯，发起写请求，而后Server将写请求转发给Leader，Leader再将写请求转发给其余Server，Server在接收到写请求后写入数据并回应Leader，Leader在接收到大多数写成功回应后，认为数据写成功，回应Client。

Zookeeper读取由特定链接的Server在内部执行，所以不须要与集群进行交互。

5. Zookeeper的数据模型

Zookeeper的数据保存在一个相似于文件系统的一个树形结构中，每一个数据节点只能携带少许的数据。为何只能携带少许的数据呢？由于Zookeeper用于进行协调服务的，因此不须要携带大量数据。

每一个数据节点（树中的每个分支节点或者叶子节点）称之为znode。每个znode节点既是目录又是文件（是文件的含义是它能够带少许数据，是目录的含义是它有可能还有子目录），这和咱们普通看到的文件系统不同。

 

 

每一个目录在zookeeper中叫作znode,而且其有一个惟一的路径标识，如/services/myservice/servers/stuidname1

• znode有两种类型，短暂的(ephemeral: 断开链接本身删除)和持久的(ersistent: 断开链接不删除)；
• znode能够包含数据和子znode(ephemeral类型的节点不能有子znode)；
• znode中的数据能够有多个版本，好比某一个znode下存有多个数据版本，那么查询这个路径下的数据需带上版本；

建立znode时设置顺序标识，znode名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护 。

如存一个/stu/name值mike，会对路径上加序列化，如/name000001

再存一个/stu/name值jack，会对路径上加序列化， 如/name000002

上面的znode就有两个版本

•   客户端应用能够在znode上设置监视器(Watcher)。
•   znode不支持部分读写，而是一次性完整读写
•   znode的类型在建立时肯定而且以后不能再修改；
•   ephemeral znode的客户端会话结束时，zookeeper会将该ephemeral znode删除，ephemeral znode不能够有子节点；
•   persistent znode不依赖于客户端会话，只有当客户端明确要删除该persistent znode时才会被删除；

Zookeeper以节点的方式存储一些关键信息，默认状况下，全部应用均可以读写任何节点，在复杂的应用中，这不太安全，Zookeeper经过ACL(Access Controll List)机制来解决访问权限问题。

整体来讲，Zookeeper的节点有5种ACL(Access Controller List)权限：

•   CREATE 容许建立Child Nodes
•   READ 容许获取ZNode的数据，以及该节点的孩子列表
•   WRITE 能够修改ZNode的数据
•   DELETE 能够删除一个孩子节点
•   ADMIN 能够设置权限

这5种权限简写为crwda(即：每一个单词的首字符缩写)。注意这5种权限中，delete是指对子节点的删除权限，其它4种权限指对自身节点的操做权限。

 

6. Zookeeper的监听机制

Zookeeper的节点是能够被监控，目录中存储数据的修改、子节点目录的变化，均可以触发事件并通知监听的客户端，这是 Zookeeper重要的特性。经过此特性能够实现的功能个监听事件是一个有配置的集中管理、集群管理、分布式锁等。监听机制官方说明为次性的监听器，当被设置了监听的数据发生变化时，服务器就会将这个改变发送给负责设置 Watch的客户端。

 ZooKeeper中的Watch是只能触发一次。也就是说，若是客户端在指定的ZNode设置了Watch，若是该ZNode数据发生变动，ZooKeeper会发送一个变动通知给客户端，同时触发设置的Watch事件。若是ZNode数据又发生了变动，客户端在收到第一次通知后没有从新设置该ZNode的Watch，则ZooKeeper就不会发送一个变动通知给客户端。

Zookeeper的特色是

• 一次性触发
•  事件触发后发给客户端。
• 数据被设置 Watch