ZooKeeper原理及其在Hadoop和HBase中的应用

最新推荐文章于 2023-11-15 16:08:31 发布

weixin_30525825

最新推荐文章于 2023-11-15 16:08:31 发布

阅读量82

点赞数

文章标签：大数据数据库网络

原文链接：http://www.cnblogs.com/iyulang/p/6604914.html

版权

简介

ZooKeeper是一个开源的**分布式协调服务**，由雅虎创建，是Google Chubby的开源实现。分布式应用程序可以基于ZooKeeper实现诸如**数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列**等功能。

基本概念

本节将介绍ZooKeeper的几个核心概念。这些概念贯穿于之后对ZooKeeper更深入的讲解，因此有必要预先了解这些概念。

集群角色

在ZooKeeper中，有三种角色：

Leader
Follower
Observer

一个ZooKeeper集群同一时刻只会有一个Leader，其他都是Follower或Observer。

ZooKeeper配置很简单，每个节点的配置文件(zoo.cfg)都是一样的，只有myid文件不一样。myid的值必须是zoo.cfg中server.{数值}的{数值}部分。

zoo.cfg文件内容示例：

maxClientCnxns=0
# The number of milliseconds of each tick
tickTime=2000
# The number of ticks that the initial
# synchronization phase can take
initLimit=10
# The number of ticks that can pass between
# sending a request and getting an acknowledgement syncLimit=5 # the directory where the snapshot is stored. dataDir=/var/lib/zookeeper/data # the port at which the clients will connect clientPort=2181 # the directory where the transaction logs are stored. dataLogDir=/var/lib/zookeeper/logs server.1=192.168.20.101:2888:3888 server.2=192.168.20.102:2888:3888 server.3=192.168.20.103:2888:3888 server.4=192.168.20.104:2888:3888 server.5=192.168.20.105:2888:3888 minSessionTimeout=4000 maxSessionTimeout=100000

在装有ZooKeeper的机器的终端执行 zookeeper-server status 可以看当前节点的ZooKeeper是什么角色（Leader or Follower）。

[root@node-20-103 ~]# zookeeper-server status
JMX enabled by default
Using config: /etc/zookeeper/conf/zoo.cfg
Mode: follower

[root@node-20-104 ~]# zookeeper-server status
JMX enabled by default
Using config: /etc/zookeeper/conf/zoo.cfg
Mode: leader

如上，node-20-104是Leader，node-20-103是follower。

ZooKeeper默认只有Leader和Follower两种角色，没有Observer角色。

为了使用Observer模式，在任何想变成Observer的节点的配置文件中加入：peerType=observer
并在所有server的配置文件中，配置成observer模式的server的那行配置追加:observer，例如：
server.1:localhost:2888:3888:observer

ZooKeeper集群的所有机器通过一个**Leader选举过程**来选定一台被称为**『Leader』**的机器，**Leader服务器**为客户端提供**读**和**写**服务。

Follower和Observer都**能**提供**读**服务，**不能**提供**写**服务。两者唯一的区别在于，**Observer**机器**不参与Leader选举**过程，也**不参与写操作**的『过半写成功』策略，因此Observer可以在**不影响写性能**的情况下**提升**集群的**读性能**。

会话（Session）

Session是指**客户端会话**，在讲解客户端会话之前，我们先来了解下**客户端连接**。在ZooKeeper中，一个客户端连接是指客户端和ZooKeeper服务器之间的**TCP长连接**。ZooKeeper对外的服务端口默认是**2181**，客户端启动时，首先会与服务器建立一个TCP连接，从第一次连接建立开始，客户端会话的生命周期也开始了，通过这个连接，客户端能够通过**心跳检测**和服务器保持有效的会话，也能够向ZooKeeper服务器**发送请求**并**接受响应**，同时还能通过该连接接收来自服务器的**Watch事件通知**。Session的**SessionTimeout**值用来设置一个客户端会话的**超时时间**。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在SessionTimeout规定的时间内能够**重新连接上**集群中**任意一台**服务器，那么之前创建的会话**仍然有效**。

数据节点（ZNode）

在谈到分布式的时候，**一般**『节点』指的是组成集群的每一台**机器**。而ZooKeeper中的数据节点是指**数据模型**中的**数据单元**，称为**ZNode**。ZooKeeper将所有数据存储在**内存中**，数据模型是一棵**树（ZNode Tree）**，由斜杠（/）进行分割的路径，就是一个ZNode，如/hbase/master,其中hbase和master**都是**ZNode。每个ZNode上都会保存**自己的数据内容**，同时会保存一系列**属性信息**。

注：
这里的ZNode可以理解成**既是**Unix里的**文件**，**又是**Unix里的**目录**。因为每个ZNode不仅本身可以**写数据**（相当于Unix里的文件），还可以有**下一级文件或目录**（相当于Unix里的目录）。

在ZooKeeper中，ZNode可以分为**持久节点**和**临时节点**两类。

持久节点

所谓持久节点是指一旦这个ZNode被创建了，除非主动进行ZNode的移除操作，否则这个ZNode将一直保存在ZooKeeper上。

临时节点

临时节点的生命周期跟客户端会话绑定，一旦客户端会话失效，那么这个客户端创建的所有临时节点都会被移除。

另外，ZooKeeper还允许用户为每个节点添加一个特殊的属性：SEQUENTIAL。一旦节点被标记上这个属性，那么在这个节点被创建的时候，ZooKeeper就会自动在其节点后面追加上一个整型数字，这个整型数字是一个由父节点维护的自增数字。

版本

ZooKeeper的每个ZNode上都会存储数据，对应于每个ZNode，ZooKeeper都会为其维护一个叫作Stat的数据结构，Stat中记录了这个ZNode的三个数据版本，分别是version（当前ZNode的版本）、cversion（当前ZNode子节点的版本）和aversion（当前ZNode的ACL版本）。

状态信息

每个ZNode除了存储数据内容之外，还存储了ZNode本身的一些状态信息。用 get 命令可以同时获得某个ZNode的内容和状态信息。如下：

[zk: localhost:2181(CONNECTED) 23] get /yarn-leader-election/appcluster-yarn/ActiveBreadCrumb

appcluster-yarnrm1
cZxid = 0x1b00133dc0    //Created ZXID,表示该ZNode被创建时的事务ID
ctime = Tue Jan 03 15:44:42 CST 2017 //Created Time,表示该ZNode被创建的时间 mZxid = 0x1d00000063 //Modified ZXID，表示该ZNode最后一次被更新时的事务ID mtime = Fri Jan 06 08:44:25 CST 2017 //Modified Time，表示该节点最后一次被更新的时间 pZxid = 0x1b00133dc0 //表示该节点的子节点列表最后一次被修改时的事务ID。注意，只有子节点列表变更了才会变更pZxid，子节点内容变更不会影响pZxid。 cversion = 0 //子节点的版本号 dataVersion = 11 //数据节点的版本号 aclVersion = 0 //ACL版本号 ephemeralOwner = 0x0 //创建该节点的会话的seddionID。如果该节点是持久节点，那么这个属性值为0。 dataLength = 22 //数据内容的长度 numChildren = 0 //子节点的个数

在ZooKeeper中，version属性是用来实现乐观锁机制中的『写入校验』的（保证分布式数据原子性操作）。

事务操作

在ZooKeeper中，能改变ZooKeeper服务器状态的操作称为事务操作。一般包括数据节点创建与删除、数据内容更新和客户端会话创建与失效等操作。对应每一个事务请求，ZooKeeper都会为其分配一个全局唯一的事务ID，用ZXID表示，通常是一个64位的数字。每一个ZXID对应一次更新操作，从这些ZXID中可以间接地识别出ZooKeeper处理这些事务操作请求的全局顺序。

Watcher

Watcher（事件监听器），是ZooKeeper中一个很重要的特性。ZooKeeper允许用户在指定节点上注册一些Watcher，并且在一些特定事件触发的时候，ZooKeeper服务端会将事件通知到感兴趣的客户端上去。该机制是ZooKeeper实现分布式协调服务的重要特性。

ACL

ZooKeeper采用ACL（Access Control Lists）策略来进行权限控制。ZooKeeper定义了如下5种权限。

CREATE: 创建子节点的权限。
READ: 获取节点数据和子节点列表的权限。
WRITE：更新节点数据的权限。
DELETE: 删除子节点的权限。
ADMIN: 设置节点ACL的权限。

注意：CREATE 和 DELETE 都是针对子节点的权限控制。

ZooKeeper典型应用场景

ZooKeeper是一个**高可用**的分布式**数据管理与协调框架**。基于对ZAB算法的实现，该框架能够很好地保证分布式环境中数据的**一致性**。也是基于这样的特性，使得ZooKeeper成为了解决分布式一致性问题的利器。

数据发布与订阅（配置中心）

数据发布与订阅，即所谓的**配置中心**，顾名思义就是发布者将数据发布到ZooKeeper节点上，供订阅者进行数据订阅，进而达到**动态获取数据**的目的，实现配置信息的**集中式管理**和**动态更新**。

在我们平常的应用系统开发中，经常会碰到这样的需求：系统中需要使用一些通用的配置信息，例如**机器列表信息**、**数据库配置信息**等。这些全局配置信息通常具备以下3个特性。

数据量通常比较**小。**
数据内容在运行时**动态变化**。
集群中各机器共享，**配置一致**。

对于这样的全局配置信息就可以发布到ZooKeeper上，让客户端（集群的机器）去订阅该消息。

发布/订阅系统一般有两种设计模式，分别是**推（Push）**和**拉（Pull）**模式。

推：**服务端主动**将数据更新发送给所有订阅的客户端。
拉：**客户端主动**发起请求来获取最新数据，通常客户端都采用**定时轮询**拉取的方式。

ZooKeeper采用的是**推拉相结合**的方式。如下：

客户端想服务端**注册**自己需要关注的节点，一旦该节点的数据发生**变更**，那么服务端就会向相应的客户端发送Watcher事件**通知**，客户端接收到这个消息通知后，需要**主动**到服务端**获取**最新的数据（**推拉结合**）。

命名服务(Naming Service)

命名服务也是分布式系统中比较常见的一类场景。在分布式系统中，通过使用命名服务，客户端应用能够根据指定**名字**来获取**资源或服务的地址，提供者等信息**。被命名的实体通常可以是**集群中的机器，提供的服务，远程对象等等**——这些我们都可以统称他们为**名字（Name）**。其中较为常见的就是一些分布式服务框架（如RPC、RMI）中的服务地址列表。通过在ZooKeepr里创建顺序节点，能够很容易创建一个**全局唯一的路径**，这个路径就可以作为一个**名字**。

ZooKeeper的命名服务即生成**全局唯一的ID**。

分布式协调/通知

ZooKeeper中特有**Watcher注册**与**异步通知机制**，能够很好的实现分布式环境下不同机器，甚至不同系统之间的**通知与协调**，从而实现**对数据变更的实时处理**。使用方法通常是不同的客户端都对ZK上同一个ZNode进行注册，监听ZNode的变化（包括ZNode本身内容及子节点的），如果ZNode发生了变化，那么所有订阅的客户端都能够接收到相应的Watcher通知，并做出相应的处理。

ZK的分布式协调/通知，是一种通用的分布式系统机器间的通信方式。

心跳检测

机器间的心跳检测机制是指在分布式环境中，不同机器（或进程）之间需要检测到彼此是否在正常运行，例如A机器需要知道B机器是否正常运行。在传统的开发中，我们通常是通过主机直接是否可以**相互PING通**来判断，更复杂一点的话，则会通过在机器之间建立长连接，通过**TCP连接**固有的心跳检测机制来实现上层机器的心跳检测，这些都是非常常见的心跳检测方法。

下面来看看如何使用ZK来实现分布式机器（进程）间的心跳检测。

基于ZK的**临时节点**的特性，可以让不同的进程都在ZK的一个**指定节点**下创建**临时子节点**，不同的进程直接可以根据这个临时子节点来判断对应的进程**是否存活**。通过这种方式，检测和被检测系统直接并不需要直接相关联，而是通过ZK上的某个节点进行关联，大大**减少了系统耦合**。

工作进度汇报

在一个常见的**任务分发系统**中，通常任务被分发到不同的机器上执行后，需要实时地将自己的任务执行进度**汇报**给分发系统。这个时候就可以通过ZK来实现。在ZK上选择一个节点，每个任务客户端都在这个节点下面创建**临时子节点**，这样便可以实现两个功能：

通过判断临时节点是否存在来确定任务机器**是否存活**。
各个任务机器会实时地将自己的**任务执行进度写到这个临时节点上去**，以便中心系统能够实时地获取到任务的**执行进度**。

Master选举

Master选举可以说是ZooKeeper**最典型的应用场景**了。比如HDFS中Active NameNode的选举、YARN中Active ResourceManager的选举和HBase中Active HMaster的选举等。

针对Master选举的需求，通常情况下，我们可以选择常见的**关系型数据库**中的**主键特性**来实现：希望成为Master的机器都向数据库中插入一条**相同主键ID**的记录，数据库会帮我们进行**主键冲突检查**，也就是说，**只有一台**机器能插入成功——那么，我们就认为向数据库中**成功插入**数据的客户端机器**成为Master**。

依靠关系型数据库的主键特性确实能够很好地保证在集群中选举出唯一的一个Master。但是，如果当前选举出的Master挂了，那么该如何处理？谁来告诉我Master挂了呢？显然，关系型数据库无法通知我们这个事件。但是，ZooKeeper可以做到！

利用ZooKeepr的强一致性，能够很好地保证在分布式高并发情况下节点的创建一定能够保证全局唯一性，即ZooKeeper将会保证客户端**无法创建一个已经存在的ZNode**。也就是说，如果同时有多个客户端请求创建**同一个**临时节点，那么最终一定**只有一个**客户端请求能够创建成功。利用这个特性，就能很容易地在分布式环境中进行Master选举了。

成功创建该节点的客户端所在的机器就成为了Master。同时，其他没有成功创建该节点的客户端，都会在该节点上**注册**一个子节点变更的**Watcher**，用于监控当前Master机器是否存活，一旦发现当前的Master挂了，那么其他客户端将会**重新进行Master选举**。

这样就实现了Master的**动态选举**。

分布式锁

分布式锁是控制**分布式系统**之间**同步访问共享资源**的一种方式。

分布式锁又分为**排他锁**和**共享锁**两种。

排他锁

排他锁（Exclusive Locks，简称X锁），又称为**写锁**或**独占锁**。

如果事务T1对数据对象O1加上了排他锁，那么在整个加锁期间，只允许事务T1对O1进行**读取和更新**操作，其他任何事务都不能在对这个数据对象进行任何类型的操作（不能再对该对象加锁），直到T1释放了排他锁。

可以看出，排他锁的核心是如何保证当前**只有一个事务获得锁**，并且锁**被释放**后，所有正在等待获取锁的事务都能够**被通知到**。

如何利用ZooKeeper实现排他锁？

定义锁

ZooKeeper上的**一个ZNode可以表示一个锁**。例如/exclusive_lock/lock节点就可以被定义为一个锁。

获得锁

如上所说，把ZooKeeper上的一个ZNode看作是一个锁，**获得锁**就通过**创建ZNode**的方式来实现。所有客户端都去/exclusive_lock节点下创建临时子节点/exclusive_lock/lock。ZooKeeper会保证在所有客户端中，最终只有一个客户端能够创建成功，那么就可以认为该客户端获得了锁。同时，所有没有获取到锁的客户端就需要到/exclusive_lock节点上注册一个子节点变更的Watcher监听，以便实时监听到lock节点的变更情况。

释放锁

因为/exclusive_lock/lock是一个**临时节点**，因此在以下两种情况下，都有可能释放锁。