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

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

 

简介

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的方式来实现。全部客户端都去/exclusivelock节点下建立临时子节点/exclusivelock/lock。ZooKeeper会保证在全部客户端中，最终只有一个客户端可以建立成功，那么就能够认为该客户端得到了锁。同时，全部没有获取到锁的客户端就须要到/exclusive_lock节点上注册一个子节点变动的Watcher监听，以便实时监听到lock节点的变动状况。

 

释放锁

 

由于/exclusive_lock/lock是一个临时节点，所以在如下两种状况下，都有可能释放锁。

 

当前得到锁的客户端机器发生宕机或重启，那么该临时节点就会被删除，释放锁。

正常执行完业务逻辑后，客户端就会主动将本身建立的临时节点删除，释放锁。

不管在什么状况下移除了lock节点，ZooKeeper都会通知全部在/exclusive_lock节点上注册了节点变动Watcher监听的客户端。这些客户端在接收到通知后，再次从新发起分布式锁获取，即重复『获取锁』过程。

 

共享锁

 

共享锁（Shared Locks，简称S锁），又称为读锁。若是事务T1对数据对象O1加上了共享锁，那么T1只能对O1进行读操做，其余事务也能同时对O1加共享锁（不能是排他锁），直到O1上的全部共享锁都释放后O1才能被加排他锁。

总结：能够多个事务同时得到一个对象的共享锁（同时读），有共享锁就不能再加排他锁（由于排他锁是写锁）

 

ZooKeeper在大型分布式系统中的应用

 

前面已经介绍了ZooKeeper的典型应用场景。本节将以常见的大数据产品Hadoop和HBase为例来介绍ZooKeeper在其中的应用，帮助你们更好地理解ZooKeeper的分布式应用场景。

 

ZooKeeper在Hadoop中的应用

 

在Hadoop中，ZooKeeper主要用于实现HA(Hive Availability），包括HDFS的NamaNode和YARN的ResourceManager的HA。同时，在YARN中，ZooKeepr还用来存储应用的运行状态。HDFS的NamaNode和YARN的ResourceManager利用ZooKeepr实现HA的原理是同样的，因此本节以YARN为例来介绍。

 

从上图能够看出，YARN主要由ResourceManager（RM）、NodeManager（NM）、ApplicationMaster（AM）和Container四部分组成。其中最核心的就是ResourceManager。

 

ResourceManager负责集群中全部资源的统一管理和分配，同时接收来自各个节点（NodeManager）的资源汇报信息，并把这些信息按照必定的策略分配给各个应用程序（Application Manager），其内部维护了各个应用程序的ApplicationMaster信息、NodeManager信息以及资源使用信息等。

 

为了实现HA，必须有多个ResourceManager并存（通常就两个），而且只有一个ResourceManager处于Active状态，其余的则处于Standby状态，当Active节点没法正常工做（如机器宕机或重启）时，处于Standby的就会经过竞争选举产生新的Active节点。

 

主备切换

 

下面咱们就来看看YARN是如何实现多个ResourceManager之间的主备切换的。

 

一、建立锁节点 在ZooKeeper上会有一个/yarn-leader-election/appcluster-yarn的锁节点，全部的ResourceManager在启动的时候，都会去竞争写一个Lock子节点：/yarn-leader-election/appcluster-yarn/ActiveBreadCrumb，该节点是临时节点。ZooKeepr可以为咱们保证最终只有一个ResourceManager可以建立成功。建立成功的那个ResourceManager就切换为Active状态，没有成功的那些ResourceManager则切换为Standby状态。

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

appcluster-yarnrm2
cZxid = 0x1b00133dc0
ctime = Tue Jan 03 15:44:42 CST 2017
mZxid = 0x1f00000540
mtime = Sat Jan 07 00:50:20 CST 2017
pZxid = 0x1b00133dc0
cversion = 0
dataVersion = 28
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 22
numChildren = 0

 

能够看到此时集群中ResourceManager2为Active。

 

二、注册Watcher监听 全部Standby状态的ResourceManager都会向/yarn-leader-election/appcluster-yarn/ActiveBreadCrumb节点注册一个节点变动的Watcher监听，利用临时节点的特性，可以快速感知到Active状态的ResourceManager的运行状况。

 

三、主备切换 当Active状态的ResourceManager出现诸如宕机或重启的异常状况时，其在ZooKeeper上链接的客户端会话就会失效，所以/yarn-leader-election/appcluster-yarn/ActiveBreadCrumb节点就会被删除。此时其他各个Standby状态的ResourceManager就都会接收到来自ZooKeeper服务端的Watcher事件通知，而后会重复进行步骤1的操做。

 

以上就是利用ZooKeeper来实现ResourceManager的主备切换的过程，实现了ResourceManager的HA。

 

HDFS中NameNode的HA的实现原理跟YARN中ResourceManager的HA的实现原理相同。其锁节点为/hadoop-ha/mycluster/ActiveBreadCrumb。

 

ResourceManager状态存储

 

在 ResourceManager 中，RMStateStore 可以存储一些 RM 的内部状态信息，包括 Application 以及它们的 Attempts 信息、Delegation Token 及 Version Information 等。须要注意的是，RMStateStore 中的绝大多数状态信息都是不须要持久化存储的，由于很容易从上下文信息中将其重构出来，如资源的使用状况。在存储的设计方案中，提供了三种可能的实现，分别以下。

 

·基于内存实现，通常是用于平常开发测试。

·基于文件系统的实现，如HDFS。

·基于ZooKeeper实现。

 

因为这些状态信息的数据量都不是很大，所以Hadoop官方建议基于ZooKeeper来实现状态信息的存储。在ZooKeepr上，ResourceManager 的状态信息都被存储在/rmstore这个根节点下面。

[zk: localhost:2181(CONNECTED) 28] ls /rmstore/ZKRMStateRoot[RMAppRoot, 
AMRMTokenSecretManagerRoot, EpochNode, RMDTSecretManagerRoot, RMVersionNode]

 

RMAppRoot 节点下存储的是与各个 Application 相关的信息，RMDTSecretManagerRoot 存储的是与安全相关的 Token 等信息。每一个 Active 状态的 ResourceManager 在初始化阶段都会从 ZooKeeper 上读取到这些状态信息，并根据这些状态信息继续进行相应的处理。

 

小结：

 

ZooKeepr在Hadoop中的应用主要有：

 

一、HDFS中NameNode的HA和YARN中ResourceManager的HA。

二、存储RMStateStore状态信息

 

ZooKeeper在HBase中的应用

 

HBase主要用ZooKeeper来实现HMaster选举与主备切换、系统容错、RootRegion管理、Region状态管理和分布式SplitWAL任务管理等。

 

HMaster选举与主备切换

 

HMaster选举与主备切换的原理和HDFS中NameNode及YARN中ResourceManager的HA原理相同。

 

系统容错

 

当HBase启动时，每一个RegionServer都会到ZooKeeper的/hbase/rs节点下建立一个信息节点（下文中，咱们称该节点为"rs状态节点"），例如/hbase/rs/[Hostname]，同时，HMaster会对这个节点注册监听。当某个 RegionServer 挂掉的时候，ZooKeeper会由于在一段时间内没法接受其心跳（即 Session 失效），而删除掉该 RegionServer 服务器对应的 rs 状态节点。与此同时，HMaster 则会接收到 ZooKeeper 的 NodeDelete 通知，从而感知到某个节点断开，并当即开始容错工做。

 

HBase为何不直接让HMaster来负责RegionServer的监控呢？若是HMaster直接经过心跳机制等来管理RegionServer的状态，随着集群愈来愈大，HMaster的管理负担会愈来愈重，另外它自身也有挂掉的可能，所以数据还须要持久化。在这种状况下，ZooKeeper就成了理想的选择。

 

RootRegion管理

 

对应HBase集群来讲，数据存储的位置信息是记录在元数据region，也就是RootRegion上的。每次客户端发起新的请求，须要知道数据的位置，就会去查询RootRegion，而RootRegion自身位置则是记录在ZooKeeper上的（默认状况下，是记录在ZooKeeper的/hbase/meta-region-server节点中）。当RootRegion发生变化，好比Region的手工移动、从新负载均衡或RootRegion所在服务器发生了故障等是，就可以经过ZooKeeper来感知到这一变化并作出一系列相应的容灾措施，从而保证客户端老是可以拿到正确的RootRegion信息。

 

Region管理

 

HBase里的Region会常常发生变动，这些变动的缘由来自于系统故障、负载均衡、配置修改、Region分裂与合并等。一旦Region发生移动，它就会经历下线（offline）和从新上线（online）的过程。

 

在下线期间数据是不能被访问的，而且Region的这个状态变化必须让全局知晓，不然可能会出现事务性的异常。对于大的HBase集群来讲，Region的数量可能会多达十万级别，甚至更多，这样规模的Region状态管理交给ZooKeeper来作也是一个很好的选择。

 

分布式SplitWAL任务管理

 

当某台RegionServer服务器挂掉时，因为总有一部分新写入的数据尚未持久化到HFile中，所以在迁移该RegionServer的服务时，一个重要的工做就是从WAL中恢复这部分还在内存中的数据，而这部分工做最关键的一步就是SplitWAL，即HMaster须要遍历该RegionServer服务器的WAL，并按Region切分红小块移动到新的地址下，并进行日志的回放（replay）。

 

因为单个RegionServer的日志量相对庞大（可能有上千个Region，上GB的日志），而用户又每每但愿系统可以快速完成日志的恢复工做。所以一个可行的方案是将这个处理WAL的任务分给多台RegionServer服务器来共同处理，而这就又须要一个持久化组件来辅助HMaster完成任务的分配。当前的作法是，HMaster会在ZooKeeper上建立一个SplitWAL节点（默认状况下，是/hbase/SplitWAL节点），将"哪一个RegionServer处理哪一个Region"这样的信息以列表的形式存放到该节点上，而后由各个RegionServer服务器自行到该节点上去领取任务并在任务执行成功或失败后再更新该节点的信息，以通知HMaster继续进行后面的步骤。ZooKeeper在这里担负起了分布式集群中相互通知和信息持久化的角色。

 

小结：

以上就是一些HBase中依赖ZooKeeper完成分布式协调功能的典型场景。但事实上，HBase对ZooKeepr的依赖还不止这些，好比HMaster还依赖ZooKeeper来完成Table的enable/disable状态记录，以及HBase中几乎全部的元数据存储都是放在ZooKeeper上的。

 

因为ZooKeeper出色的分布式协调能力及良好的通知机制，HBase在各版本的演进过程当中愈来愈多地增长了ZooKeeper的应用场景，从趋势上来看二者的交集愈来愈多。HBase中全部对ZooKeeper的操做都封装在了org.apache.hadoop.hbase.zookeeper这个包中

感兴趣的同窗能够自行研究(【Spark&hadoop大数据交流】：498835267 )