1、Zookeeper初步调研报告Zookeeper 初步调研报告【摘要】 Zookeeper是参考Google Chubby实现原理设计实现的一个分布式应用协调系统。Zookeeper的原型系统由Yahoo!开发，目前，由Apache基金会维护，为Hadoop项目的子项目。本文主要通过分析Chubby，Zookeeper项目的相关文档，总结和分析了Zookeeper的特点，能使用Zookeeper实现的高级分布式应用场景，以及用Zookeeper实现的分布式协调功能帮助社区产品线解决的一些分布式问题。本文还讨论了社区Space组的UDAM资源定位系统与Zookeeper比较的一些不同之处。1 G
2、oogle Chubby 分布式锁服务是现代分布式系统的重要基础之一。简单的说，分布式锁服务实现了在一个分布式的环境下实现了单机版锁服务的功能。在分布式环境下，锁服务锁定的资源对象通常不是单个线程，或者进程，而是单个或者多个客户端。Google对分布式锁服务的定义是：分布式锁服务的目标是让客户端的行为得到同步，并使他们关于环境的一些基础信息达到统一。由于是分布式系统的组成部分，分布式锁的首要设计目标包括：可靠性、对于大规模客户端的可用性、以及简单，且易于理解的语义。锁服务的吞吐率和存储能力则是其他需要重点考虑的问题。值得注意的一点是，与这几个重要的目标相比，分布式系统的性能并不是一个需要优先考
3、虑的问题。 Chubby是Google开发的分布式锁系统，目前，在Bigtable(Google的分布式存储系统)和MapReduce(Google的分布式计算平台)中都应用了Chubby提供的分布式锁服务，以保证分布式的同步和并发。在参考文献1中提到，Chubby被用于解决以下问题：a)帮助工程师实现服务的高可用性。b)为需要主从选择，数据划分的服务提供选择机制和通告方式(advertising the results)。c)基于锁的使用接口(lock-based interface)容易理解d)分布式一致性算法利用投票的方式来做出决定，并利用镜像冗余获得高可用性Chubby的设计实现基于以
4、下的考虑：a)一个服务通过一个Chubby文件发布服务的基础信息，而这个服务可能被成千上万的客户端所依赖。这就要求在服务器尽可能少的条件下，有效支持这些客户端对该文件的访问。b)多服务器冗余环境下，从属服务器需要知道主服务器的更新状况，这就需要通知机制来避免轮询，以提高效率c)需要有cache机制来缓存查询结果，以防止多余重复访问d)需要有权限控制来保证数据访问的安全1.1系统构架Chubby主要由两个通过PRC通讯的部分组成：服务器，与应用相连的客户端库。每个Chubby组群(Cell)都包含一组保持相同数据的Chubby服务器，被称为replicas。每个组群利用分布式一致性协议(dist
5、ributed consensus protocol, 如：Paxos2)来选择一个主服务器(master)，并且在一个主服务器租期(master lease)内，组群不会再选择新的主服务器。组群中的所有服务器都有一个数据库的备份，但只有主服务器能发起读和写的响应，其他服务器只利用分布式一致性协议从主服务器获得更新。客户端通过DNS服务器获得组群中主服务器的地址。当客户端确定了主服务器后，就将所有请求发送到主服务器，直到主服务器不再响应，或者该服务器返回它已经不再是主服务器为止。主服务器将客户端写请求转发给其他服务器，只有当组群中大多数服务器更新成功后，该写请求才被确认。读请求完全由主服务器响
6、应。当主服务器死机，或者主服务器租期结束时，组群能在1分钟之内选出新的主服务器（一般来说，这个过程只花费几秒钟时间）。当服务器失效后，若数小时不能恢复服务，则系统自动从备机池中启用备机保证组群机器数目。图一、Chubby系统构架1.2 系统细节Chubby采用类似于UNIX文件系统的方式管理系统中的相关文件，如一个典型的文件路径: /ls/foo/wombat/pouch。其中ls是Chubby系统常用的前缀，代表Lock Service；foo是Chubby集群的名字。/wombat/pouch则标识了Chubby的具体服务。Chubby如此的树状层次结构安排主要是为了方便文件系统（如Goo
7、gle File System）的访问。但与UNIX文件系统不同的是，Chubby中文件的访问权限完全取决于文件本身定义的访问权限，与它所在上层目录的访问权限无关。Chubby中的文件和文件夹，也被称为节点(node)，有“永久节点”和“暂时性节点”之分。任何类型的节点都能被删除，“暂时性节点”还可以在无客户端连接时自动删除。每个节点都能作为一个读写锁被使用。节点的元数据信息中，包含ACL(Access Control Links)信息，当节点被创建时，若不指定其访问权限，则节点自动继承上级目录的访问权限。每次RPC访问时，系统会自动根据ACL信息确定客户端的访问合法性。节点的元数据中，还包含
8、4个严格增长的64位整数：名称描述实体编号比上一个与此节点同名的节点的该编号大内容编号当文件内容发生改变时增长锁编号当锁状态从释放变为持有时增长ACL编号当节点的ACL信息被修改时增长Chubby中的任何文件都可以作为锁被客户端持有（以互斥锁，或者读写锁的模式），但无论以何种方式持有锁都要求客户端对该节点有写权限，如果客户端只对某个节点有读权限，它无法阻止有权限的客户端对节点进行写操作。分布式环境中的锁是非常复杂的，因为各个实体间的网络交互情况是不确定的。可能出现的情况是客户端A获得了锁L，当它发送请求R时，网络发生故障。此时客户端B又获得了锁L，并进行了某些操作，这时，如果R请求到达的话，它
9、并不是一个受到锁L保护的操作。解决这个问题的关键在于，服务器在处理请求时必须严格按照事件发生的顺序。由于对于每次交互都加序列号的实现方式代价太大，Chubby只对需要锁的操作记录序列号：客户端在取得了锁之后，会马上向服务器请求一个序列号和锁状态。当客户发起操作请求时，服务器会验证客户端带的序列号和锁状态是否有效，如果已经失效，则操作被拒绝。即便如此，也不是所有协议都可以加上序列号，所以Chubby还保存了一种不完美，但比较有效的方法：锁延时(lock-delay)。当客户端主动释放锁时，其他客户端可以马上获得该锁。但如果是因为客户端失效或者通信失败的话。其他客户端将在一定时间内（即，锁延时时间
10、内）不能获得该锁。Chubby具有依据事件的异步唤醒机制，支持的事件包括：a)文件内容被修改。该事件通常被用来监视服务描述（即，资源定位）文件b)子节点的增加、删除、或者修改操作c)Chubby主服务器失效。接收到该事件表明，某些交互信息可能已经丢失d)锁被获得。这个事件可以被用于判断某服务器是否被选为主服务器e)其他客户端发来的锁冲突请求Chubby实现了以下的API：接口名描述Open()根据文件名获得文件句柄，与UNIX类似。客户端需要传递如下信息：a)这个句柄的使用方式（读、写、锁定，或者修改访问权限），只有在使用方式符合客户端权限的时候，打开句柄才能成功。b)客户端接收的事件类型c)
11、锁延时(lock-delay)长度d)是否需要创建新文件或者新目录，如果需要则需要传递初始化信息Close()关闭文件句柄Poison()不关闭文件句柄，但任何关于该句柄的操作都会失败GetContentsAndStat()获得文件（节点）数据和元数据GetStat()获得文件（节点）元数据ReadDir()获得文件夹中子节点名和他们的元数据SetContents()写文件内容。客户端需要提供当前数据编号，如果编号错误，则失败SetACL()设置文件（节点）ACL信息Delete()删除一个无子节点的节点Acquire()请求锁TryAcquire()尝试请求锁Release()释放锁GetS
12、equencer()返回一个与该句柄持有锁相关的序列号SetSequencer()将一个序列号与句柄相关联 客户端利用Chubby选主的过程即可利用以上的API实现：所有候选客户端同时打开同一个文件句柄，并竞争它的锁，获得锁的客户端将自身信息写入该文件，以便让其他客户端知道自己已经成为主客户端。另一方面，为了减轻网络交互的压力，Chubby的客户端库还实现了cache。客户端库接收服务器发送的失效通知来使客户端内存中的数据失效。当Chubby服务器上的数据和元数据被修改的时候，主服务器会发失效通知给可能cache了这些数据的客户端，这一机制是建立在KeepAlives机制之上，并依赖租约机制。
13、它保证了客户端看到的服务器是一致的，或者是失效的。注意，此处Chubby服务器仅仅是让客户端的cache失效，而没有不是更新客户端的cache，这是由于在分布式情况下让cache失效远比直接更新cache要有效率。Chubby中定义的会话（Session）指的是Chubby组群和客户端之间的一种连接关系，这种关系存在于一定时间段内，并由一种周期性进行的handshake所维护，这种握手被称为KeepAlives。除非客户端通知Chubby组群中止会话，客户端关于Chubby句柄的任何操作都会使会话保持有效。客户端在第一次连接Chubby主服务器的时候建立会话，当会话被外部中止，或者空闲的时候，
14、会话结束。每个会话都由一个租期（lease）相关联，Chubby服务器保证在租期时间内，服务器端不会关闭会话。服务器有权限延长与客户端的会话租期时间，但不能将其缩短。 服务器通过KeepAlives的回复可以延长客户端租期的时间。此外，KeepAlives回复还被用于传递Chubby服务器事件和cache失效信息给客户端。当服务器有信息传递给客户端时，KeepAlives回复将会早一些返回。而KeepAlives回复中的Piggybacking事件保证了客户端不能在没有做cache失效确认的情况下维持会话有效。这样的机制简化了客户端，并且方便穿透只能单向发起请求的防火墙。当一个客户端租期到期的
15、时候，客户端无法判断是否是服务器中止了会话，此时客户端会清空本地cache，进入Jeopardy状态，并等待一段时间(the grace period)。如果在这段时间中，Chubby服务器能成功的完成KeepAlives交互，则客户端重新使其cache有效。否则客户端认为会话已经失效。这保证了客户端的调用不会在Chubby组群失效时永久阻塞。当grace period开始的时候，Chubby客户端库保证客户端会收到Jeopardy事件，如果，KeepAlives能成功完成，则客户端会收到safe事件，否则，则收到expired事件。 当Chubby主服务器发生变更时，新的Chubby主服务器
16、会做以下一些工作：a)首先选择一个新的时期编号(epoch number)，客户端的每个请求都需要带这个编号。这样可以保证当前的Chubby主服务器不会处理以及过时的（发给以前主服务器的）请求。b)新的主服务器也可以响应定位主服务器的请求c)新的主服务器在内存中创建被用于会话和锁等信息的结构体，并保存在数据库中。并且将会话租期调整到前一主服务器允许的最大租期长度d)此时，新的主服务器已经可以接受KeepAlives请求，但不能处理会话相关的操作。e)新的主服务器发送服务器失效事件给每个连接客户端，并通知它们清除cache，因为某些事件可能已经被丢失。f)新的主服务器等待所有连接客户端确认服务器
17、失效事件，并让会话过期g)如果客户端使用过期的句柄连接服务器，则新的主服务器重新在内存中建立该句柄的标识方式，并相应请求。但如果该句柄被关闭，则新的主服务器保证，在其服务期间，该句柄不能再次被使用，这保证了网络延时不会造成已关闭的句柄重新打开。h)新的主服务器在启动一段时间后会关闭没有客户端链接的暂时性节点，所以客户端在收到主机主机失效的事件后，应该刷新暂时性节点。关于数据存储和备份方面，Chubby一开始使用Berkeley DB的key-value存储方式储存节点数据和元数据，并每隔几个小时就将数据库快照备份到异地的GFS文件服务器上。这样的备份机制完全可以保证数据恢复，或者重建新备机数据
18、的要求。镜像功能方面，由于Chubby文件的实现方式，简单的文件拷贝就能实现镜像功能。2 Zookeeper 正如前文所说，Zookeeper的设计和实现参考了Chubby的设计原理。如，Zookeeper也使用了类似于文件系统的树状名字空间，也用ACL控制访问权限，也有事件触发机制等。但Zookeeper实现的功能可以认为是Chubby实现功能的一个子集。以下将总结和分析Zookeeper实现的功能，并与Chubby以及Space组的UDAM系统的功能做一个比较。2.1 Zookeeper数据模型Zookeeper使用类似于分布式文件系统的树状命名空间。不同的是，在Zookeeper中只使用
19、绝对路径，没有相对路径。对于命名空间中的每一个节点，都有与之相关的数据和子节点。（分析：此处Zookeeper的资源表示方式与Chubby是一致，以路径名的方式来表示资源的逻辑关系。UDAM也采用树状的方式标识资源）。2.1.1 数据节点（ZNodes）Zookeeper树状结构上的节点被称为znode。每个znode维护一个stat数据结构，它包括了数据的版本号，访问控制链的版本号，时间戳等。每次znode的数据发生变化时，数据版本号都会增长。当客户端发起一个节点的删除或者更新操作时，必须携带该数据节点当前的版本号，若版本号不正确，则操作将会失败。（分析：与Chubby不同的一点是，Zook
20、eeper的节点并没有天然的锁属性，不能对节点进行直接的加锁和解锁操作。但锁的实现通过Zookeeper实现的另一个特性得到弥补，即，顺序节点。本文后面会解释如何使用序列节点实现分布式锁功能。另一方面，与Chubby一致的一点是，节点有与之关联的数据和元数据。数据的格式自由，有很好的扩展性。在这方面，UDAM目前实现的是子系统级别的资源实体定位，数据可扩展性方面较弱）2.1.1 监视机制（Watch）Zookeeper客户端在数据节点上设置监视，则当数据节点发生变化时，客户端会收到提醒。详细分析见本文下面的内容。2.1.2 数据访问（Data Access）对于Zookeeper数据节点的数据
21、读写是Zookeeper自动完成的，并以单个节点为粒度，即，读操作读出与数据节点相关联的所有数据，写则替换该节点上的所有数据。每个节点上的“访问控制链”(ACL, Access Control List)保存了各客户端对于该节点的访问权限。（分析：ACL的访问权限控制思想与Chubby一致。Zookeeper对与用户类别的区分，不只局限于所有者、组、以及所有人三个级别。Zookeeper支持对访问的区分有更加细的粒度。UDAM使用ip名单的方式控制，防止线下的模块使用线上的资源。但没有粒度更小的权限控制。对于目前NS应用来说，UDAM的实现已经够用，但Zookeeper这方面功能更加完善）2.
22、1.3 暂时性节点（Ephemeral Nodes） Zookeeper有个暂时性节点机制，即，暂时性节点仅在单个会话（session）中，当会话结束时，节点便销毁了。这个特性决定了这类节点不能有子节点。（分析：从Zookeeper文档描述分析，暂时性节点是对应于模块级资源的合适选择。当模块失效时，节点销毁。）2.1.4 顺序节点（Sequence Nodes） 顺序节点用于保证新创建的节点中所带的编号一定大于某个已有节点的编号。（分析：Chubby中没有顺序节点的概念，Zookeeper使用顺序节点来实现分布式锁的功能）2.2 Zookeeper 中的时间： Zxid: Zookeeper
23、事务ID，由zxid来标识Zookeeper状态的每一个变化，zxid按照产生的时间顺序递增。 节点版本号：数据节点的每一个变化将改变节点的一个版本号。三个节点版本号包括：版本（数据节点变化的次数）、子节点版本（子节点变化的次数）、访问控制链版本（访问控制链变化的次数） Ticks：在多服务器的Zookeeper服务中，时间的时间用ticks来描述。当客户端要求一个比最小会话失效时间更小的超时时间时，最小会话失效时间将会被使用。2.3 stat 结构体字段名含义Czxid该znode创建时的zxidMzxid该znode最后一次修改时的zxidCtime该znode创建时的时间Mtime该zn
24、ode最后一次修改的时间Version该znode的变化次数Cversion该znode的子节点变化次数Aversion该znode的acl变化次数EphemeralOwner如果是个暂时性节点，则记录拥有该znode的会话id，否则为0DataLength该znode数据长度NumChildren该znode子节点个数2.4 Zookeeper会话客户端保存了所有Zookeeper服务器列表，并在发起服务请求时随机选择服务器。当客户端向Zookeeper发起服务请求时，Zookeeper会创建一个Zookeeper会话，并产生一个64位数值的会话ID。如果客户端连接其他Zookeeper服务
25、器，则会把这个会话ID作为握手的一个参数。为了保证数据传输安全，与会话ID相关联的一个密码会发送给客户端。会话ID与密码的关联关系，集群中的任何一台Zookeeper服务器都可以验证。（分析：该机制不仅保证了数据传输的安全性，也保证了，当某台Zookeeper服务器停机时，客户端能够毫无障碍地连接新的Zookeeper服务器以获得持续的会话服务） 客户端与服务器建立连接时的参数包括：a)超时设置（以ms为单位），目前要求这个超时时间至少是tickTime的两倍b)默认监视器，当客户端的数据发生变化的时候，该监视器将被通知。监视器的初始状态是“连接断开”，所以发起连接请求时，监视器收到的第一的事
26、件是连接建立。（分析：UDAM利用报文建立客户端与资源中心服务器的连接，交互过程如下：a)客户端发送报文给UDAM资源服务器b)UDAM资源服务器与客户端建立TCP连接，并将所有资源服务器信息发送给客户端，注意，此处UDAM会将最新的资源中心列表发送给客户端。但Zookeeper的资源服务器列表依赖于自身配置。c)客户端发送自己拥有的资源和依赖的资源信息d)资源服务器发送客户端所依赖的资源信息，连接建立） Zookeeper的会话保持机制通过客户端发送的请求来维持，如果客户端一段时间没有发送请求，则客户端会发送PING请求来保持会话。这个心跳机制也保证了服务器端了解客户端的生存状态。（分析：U
27、DAM没有使用Session id作为连接标识，它使用客户端发送的报文来行使心跳的功能。由于报文是以UDP的方式发送的，在服务器端超时未收到报文的时候，资源服务器会发起TCP连接，以保证客户端的报文不是由于UDP丢包而导致。 此处Chubby的实现方式不一样，Chubby利用KeepAlives来保持会话，但它利用KeepAlives返回包传递服务器事件等信息。Zookeeper没有使用ping返回包携带数据信息，但也是靠客户端发起获取资源的请求。这两种方式对于穿透单向防火墙有帮助。UDAM客户端需要监听特定端口来捕获资源服务器发起的连接。）当连接成功建立以后，有两种情况可以导致客户端产生失去
28、连接错误。a)对于一个已失效（不合法）的会话的操作b)客户端与Zookeeper服务器断开连接，但仍有未完成的异步请求。2.5 Zookeeper监视机制 Zookeeper中的各种读请求，如getDate()，getChildren()，和exists()，都可以选择加“监视点”(watch)。“监视点”指的是一种一次性的触发器(trigger)，当受监视的数据发生变化时，该触发器会通知客户端。 监视机制有三个关键点：a)“监视点”是一次性的，当触发过一次之后，除非重新设置，新的数据变化不会提醒客户端。b)“监视点”将数据改变的通知客户端。如果数据改变是客户端A引起的，不能保证“监视点”通知
29、事件会在引发数据修改的函数返回前到达客户端A。对于“监视点”，Zookeeper有如下保证：客户端一定是在接收到“监视”事件（watch event）之后才接收到数据的改变信息。c)getData() 和exists()设置关于节点数据的“监视点”，并返回节点数据信息；getChildren()设置关于子节点的“监视点”，并返回子节点信息。setData()会触发关于节点数据的“监视点”。成功的create()会触发所建立节点的数据“监视点”，和父节点的子节点“监视点”。成功的delete()会触发所删除节点的数据“监视点”，和父节点的子节点“监视点”。“监视点”保留在Zookeeper服务器
30、上，则当客户端连接到新的Zookeeper服务器上时，所有需要被触发的相关“监视点”都会被触发。当客户端断线后重连，与它的相关的“监视点”都会自动重新注册，这对客户端来说是透明的。在以下情况，“监视点”会被错过：客户端B设置了关于节点A存在性的“监视点”，但B断线了，在B断线过程中节点A被创建又被删除。此时，B再连线后不知道A节点曾经被创建过。（分析：UDAM的资源修改提醒机制实现逻辑如下：a)模块A在修改后重启时利用报文通知UDAM资源中心b)资源中心确认并与模块A进行数据交互c)资源中心将所有依赖于模块A的资源标记为不可用，有一个单独的定时线程扫描所有资源，并与这些不可用资源通信，以达到更
31、新数据的目的。）Zookeeper的“监视”机制保证以下几点：a)“监视”事件的触发顺序和分发顺序与事件触发的顺序一致。b)客户端将先接收到“监视”事件，然后才收到新的数据c)“监视”事件触发的顺序与Zookeeper服务器上数据变化的顺序一致关于Zookeeper“监视”机制的注意点：a)“监视点”是一次性的b)由于“监视点”是一次性的，而且，从接收到“监视”事件到设置新“监视点”是有延时的，所以客户端可能监控不到数据的所有变化c)一个监控对象，只会被相关的通知触发一次。如，一个客户端设置了关于某个数据点exists和getData的监控，则当该数据被删除的时候，只会触发“文件被删除”的通知
32、。d)当客户端断开与服务器的连接时，客户端不再能收到“监视”事件，直到重新获得连接。所以关于Session的信息将被发送给所有Zookeeper服务器。由于当连接断开时收不到“监视”时间，所以在这种情况下，模块行为需要容错方面的设计。2.6 Zookeeper基于ACL的访问控制机制 Zookeeper利用访问控制链机制（Access Control List）控制客户端访问数据节点的权限，类似于UNIX文件的访问控制。但Zookeeper对于用户类别的区分，不止局限于所有者(owner)、组(group)、所有人(world)三个级别。Zookeeper中，数据节点没有“所有者”的概念。访问者利用id标识自己的身份，并获得与之相应的不同的访问权限。 Zook
