ZooKeeper详细分析,zookeeper源码分析

('前言相信大家对ZooKeeper应该不算陌生。但是你真的了解ZooKeeper是个什么东西吗？如果别人/面试官让你给他讲讲ZooKeeper是个什么东西，你能回答到什么地步呢？我本人曾经使用过ZooKeeper作为Dubbo的注册中心，另外在搭建solr集群的时候，我使用到了ZooKeeper作为solr集群的管理工具。前几天，总结项目经验的时候，我突然问自己ZooKeeper到底是个什么东西？想了半天，脑海中只是简单的能浮现出几句话：“①Zookeeper可以被用作注册中心。②Zookeeper是Hadoop生态系统的一员；③构建Zookeeper集群的时候，使用的服务器最好是奇数台。”可见，我对于Zookeeper的理解仅仅是停留在了表面。所以，通过本文，希望带大家稍微详细的了解一下ZooKeeper。如果没有学过ZooKeeper，那么本文将会是你进入ZooKeeper大门的垫脚砖。如果你已经接触过ZooKeeper，那么本文将带你回顾一下ZooKeeper的一些基础概念。最后，本文只涉及ZooKeeper的一些概念，并不涉及ZooKeeper的使用以及ZooKeeper集群的搭建。网上有介绍ZooKeeper的使用以及搭建ZooKeeper集群的文章，大家有需要可以自行查阅。一什么是ZooKeeperZooKeeper的由来下面这段内容摘自《从Paxos到Zookeeper》第四章第一节的某段内容，推荐大家阅读以下：Zookeeper最早起源于雅虎研究院的一个研究小组。在当时，研究人员发现，在雅虎内部很多大型系统基本都需要依赖一个类似的系统来进行分布式协调，但是这些系统往往都存在分布式单点问题。所以，雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架，以便让开发人员将精力集中在处理业务逻辑上。关于“ZooKeeper”这个项目的名字，其实也有一段趣闻。在立项初期，考虑到之前内部很多项目都是使用动物的名字来命名的（例如著名的Pig项目),雅虎的工程师希望给这个项目也取一个动物的名字。时任研究院的首席科学家RaghuRamakrishnan开玩笑地说：“在这样下去，我们这儿就变成动物园了！”此话一出，大家纷纷表示就叫动物园管理员吧一一一因为各个以动物命名的分布式组件放在一起，雅虎的整个分布式系统看上去就像一个大型的动物园了，而Zookeeper正好要用来进行分布式环境的协调一一于是，Zookeeper的名字也就由此诞生了。1.1ZooKeeper概览ZooKeeper是一个开源的分布式协调服务，ZooKeeper框架最初是在“Yahoo!"上构建的，用于以简单而稳健的方式访问他们的应用程序。后来，ApacheZooKeeper成为Hadoop，HBase和其他分布式框架使用的有组织服务的标准。例如，ApacheHBase使用ZooKeeper跟踪分布式数据的状态。ZooKeeper的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。原语：操作系统或计算机网络用语范畴。是由若干条指令组成的，用于完成一定功能的一个过程。具有不可分割性·即原语的执行必须是连续的，在执行过程中不允许被中断。ZooKeeper是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于ZooKeeper实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。Zookeeper一个最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心。服务生产者将自己提供的服务注册到Zookeeper中心，服务的消费者在进行服务调用的时候先到Zookeeper中查找服务，获取到服务生产者的详细信息之后，再去调用服务生产者的内容与数据。如下图所示，在Dubbo架构中Zookeeper就担任了注册中心这一角色。1.2结合个人使用情况的讲一下ZooKeeper在我自己做过的项目中，主要使用到了ZooKeeper作为Dubbo的注册中心(Dubbo官方推荐使用ZooKeeper注册中心)。另外在搭建solr集群的时候，我使用ZooKeeper作为solr集群的管理工具。这时，ZooKeeper主要提供下面几个功能：1、集群管理：容错、负载均衡。2、配置文件的集中管理3、集群的入口。我个人觉得在使用ZooKeeper的时候，最好是使用集群版的ZooKeeper而不是单机版的。官网给出的架构图就描述的是一个集群版的ZooKeeper。通常3台服务器就可以构成一个ZooKeeper集群了。为什么最好使用奇数台服务器构成ZooKeeper集群？我们知道在Zookeeper中Leader选举算法采用了Zab协议。Zab核心思想是当多数Server写成功，则任务数据写成功。①如果有3个Server，则最多允许1个Server挂掉。②如果有4个Server，则同样最多允许1个Server挂掉。既然3个或者4个Server，同样最多允许1个Server挂掉，那么它们的可靠性是一样的，所以选择奇数个ZooKeeperServer即可，这里选择3个Server。12341234二关于ZooKeeper的一些重要概念2.1重要概念总结●ZooKeeper本身就是一个分布式程序（只要半数以上节点存活，ZooKeeper就能正常服务）。●为了保证高可用，最好是以集群形态来部署ZooKeeper，这样只要集群中大部分机器是可用的（能够容忍一定的机器故障），那么ZooKeeper本身仍然是可用的。●ZooKeeper将数据保存在内存中，这也就保证了高吞吐量和低延迟（但是内存限制了能够存储的容量不太大，此限制也是保持znode中存储的数据量较小的进一步原因）。●ZooKeeper是高性能的。在“读”多于“写”的应用程序中尤其地高性能，因为“写”会导致所有的服务器间同步状态。（“读”多于“写”是协调服务的典型场景。）●ZooKeeper有临时节点的概念。当创建临时节点的客户端会话一直保持活动瞬时节点就一直存在。而当会话终结时，瞬时节点被删除。持久节点是指一旦这个ZNode被创建了，除非主动进行ZNode的移除操作，否则这个ZNode将一直保存在Zookeeper上。●ZooKeeper底层其实只提供了两个功能：①管理（存储、读取）用户程序提交的数据；②为用户程序提交数据节点监听服务。下面关于会话（Session）、Znode、版本、Watcher、ACL概念的总结都在《从Paxos到Zookeeper》第四章第一节以及第七章第八节有提到，感兴趣的可以看看！2.2会话（Session）Session指的是ZooKeeper服务器与客户端会话。在ZooKeeper中，一个客户端连接是指客户端和服务器之间的一个TCP长连接。客户端启动的时候，首先会与服务器建立一个TCP连接，从第一次连接建立开始，客户端会话的生命周期也开始了。通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能够向Zookeeper服务器发送请求并接受响应，同时还能够通过该连接接收来自服务器的Watch事件通知。Session的sessionTimeout值用来设置一个客户端会话的超时时间。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在sessionTimeout规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效。在为客户端创建会话之前，服务端首先会为每个客户端都分配一个sessionID。由于sessionID是Zookeeper会话的一个重要标识，许多与会话相关的运行机制都是基于这个sessionID的，因此，无论是哪台服务器为客户端分配的sessionID，都务必保证全局唯一。2.3Znode在谈到分布式的时候，我们通常说的“节点"是指组成集群的每一台机器。然而，在Zookeeper中，“节点"分为两类，第一类同样是指构成集群的机器，我们称之为机器节点；第二类则是指数据模型中的数据单元，我们称之为数据节点一一ZNode。Zookeeper将所有数据存储在内存中，数据模型是一棵树（ZnodeTree)，由斜杠（/）的进行分割的路径，就是一个Znode，例如/foo/path1。每个上都会保存自己的数据内容，同时还会保存一系列属性信息。在Zookeeper中，node可以分为持久节点和临时节点两类。所谓持久节点是指一旦这个ZNode被创建了，除非主动进行ZNode的移除操作，否则这个ZNode将一直保存在Zookeeper上。而临时节点就不一样了，它的生命周期和客户端会话绑定，一旦客户端会话失效，那么这个客户端创建的所有临时节点都会被移除。另外，ZooKeeper还允许用户为每个节点添加一个特殊的属性：SEQUENTIAL.一旦节点被标记上这个属性，那么在这个节点被创建的时候，Zookeeper会自动在其节点名后面追加上一个整型数字，这个整型数字是一个由父节点维护的自增数字。2.4版本在前面我们已经提到，Zookeeper的每个ZNode上都会存储数据，对应于每个ZNode，Zookeeper都会为其维护一个叫作Stat的数据结构，Stat中记录了这个ZNode的三个数据版本，分别是version（当前ZNode的版本）、cversion（当前ZNode子节点的版本）和cversion（当前ZNode的ACL版本）。2.5WatcherWatcher（事件监听器），是Zookeeper中的一个很重要的特性。Zookeeper允许用户在指定节点上注册一些Watcher，并且在一些特定事件触发的时候，ZooKeeper服务端会将事件通知到感兴趣的客户端上去，该机制是Zookeeper实现分布式协调服务的重要特性。2.6ACLZookeeper采用ACL（AccessControlLists）策略来进行权限控制，类似于UNIX文件系统的权限控制。Zookeeper定义了如下5种权限。其中尤其需要注意的是，CREATE和DELETE这两种权限都是针对子节点的权限控制。三ZooKeeper特点●顺序一致性：从同一客户端发起的事务请求，最终将会严格地按照顺序被应用到ZooKeeper中去。●原子性：所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用。●单一系统映像：无论客户端连到哪一个ZooKeeper服务器上，其看到的服务端数据模型都是一致的。●可靠性：一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖。四ZooKeeper设计目标4.1简单的数据模型ZooKeeper允许分布式进程通过共享的层次结构命名空间进行相互协调，这与标准文件系统类似。名称空间由ZooKeeper中的数据寄存器组成-称为znode，这些类似于文件和目录。与为存储设计的典型文件系统不同，ZooKeeper数据保存在内存中，这意味着ZooKeeper可以实现高吞吐量和低延迟。4.2可构建集群为了保证高可用，最好是以集群形态来部署ZooKeeper，这样只要集群中大部分机器是可用的（能够容忍一定的机器故障），那么zookeeper本身仍然是可用的。客户端在使用ZooKeeper时，需要知道集群机器列表，通过与集群中的某一台机器建立TCP连接来使用服务，客户端使用这个TCP链接来发送请求、获取结果、获取监听事件以及发送心跳包。如果这个连接异常断开了，客户端可以连接到另外的机器上。ZooKeeper官方提供的架构图：上图中每一个Server代表一个安装Zookeeper服务的服务器。组成ZooKeeper服务的服务器都会在内存中维护当前的服务器状态，并且每台服务器之间都互相保持着通信。集群间通过Zab协议（ZookeeperAtomicBroadcast）来保持数据的一致性。4.3顺序访问对于来自客户端的每个更新请求，ZooKeeper都会分配一个全局唯一的递增编号，这个编号反应了所有事务操作的先后顺序，应用程序可以使用ZooKeeper这个特性来实现更高层次的同步原语。这个编号也叫做时间戳——zxid（ZookeeperTransactionId）4.4高性能ZooKeeper是高性能的。在“读”多于“写”的应用程序中尤其地高性能，因为“写”会导致所有的服务器间同步状态。（“读”多于“写”是协调服务的典型场景。）五ZooKeeper集群角色介绍最典型集群模式：Master/Slave模式（主备模式）。在这种模式中，通常Master服务器作为主服务器提供写服务，其他的Slave服务器从服务器通过异步复制的方式获取Master服务器最新的数据提供读服务。但是，在ZooKeeper中没有选择传统的Master/Slave概念，而是引入了Leader、Follower和Observer三种角色。如下图所示ZooKeeper集群中的所有机器通过一个Leader选举过程来选定一台称为“Leader”的机器，Leader既可以为客户端提供写服务又能提供读服务。除了Leader外，Follower和Observer都只能提供读服务。Follower和Observer唯一的区别在于Observer机器不参与Leader的选举过程，也不参与写操作的“过半写成功”策略，因此Observer机器可以在不影响写性能的情况下提升集群的读性能。六ZooKeeper&ZAB协议&Paxos算法6.1ZAB协议&Paxos算法Paxos算法应该可以说是ZooKeeper的灵魂了。但是，ZooKeeper并没有完全采用Paxos算法，而是使用ZAB协议作为其保证数据一致性的核心算法。另外，在ZooKeeper的官方文档中也指出，ZAB协议并不像Paxos算法那样，是一种通用的分布式一致性算法，它是一种特别为Zookeeper设计的崩溃可恢复的原子消息广播算法。6.2ZAB协议介绍ZAB（ZooKeeperAtomicBroadcast原子广播）协议是为分布式协调服务ZooKeeper专门设计的一种支持崩溃恢复的原子广播协议。在ZooKeeper中，主要依赖ZAB协议来实现分布式数据一致性，基于该协议，ZooKeeper实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。6.3ZAB协议两种基本的模式：崩溃恢复和消息广播ZAB协议包括两种基本的模式，分别是崩溃恢复和消息广播。当整个服务框架在启动过程中，或是当Leader服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB协议就会进人恢复模式并选举产生新的Leader服务器。当选举产生了新的Leader服务器，同时集群中已经有过半的机器与该Leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式。其中，所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能够和Leader服务器的数据状态保持一致。当集群中已经有过半的Follower服务器完成了和Leader服务器的状态同步，那么整个服务框架就可以进人消息广播模式了。当一台同样遵守ZAB协议的服务器启动后加人到集群中时，如果此时集群中已经存在一个Leader服务器在负责进行消息广播，那么新加人的服务器就会自觉地进人数据恢复模式：找到Leader所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中去。正如上文介绍中所说的，ZooKeeper设计成只允许唯一的一个Leader服务器来进行事务请求的处理。Leader服务器在接收到客户端的事务请求后，会生成对应的事务提案并发起一轮广播协议；而如果集群中的其他机器接收到客户端的事务请求，那么这些非Leader服务器会首先将这个事务请求转发给Leader服务器。七总结通过阅读本文，想必大家已从①ZooKeeper的由来。->②ZooKeeper到底是什么。->③ZooKeeper的一些重要概念（会话（Session）、Znode、版本、Watcher、ACL）->④ZooKeeper的特点。->⑤ZooKeeper的设计目标。->⑥ZooKeeper集群角色介绍（Leader、Follower和Observer三种角色）->⑦ZooKeeper&ZAB协议&Paxos算法。这七点了解了ZooKeeper。',)