Zookeeper Introduction

问题思考

对于 hadoop 生态系统来讲,有几个问题须要经过分布式协调服务来解决:

1. 高可用性的主节点选举。对于集群各服务,如 HDFS、YARN、HBASE、SPARK 等如何保证同一时间只有一个主节点对外提供服务。
2. YARN 中 ResourceManager 失败后如何恢复执行任务的必要信息:Application 状态信息,Application 对应的 ApplicationAttempt 信息,以及一些相关的安全令牌信息。
3. Hive 数据仓库中 SQL 查询的并发锁问题。

所以,诞生了一个针对分布式系统的可靠协调系统,即 Zookeeper。

 

简介

Zookeeper 是一个针对大型分布式系统的可靠协调系统,提供的功能包括:配置维护、名字服务、分布式同步、组服务等。

ZooKeeper 的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。相关例子包括:分布式队列、分布式锁和一些节点的“领导者选举”。

 

数据结构

Zookeeper 维护一种树状层次结构,树中的节点被称为 znode,znode 用来存储数据。一种是短暂 znode,一种是持久 znode。

短暂 node 是根据会话链接存在,会话消失或超时,则消失。

持久 znode 只有客户端明确要删除该持久 znode 时才被删除。

Zookeeper 使用这样一个相似文件系统的树结构,数据能够挂在某个节点上,能够对这个节点进行删改。因为 zookeeper 集群做为一个总体对提供服务,因此对于任何节点上的修改都是对集群总体进行修改,也能够说是对集群内全部的节点同时进行修改。

Znode 的大小存在限制,默认是 1MB。能够经过参数调整,可是 Zookeeper 设计的初衷并非存储大数据量,而是对关键数据对外提供高效稳定的服务。

合理的使用 znode,不只提升 Zookeeper 服务的性能,也能保证 Zookeeper 服务的稳定性。

选举

Zookeeper 服务有两种运行模式:Standalone 模式和 Replicated 模式。当只有一个服务器来做为 Zookeeper 服务器时,是 Standalone 模式,能够用于开发测试环境。

生产环境下,Zookeeper 一般使用 Replicated 模式,来保证高可用性和可恢复性,Replicated模式下集群内部只要有半数以上的服务器处于可用状态,它就可以提供服务。

Replicated 模式下集群内的全部机器经过一个选择过程选出一台称为”领导者(leader)”,其余机器称为“跟随者(follower)”。一旦半数以上(或指定数量)的跟随者已经将其状态与领导者同步,则选举过程结束。若是 Leader 挂了,zk 集群会从新选举,在毫秒级别就会从新选举出一个 Leaer。Leader 提供写入请求,全部机器提供读取请求,观察者咱们这里不谈。全部的写请求都会发送给领导者,再有领导者将更新广播给全部的跟随者。当半数以上的跟随者已经将修改持久化以后,领导者才会提交这个更新。而后客户端会受到一个更新成功的响应。这个用来达成共识的协议被设计成具备原子性,所以每一个修改要么成功要么失败。这相似于数据库中的两段式提交协议。

为了保证客户端查看 Zookeeper 各机器数据的及时性,客户端对 znode 的数据读取会自动调用 sync 操做。Sync 操做会强制此服务器的 znode 同步到 leader 的状态。

一般状况下,生产环境使用 replicated 模式,集群一般包含奇数台机器。通常 3 或 5台。例如,在一个有 5 节点的集群内部,只容许最多 2 台机器出现故障,只要有 3 台或者 3台以上的机器存活,那么集群就能够对外提供服务器。注意,对于 6 台机器的集群,也只容许最多 2 台机器出现故障,当出现 3 台机器故障时,集群一样不能对外提供服务。

设计特色

Zookeeper 的设计中有以下特色:
 

• 顺序一致性

全局惟一的 ID,称为 zxid(”ZooKeeper Transaction ID”).ZooKeeper 要求的更新都是按照编
号并排序,决定了分布式系统的执行顺序。对某一个 znode 的更新,好比操做 a 执行先于操
做 b,那么全部的客户端只会出现先看到 a 再看到 b;反之不能。
 

• 原子性

一个更新做为一个原子事务,要么成功要么失败。若是失败,任何客户端不会看到更新的结
果。
 

• 单一系统映像

任何客户端在链接到任何 zookeeper 服务器时,看到都是一样的视图。按顺序链接到不一样的
zookeeper 服务器,只会看到更新结果。好比,ClientA 前后登陆 ServerA 和 ServerB,那么在
ClientA 在 ServerB 上看到的视图老是比 ServerA 看到的更新。

 

• 持久性

一个更新一旦成功,结果就会永久写入,并不能被撤销。
 

• 及时性

任何客户端看到的系统视图均可能滞后的,可是滞后时间不能太长。若是一个服务器的系统
视图太久,那还不如关闭此服务器,链接到一个系统视图较新的服务器。

 

注意事项

 

• 机器列表

客户端连接 Zookeeper 的机器列表、每一个 Zookeeper 服务器的机器列表必须保持一致。
若是客户端包含列表少与服务端,虽然工做仍是正常的,可是损失了 Zookeeper 服务部分的高可用性。
若是客户端的列表里包含不一样 Zookeeper 集群的服务器,那么有些工做可能将变得异常。固然同一集群内的各个 Zookeeper 服务器的配置应该保持一致。

 

• 内存设置

你应该特别留心设置 Zookeeper 服务的 Java max heap size。
Zookeeper 中的 znode 数据都会存放在内存中,同时内存数据的快照会按期保存在磁盘上。
Zookeeper 须要足够的内存,确保 zookeeper 不会使用 swap,确保 Zookeeper 分配的最大 heap size 不大于真正可用的内存。

 

• 日志磁盘

Zookeeper 中影响性能最关键的部分在于 transaction log。Zookeeper 在作出响应以前会把事务日志同步到存储介质上。

一个独立的日志磁盘是维持优秀性能的关键。若是将日志写入一个繁忙的磁盘将致使恶劣的性能表现。