大数据开发zookeeper

　　昨天不是给大家带来了zookeeper前瞻吗？今天紧接着就给大家带来大数据开发zookeeper，将带大家进一步了解zookeeper。不知道大家第一次听说zookeeper是有一种什么的印象，但我就是单纯的理解为动物园管理员了，具体什么原因，就跟着看下去吧。
　　一、Zookeeper由来
　　Zookeeper最早起源于雅虎研究院的一个研究小组，而雅虎内部很多大型系统基本上都需要依赖一个类似的系统来进行分布式协调，但是这些系统往往都存在分布式单点问题。为此，雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架，以便让开发人员将精力集中在处理业务逻辑上。
　　在立项初期，因为内部很多项目都是使用动物的名字来命名的（例如著名的Pig项目），雅虎的工程师希望给这个项目也取一个动物的名字，当时任命于研究院的首席科学家RaghuRamakrishnan开玩笑地说：在这样下去，我们这儿就变成动物园了！
　　此话一出，大家纷纷表示就叫动物园管理员吧，因为各个以动物命名的分布式组件放在一起，雅虎的整个分布式系统看上去就像一个大型的动物园了。
　　而Zookeeper正好要用来进行分布式环境的协调，于是，Zookeeper的名字也就由此诞生了。
　　二、Zookeeper认知
　　ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop的重要组件，CDH版本中更是使用它进行Namenode的协调控制。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、名字服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
　　Zookeeper中的角色主要有以下三类，如下图：
　　三、重要概念
　　1。ZooKeeper本身就是一个分布式程序（只要半数以上节点存活，ZooKeeper就能正常服务）。
　　为了保证高可用，最好是以集群形态来部署ZooKeeper，这样只要集群中大部分机器是可用的（能够容忍一定的机器故障），那么ZooKeeper本身仍然是可用的。
　　2。ZooKeeper将数据保存在内存中，这也就保证了高吞吐量和低延迟（但是内存限制了能够存储的容量不太大，此限制也是保持Znode中存储的数据量较小的进一步原因）。
　　3。ZooKeeper是高性能的。在读多于写的应用程序中尤其地高性能，因为写会导致所有的服务器间同步状态。（读多于写是协调服务的典型场景。）
　　4。ZooKeeper有临时节点的概念。当创建临时节点的客户端会话一直保持活动，瞬时节点就一直存在。
　　而当会话终结时，瞬时节点被删除。持久节点是指一旦这个ZNode被创建了，除非主动进行ZNode的移除操作，否则这个ZNode将一直保存在Zookeeper上。
　　5。ZooKeeper底层其实只提供了两个功能：第一个是：管理（存储、读取）用户程序提交的数据；另一个则是：为用户程序提交数据节点监听服务。
　　会话（Session）
　　Session指的是ZooKeeper服务器与客户端会话。在ZooKeeper中，一个客户端连接是指客户端和服务器之间的一个TCP长连接。
　　Znode
　　在ZooKeeper中，节点分为两类：
　　第一类同样是指构成集群的机器，我们称之为机器节点。
　　第二类则是指数据模型中的数据单元，我们称之为数据节点一ZNode。
　　ZooKeeper将所有数据存储在内存中，数据模型是一棵树（ZnodeTree），由斜杠（）的进行分割的路径，就是一个Znode，例如foopath1。每个上都会保存自己的数据内容，同时还会保存一系列属性信息。
　　Watcher
　　Watcher（事件监听器），是ZooKeeper中的一个很重要的特性。
　　ZooKeeper允许用户在指定节点上注册一些Watcher，并且在一些特定事件触发的时候，ZooKeeper服务端会将事件通知到感兴趣的客户端上去，该机制是ZooKeeper实现分布式协调服务的重要特性。
　　ACL
　　ZooKeeper采用ACL（AccessControlLists）策略来进行权限控制，类似于UNIX文件系统的权限控制。
　　四、ZooKeeper特点
　　Zookeeper具体有4个特点：
　　1。顺序一致性：从同一客户端发起的事务请求，最终将会严格地按照顺序被应用到ZooKeeper中去。
　　2。原子性：所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用。
　　3。单一系统映像：无论客户端连到哪一个ZooKeeper服务器上，其看到的服务端数据模型都是一致的。
　　4。可靠性：一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖。
　　本期内容就是这些了，希望大家结合昨天那篇大数据开发zookeeper前瞻一起理解，这样能够容易看懂一些。和zookeeper一样，希望大家对知识也要做个keeper，不要学完就忘了。
　　希望大家点个关注，及时收取最新文章推送，想了解更多敬请咨询加米谷大数据。
　　有问题的欢迎在评论区留言，如有侵权请告知。