大数据处理技术之分布式协调服务ZooKeeper

ZooKeeper简介

1.什么是ZooKeeper

ZooKeeper是Google的Chubby一个开源的实现，是Hadoop的分布式协调服务；它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等。

2.架构原理

由一组服务器节点组成。有一个节点角色为Leader，其他节点的角色为Follower；当客户端连接到ZooKeeper集群并执行写请求时，这些请求首先会发送到Leader节点；Leader节点接收到数据变更请求后，首先将该变更写入本地磁盘供恢复使用，写完后数据变更到内存中以加快读取数据；最后，Leader节点上的数据变更会同步（广播）到集群的其他Follower节点上；当Leader失效时，Follower快速响应，由消息层重新选出一个Leader节点来处理客户端的请求。

3.数据模型

树形层次的命名空间，可以共享给分布式应用程序。ZooKeeper数据保存在内存中，可以提高吞吐量和降低数据延迟名称由斜线（/）分隔的路径元素组成，每个元素（也叫节点）都有路径标识。每个节点都可以有与之关联的数据以及子节点，通常用zonde来表示ZooKeeper命名空间中的名称节点。

存储在zonde上的数据会被客户端原子化地读取和写入，读取操作可以获取与znode关联的所有数据，写入操作可以替换所有数据。
znode的主要特点：
①znode仅存储协调数据，即与同步相关的数据
②数据量很小，一般B~KB量级
③一个zonde维护一个状态结构，当存储数据每次发生变化，版本号都会递增
④状态结构包括版本号、ACL（访问控制列表）变更、时间戳
⑤每个zonde都有一个ACL访问控制列表），用户限定该znode的客户端访问权限
⑥客户端可以znode上设置一个观察者（Watcher），如果zonde上的数据发生变化，ZooKeeper就会通知客户端，从而触发Watcher中实现的逻辑的执行

4.节点类型

持久节点（PERSISTENT）

创建后一直存在，除非手动将其删除

持久顺序节点（PERSISTENT_SEQUENTIAL）

拥有持久节点的功能，在创建时，ZooKeeper会在节点名称末尾自动追加一个自增长的数字后缀作为新的节点名称，以便记录每个节点创建的先后顺序
数字后缀的长度是10位，且由0填充
例如在/lock节点下创建子节点/lock/znode-，第一个创建的节点为/lock/znode-0000000000

临时节点（EPHEMERAL）

客户端与ZooKeeper服务器会话存在，这些节点就存在，客户端会话结束时，节点将被删除
临时节点不可以有子节点

临时顺序节点（EPHEMERAL_SEQUENTIAL）

拥有临时节点的功能，在创建时，ZooKeeper会在节点名称末尾自动追加一个自增长的数字后缀作为新的节点名称

5.Watcher机制

ZooKeeper是一个基于Watcher（观察者）模式设计的分布式服务管理框架

允许客户端向服务器的znode上注册一个Watcher，一旦zonde的状态发生变化，ZooKeeper就会通知已经在它上面注册的Watcher做出相应反应

当前，ZooKeeper有四种变化事件

节点创建
节点删除
节点数据变更
子节点变更

所有的读取操作，都可以向服务器设置一个Watcher，Watcher事件相当于一次性的触发器，如果znode再次变更，则不会发送任何通知。

Watcher机制执行流程

Watcher有两种类型
数据Watcher：只监听节点元数据的变化，getData()方法和exists()方法可以设置数据Watcher。
子节点Watcher：只监听子节点的创建与删除，getChildren()方法可以设置子节点Watcher。

事件触发

setData()方法会触发数据Watcher
一个成功的create()方法会触发正在创建的znode的数据Watcher以及父节点的子节点Watcher
一个成功的delete()方法会被删除的znode触发一个数据Watcher以及父节点的子节点Watcher

Watcher相关事件

节点创建事件：通过调用exists()方法设置
节点删除事件：通过调用exists()、getData()和getChildren()方法设置
节点改变事件：通过调用exists()和getData()设置 子节点事件：通过调用getChildren()方法设置

6.分布式锁

利用ZooKeeper实现分布式锁，常用的实现方法：所有希望获得锁的客户端都需要执行以下操作：

客户端连接ZooKeeper，调用create方法在指定锁节点（如/lock）下创建一个临时顺序节点。
客户端调用getChildren()方法查询指定锁节点下的所有子节点列表，判断子节点列表中序号最小的子节点是否是自己创建。如果是，则客户端获得锁，否则监听排在自己前一位的子节点的删除事件，若监听的子节点被删除，则重复执行此步骤，直至获得锁客户端执行业务代码。
客户端完成业务代码后，删除在ZooKeeper中对应的子节点以释放锁。

注*

Ⅰ.为什么要创建临时节点而不是永久节点？
答：如果客户端宕机，会话则失败，节点会删除以释放封锁。
Ⅱ.未获得封锁的客户端为什么要监听排在自己前一位的子节点的删除事件？
答：当锁释放时，只需要通知一个客户端，节省带宽。

ZooKeeper安装配置

在ZooKeeper集群中，会有一个Leader服务器负责管理和协调其他服务器。因此，服务器的数量通常是单数（如3、5、7），2n+1服务器组成的集群最多可以运行n台服务器失效。

配置要点：

编写配置文件：conf/zoo.cfg

在conf目录下创建一个配置文件zoo.cfg，

#基本事件单元，一个心跳的时长，单位：ms

tickTime=2000

#Follower服务器初始化连接Leader服务器时能等待的最大心跳数

initLimit=5

#Follower服务器与Leader服务器之间发送消息以及请求/应答时所能等待的最多心跳数

syncLimit=2

#存储数据的目录，需提前存在

dataDir=（ZOOKEEPER_HOME）/dataDir

#客服端连接ZooKeeper服务器的端口

clientPort=2181

#服务器，id值需唯一（1~255）后两个端口分别为Leader端口、选举端

server.1=centos01:2888:3888
server.2=centos02:2888:3888
server.3=centos03:2888:3888

配置服务器id

在指定的数据目录（配置参数中dataDir）下创建文件myid，输入当前服务器id值（注意与参数server.id中的id保持一致）

启动ZooKeeper

在每个节点执行如下命令

bin/zkServer.sh start

查看启动状态

bin/zkServer.sh status

ZooKeeper命令行操作

连接到ZooKeeper服务器

bin/zkCli.sh -server centos01:2181

常用命令
查询节点列表：ls /
创建节点：create /zk “mydata”
查看节点详细信息：get /zk
修改节点：set /zk “mydatanew”
删除节点：delete /zk

HDFS HA与YARN HA

一、HDFS HA

在Hadoop2.0之前，一个HDFS集群只有一个单一的NameNode，一旦NameNode服务不可用，则整个集群无法访问。
HDFS HA解决了上述问题，可以在同一个集群中运行两个NameNode，其中一个处于活动状态（active），另一个处于备用状态（standby），且只有活动状态的NameNode可以对外提供读写服务。当活动状态的NameNode崩溃时，HDFS集群可以快速切换到备用的NameNode，这样也就是实现了故障自动转移。
　　HDFS HA集群架构原理
为了实现故障转移，需要让备用NameNode的状态保持与活动NameNode同步，即元数据同步
两个NameNode都与一组名为“JournalNode”的独立进程进行通信

这种实现方式成为QJM（Qurom Journal Manager），使用2N+1台JournalNode存储元数据信息，当活动NameNode向QJM写入信息时，只要多数（≥N+1）JornalNode返回成功，即可认为该次数据写入成功，以此保证数据高可用性。（QJM集群最多容忍N台计算机宕机）。此外，还需要备用NameNode拥有关于集群中块位置的最新信息。

DataNode配置两个NameNode的位置，并将块位置信息和心跳发送到这两个位置。

HDFS自动故障转移

虽然系统配备了两个NameNode，但即使活动NameNode出现故障，系统也不会自动触发从活动NameNode切换到备用NameNode的故障转移。

要实现故障自动转移，还需要添加两个组件

ZooKeeper：故障检测和NameNode选举

每个NameNode都在ZooKeeper中维护一个持久会话，如果计算机崩溃，会话就会过期，ZooKeeper将通知另一个NameNode，从而实现故障转移。
当活动NameNode故障时，ZooKeeper提供了一个简单的选举机制，从备用NameNode中选举一个作为活动NameNode（目前只有唯一备用NameNode）

ZKFailoverContraller进程

独立进程，相当于ZooKeeper客户端，负责监视和管理NameNode的状态，对NameNode的主/备切换，进行总体控制
每个NameNode都会运行一个ZKFC，负责定期检测本地NameNode的健康状态，一旦发现问题，及时通知ZooKeeper

HDFS结合ZooKeeper自动故障转移架构

第一次启动

1.启动ZooKeeper集群

2.启动JournalNode进程

3.格式化活动NameNode

4.复制元数据到备用NameNode

先启动活动NameNode

5.初始化HA在ZooKeeper中状态

先停止NameNode

6.启动HDFS集群

7.启动ZKFC守护进程

正常按照如下顺序启动

1.启动ZooKeeper集群

2.启动HDFS集群

3.启动ZKFC守护进程

二、YARN HA

在Hadoop2.4之前，Hadoop集群只有一个ResourceManager，当ResourceManager出现故障，将影响整个集群。

YARN HA增加了冗余，即一个活动/备用ResourceManager对，以便可以进行故障转移。

YARN HA架构

与HDFS HA不同，ResourceManager中的ZKFC只是作为ResourceManager的一个线程，而不是一个独立的进程

启动顺序

1.启动ZooKeeper集群

2.分别在ResourceManager节点启动yarn

也可分别启动ResourceManager、NodeManager

ZooKeeper Java API

主要API接口

String create (String path,byte[ ] data,List acl,CreateModecreateMode)
Stat exists(String path,boolean watch)
void delete(Stringpath,int version)
List getChildren(String path,boolean watch)
Stat setData(String path,byte[ ] data,int version)
byte[ ] getData(String path,boolean watch,Stat stat)
void addAuthInfo(String scheme,byte[ ] auth)
Stat setACL(String path,List acl,int version)

主要功能

1.创建节点

2.修改数据

3.获取数据

4.删除节点