Zookeeper学习

什么是zookeeper

ZooKeeper是Hadoop Ecosystem中非常重要的组件，它的主要功能是为分布式系统提供一致性协调(Coordination)服务，与之对应的Google的类似服务叫Chubby。ZooKeeper以Fast Paxos算法为基础。

它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。

 

工作原理以及角色说明

Zookeeper的角色（如下图）：

• 领导者（leader）：负责进行投票的发起和决议，更新系统状态。
• 学习者（learner）：包括跟随者（follower）和观察者（observer）。
• Follower用于接受客户端请求并向客户端返回结果，在选主过程中参与投票。
• Observer可以接受客户端连接，将写请求转发给leader，但Observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度。
• 客户端（client）：请求发起方。

 

工作原理

ZooKeeper集群由一组Server节点组成，这一组Server节点中存在一个角色为Leader的节点，其他节点都为Follower。当客户端Client连接到ZooKeeper集群，并且执行写请求时，这些请求会被发送到Leader节点上，然后Leader节点上数据变更会同步到集群中其他的Follower节点。

Leader节点在接收到数据变更请求后，首先将变更写入本地磁盘，以作恢复之用。当所有的写请求持久化到磁盘以后，才会将变更应用到内存中。

ZooKeeper使用了一种自定义的原子消息协议，在消息层的这种原子特性，保证了整个协调系统中的节点数据或状态的一致性。Follower基于这种消息协议能够保证本地的ZooKeeper数据与Leader节点同步，然后基于本地的存储来独立地对外提供服务。

当一个Leader节点发生故障失效时，失败故障是快速响应的，消息层负责重新选择一个Leader，继续作为协调服务集群的中心，处理客户端写请求，并将ZooKeeper协调系统的数据变更同步（广播）到其他的Follower节点。

简化起来的流程如下：

1. 选举Leader。
2. 同步数据。
3. 选举Leader过程中算法有很多，但要达到的选举标准是一致的。
4. Leader要具有最高的Zookeeper 事务 id（zxid）
5. 集群中大多数的机器得到响应并follow选出的Leader。

 

zookeeper的重要概念

 

zookeeper数据模型

1. 每个节点在zookeeper中叫做znode，并且其有一个唯一的路径标识，如/SERVER2节点的标识就为/APP3/SERVER2
2. Znode可以有子znode，每个ZNode上可存储少量数据(默认是1M，可以通过配置修改， 通常不建议在ZNode上存储大量的数据)，但是EPHEMERAL类型的节点不能有子节点
3. Znode中的数据可以有多个版本，比如某一个路径下存有多个数据版本，那么查询这个路径下的数据就需要带上版本。
4. znode 可以是临时节点，一旦创建这个 znode 的客户端与服务器失去联系，这个 znode 也将自动删除，Zookeeper 的客户端和服务器通信采用长连接方式，每个客户端和 服务器通过心跳来保持连接，这个连接状态称为 session，如果 znode 是临时节点，这个 session 失效，znode 也就删除了
5. znode 的目录名可以自动编号，如 App1 已经存在，再创建的话，将会自动命名为 App2
6. znode 可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个功能是zookeeper对于应用最重要的特性，通过这个特性可以实现的功能包括配置的集中管理，集群管理，分布式锁等等。

 

Znode介绍

ZNode根据其本身的特性，可以分为下面两类：

1. Regular ZNode: 常规型ZNode, 用户需要显式的创建、删除
2. Ephemeral ZNode: 临时型ZNode， 用户创建它之后，可以显式的删除，也可以在创建它的Session结束后，由ZooKeeper Server自动删除。

 

Session

Client与ZooKeeper之间的通信，需要创建一个Session，这个Session会有一个超时时间。因为ZooKeeper集群会把Client的Session信息持久化，所以在Session没超时之前，Client与ZooKeeper Server的连接可以在各个ZooKeeper Server之间透明地移动。

在实际的应用中，如果Client与Server之间的通信足够频繁，Session的维护就不需要其它额外的消息了。否则，ZooKeeper Client会每t/3 ms发一次心跳给Server，如果Client 2t/3 ms没收到来自Server的心跳回应，就会换到一个新的ZooKeeper Server上。这里t是用户配置的Session的超时时间

 

Watcher

ZooKeeper 允许客户端向服务端注册一个 Watcher 监听，当服务端的一些指定事件触发了这个 Watcher，那么就会向指定客户端发送一个事件通知来实现分布式的通知功能。

ZooKeeper 的 Watcher 机制主要包括客户端线程、客户端 WatchManager 和 ZooKeeper 服务器三部分。

在具体工作流程上，简单地讲，客户端在向 ZooKeeper 服务器注册 Watcher 的同时，会将 Watcher 对象存储在客户端的 WatchManager 中。当 ZooKeeper 服务器端触发 Watcher 事件后，会向客户端发送通知，客户端线程从 WatchManager 中取出对应的 Watcher 对象来执行回调逻辑。

下图为简图

 

Zookeeper特性

 

读、写(更新)模式

在ZooKeeper集群中，读可以从任意一个ZooKeeper Server读，这一点是保证ZooKeeper比较好的读性能的关键；写的请求会先Forwarder到Leader，然后由Leader来通过ZooKeeper中的原子广播协议，将请求广播给所有的Follower，Leader收到一半以上的写成功的Ack后，就认为该写成功了，就会将该写进行持久化，并告诉客户端写成功了。

 

WAL和Snapshot（预写日志与快照）

和大多数分布式系统一样，ZooKeeper也有WAL(Write-Ahead-Log)，对于每一个更新操作，ZooKeeper都会先写WAL, 然后再对内存中的数据做更新，然后向Client通知更新结果。另外，ZooKeeper还会定期将内存中的目录树进行Snapshot，落地到磁盘上，这个跟HDFS中的FSImage是比较类似的。这么做的主要目的，一当然是数据的持久化，二是加快重启之后的恢复速度，如果全部通过Replay WAL的形式恢复的话，会比较慢。

• WAL的核心思想是:在数据写入到数据库之前，先写入到日志.再将日志记录变更到存储器中。

 

FIFO

对于每一个ZooKeeper客户端而言，所有的操作都是遵循FIFO顺序的，这一特性是由下面两个基本特性来保证的：

1. ZooKeeper Client与Server之间的网络通信是基于TCP，TCP保证了Client/Server之间传输包的顺序；
2. ZooKeeper Server执行客户端请求也是严格按照FIFO顺序的。

 

Linearizability

在ZooKeeper中，所有的更新操作都有严格的偏序关系，更新操作都是串行执行的，这一点是保证ZooKeeper功能正确性的关键。

ZooKeeper使用时间戳来记录导致状态变更的事务性操作，也就是说，一组事务通过时间戳来保证有序性。基于这一特性。ZooKeeper可以实现更加高级的抽象操作，如同步等。

 

Leader选举流程

每个Server启动以后都询问其它的Server它要投票给谁。

对于其他Server的询问，server每次根据自己的状态都回复自己推荐的leader的id和上一次处理事务的zxid（系统启动时每个server都会推荐自己）

收到所有Server回复以后，就计算出zxid最大的哪个Server，并将这个Server相关信息设置成下一次要投票的Server。

计算这过程中获得票数最多的的sever为获胜者，如果获胜者的票数超过半数，则改server被选为leader。否则，继续这个过程，直到leader被选举出来。

leader就会开始等待server连接。

Follower连接leader，将最大的zxid发送给leader。

Leader根据follower的zxid确定同步点。

完成同步后通知follower 已经成为uptodate状态。

Follower收到uptodate消息后，又可以重新接受client的请求进行服务了。

 

应用场景

1. 统一命名服务 
   分布式应用中，通常需要有一套完整的命名规则，既能够产生唯一的名称又便于人识别和记住，通常情况下用树形的名称结构是一个理想的选择，树形的名称结构是一个有层次的目录结构，既对人友好又不会重复。 
   Name Service 是 Zookeeper 内置的功能，只要调用 Zookeeper 的 API 就能实现。

2. 配置管理 
   配置的管理在分布式应用环境中很常见，例如同一个应用系统需要多台 PC Server 运行，但是它们运行的应用系统的某些配置项是相同的，如果要修改这些相同的配置项，那么就必须同时修改每台运行这个应用系统的 PC Server，这样非常麻烦而且容易出错。 
   将配置信息保存在 Zookeeper 的某个目录节点中，然后将所有需要修改的应用机器监控配置信息的状态，一旦配置信息发生变化，每台应用机器就会收到 Zookeeper 的通知，然后从 Zookeeper 获取新的配置信息应用到系统中。

3. 集群管理 
   Zookeeper 能够很容易的实现集群管理的功能，如有多台 Server 组成一个服务集群，那么必须要一个“总管”知道当前集群中每台机器的服务状态，一旦有机器不能提供服务，集群中其它机器必须知道，从而做出调整重新分配服务策略。同样当增加集群的服务能力时，就会增加一台或多台 Server，同样也必须让“总管”知道。 
   Zookeeper 不仅能够维护当前的集群中机器的服务状态，而且能够选出一个“总管”，让这个总管来管理集群，这就是 Zookeeper 的另一个功能 Leader Election。

4. 共享锁 
   共享锁在同一个进程中很容易实现，但是在跨进程或者在不同 Server 之间就不好实现了。 
   Zookeeper 却很容易实现这个功能。 
   实现方式也是需要获得锁的 Server 创建一个 EPHEMERAL_SEQUENTIAL 目录节点， 
   然后调用getChildren方法获取当前的目录节点列表中最小的目录节点是不是就是自己创建的目录节点， 
   如果正是自己创建的，那么它就获得了这个锁， 
   如果不是那么它就调用 exists(String path, boolean watch) 方法并监控 Zookeeper 上目录节点列表的变化， 
   一直到自己创建的节点是列表中最小编号的目录节点，从而获得锁， 
   释放锁很简单，只要删除前面它自己所创建的目录节点就行了。

5. 队列管理 
   Zookeeper 可以处理两种类型的队列。 
   1、当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达，这种是同步队列； 
   2、分布式FIFO队列按照 FIFO 方式进行入队和出队操作。

   例如实现生产者和消费者模型 
   创建一个父目录 /synchronizing， 
   每个成员都监控目录 /synchronizing/start 是否存在， 
   然后每个成员都加入这个队列（创建 /synchronizing/member_i 的临时目录节点）， 
   然后每个成员获取 / synchronizing 目录的所有目录节点， 
   判断 i 的值是否已经是成员的个数， 
   如果小于成员个数，等待 /synchronizing/start 的出现， 
   如果已经相等就创建 /synchronizing/start。

 

总结

Zookeeper可以用来保证数据在Zookeeper集群之间的数据的事务性一致。 
Zookeeper 作为 Hadoop 项目中的一个子项目，是 Hadoop 集群管理的一个必不可少的模块，它主要用来控制集群中的数据，如它管理 Hadoop 集群中的 NameNode，还有 Hbase 中 Master Election、Server 之间状态同步等。 
Zoopkeeper 提供了一套很好的分布式集群管理的机制，就是它这种基于层次型的目录树的数据结构，并对树中的节点进行有效管理，从而可以设计出多种多样的分布式的数据管理模型。

+

---恢复内容结束---