Zookeeper分析

Zookeeper分析

1.  Zookeeper是什么？

Zookeeper是一个精简的文件系统，提供一些简单操作和一些额外抽象操作（排序和通知）;

Zookeeper运行在集群上;

Zookeeper核心设计模式：观察者模式；

Zookeeper核心协议：Zab协议（类似Paxos协议）；

Zookeeper提供一组工具，使你在构建分布式应用时能够对部分失败（分布式系统固有特征）进行正确处理；

 

Zookeeper的特点：

Ø 最终一致性：为客户端展示同一视图，这是zookeeper最重要的功能。

Ø 可靠性：如果消息被到一台服务器接受，那么它将被所有的服务器接受。

Ø 实时性：Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。

Ø 等待无关（wait-free）：慢的或者失效的client不干预快速的client的请求。

Ø 原子性：更新只能成功或者失败，没有中间状态。

Ø 顺序性：所有Server，同一消息发布顺序一致。

2.  Zookeeper能做什么？

1.1     统一命名服务

Ø  分布式环境下，经常需要对应用/服务进行统一命名，便于识别不同服务；

ü  类似于域名与ip之间对应关系，域名容易记住；

ü  通过名称来获取资源或服务的地址，提供者等信息

Ø  按照层次结构组织服务/应用名称

Ø  可将服务名称以及地址信息写到Zookeeper上，客户端通过Zookeeper获取可用服务列表类

1.2     配置管理

Ø  分布式环境下，配置文件管理和同步时一个常见问题；

ü  一个集群中，所有节点的配置信息是一致的，比如Hadoop；

ü  对配置文件修改后，希望能够快速同步到各个节点上；

Ø  配置管理可交由Zookeeper实现；

ü  可将配置信息写入Zookeeper的一个znode上；

ü  各个节点监听这个znode；

ü  一旦znode中的数据被修改，zookeeper将通知各个节点；

1.3     集群管理

Ø  分布式环境中，实时掌握每个节点的状态时必要的；

ü  可根据节点实时状态做出一些调整；

Ø  可交由Zookeeper实现

ü  可将节点信息写入Zookeeper的一个znode中；

ü  监听这个znode可获取它的实时状态变化；

Ø  典型应用

ü  Hbase中Master状态监控与选举；

1.4     分布式通知/协调

Ø  分布式环境中，经常存在一个服务需要知道它所管理的子服务的状态；

ü  NameNode须知道各DataNode的状态

ü  JobTracker须知道各TaskTracker的状态

Ø  心跳检测机制可通过Zookeeper实现

Ø  信息推送可由Zookeeper实现（发布/订阅模式）

1.5     分布式锁

Ø  Zookeeper是强一致的；

ü  多个客户端同时在Zookeeper上创建相同znode，只有一个创建成功。

Ø  实现锁的独占性

ü  多个客户端同时在Zookeeper上创建相同znode ，创建成功的那个客户端得到锁，其他客户端等待。

Ø  控制锁的时序

ü  各个客户端在某个znode下创建临时znode （类型为CreateMode.EPHEMERAL_SEQUENTIAL），这样，该znode可掌握全局访问时序。

1.6     分布式队列

Ø  两种队列；

ü  当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达，这种是同步队列。

ü  队列按照FIFO 方式进行入队和出队操作，例如实现生产者和消费者模型。（可通过分布式锁实现）

Ø  同步队列

ü  一个job由多个task组成，只有所有任务完成后，job才运行完成。

ü  可为job创建一个/job目录，然后在该目录下，为每个完成的task创建一个临时znode，一旦临时节点数目达到task总数，则job运行完成。

3.  Zookeeper怎么做？  

3.1     Zookeeper文件系统结构

Ø  这个文件系统没有文件和目录，而是统一使用“节点”（node）的概念，称为znode，znode既可以作为保存数据的容器（如同文件），也可以作为保存其他znode的容器（如同目录）；

Ø  所有znode构成一个层次化的命名空间；

Ø  znode最多可保存1MB的数据；

Ø  znode分为两种：短暂znode和持久znode；

Ø  会话过期，短暂znode会被删除；

Ø  短暂znode不能有子节点；

Ø  可以在znode上设置监视器，当znode状态发生变化，会通过监视器告知客户端；

3.2     Zookeeper架构

Ø  在生产环境中，Zookeeper通常以“复制模式”运行在一个计算机集群上，这个集群被称为一个“集合体”；

Ø  “复制模式”实际通过Zab协议实现，该协议包含两个可以无限重复的阶段；

ü  阶段一：领导者选举（通过分布式锁完成）

集合体中的所有机器通过一个选择过程来选出一台被称为"领导者" (leader)的机器，其他的机器被称为"跟随者" (follower) 。一旦半数以上(或指定数量)的跟随者已经将其状态与领导者同步，则表明这个阶段已经完成。

ü  阶段二：原子广播

所有的写请求都被转发给领导者，再由领导者将更新广播给跟随者。当半数以上的跟随者已经将修改持久化之后，领导者才会提交这个更新，然后客户端才会收到一个更新成功的晌应。这个用来达成共识的协议被设计成具有原子性，因此每个修改要么成功要么失败。这类似于数据库中的两阶段提交协议。

Ø  ZooKeeper的Zab协议不同于众所周知的Paxos算法，Google的Chubby锁服务是基于Paxos算法的；

3.3     Zookeeper为了适应“复制模式”，集群数量最好是奇数；

4     其它

Ø  Zookeeper作为分布式系统的一个组件，为分布式系统提供高可用性（HA）；

Ø  HDFS使用Zookeeper实现主备Namenode的切换（通过Zookeeper提供的分布式锁机制）；

Ø  MapReduceon YARN的ResourceManager还存在单点故障，正在基于Zookeeper实现的；

Ø  Yahoo开发的Bookkeeper和Cloudera开发的开源软件Qurom Journal Manager（QJM）与Zookeeper的内部机制一样，都是用来保证分布式系统的高可用性（HA）；