Zookeeper 知识总结与Hadoop HA

本文总结的zookeeper应用方向主要适用于大数据

1 Zookeeper 简介

1.1 概述

Zookeeper是一个开源的分布式的，为分布式应用提供协调服务的Apache项目。

可以简单理解为：Zookeeper = 文件系统 + 通知机制

从设计角度来理解，是一个基于观察者模式设计的分布式服务框架，负责存储和管理大家关心的数据，然后接受观察者注册，一旦数据状态发生变化，Zookeeper将负责通知已经在Zookeeper上注册的观察者做出相应的反应。

1.2 特点

1）Zookeeper是一个leader（领导者）+ 多个follower（跟随者）组成的集群

2）集群中只要有半数以上的节点存活，Zookeeper集群就能正常服务

3）全局数据一致。每个server保存一份相同的数据副本，Client无论连接到哪个server，数据都是一致的

4）更新请求顺序进行。来自同一个Client的更新请求按其发送顺序依次执行

5）数据更新具有原子性。要么都成功，要么都失败

6）实时性。在一定时间范围内，Client能读到最新数据

1.3 数据结构

Zookeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称作一个ZNode。每一个ZNode默认能存储1MB数据，每个ZNode都可以通过其路径唯一标识。与Unix文件系统不同的是：

• 只有绝对路径；

• 没有文件夹和文件之分，每个节点都可以存储数据，每个节点都可以有子节点。

• 节点分为三种类型：永久、临时、顺序

1.3 应用场景

在大数据方向主要应用于Hadoop HA，包括NameNode HA、ResourceManager HA以及后续Kafka、Hbase等场景的应用。

其他方向还提供统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等服务。

2 Zookeeper 安装部署

1）集群规划：在hadoop001、hadoop002和hadoop003三个节点上部署Zookeeper。

2）下载&解压安装 ：https://zookeeper.apache.org/releases.html

（1）解压zookeeper安装包到/opt/module/目录下

chmod u+x zookeeper-3.4.10.tar.gz
tar -zxvf zookeeper-3.4.10.tar.gz -C /opt/module/

（2）在/opt/module/zookeeper-3.4.10/这个目录下创建zkData

mkdir zkData

（3）重命名/opt/module/zookeeper-3.4.10/conf这个目录下的zoo_sample.cfg为zoo.cfg

mv zoo_sample.cfg zoo.cfg

3）配置

（1）zoo.cfg文件

修改数据存储路径配置

dataDir=/opt/module/zookeeper-3.4.10/zkData

增加如下配置：

#######################cluster##########################
server.2=hadoop001:2888:3888
server.3=hadoop002:2888:3888
server.4=hadoop003:2888:3888

配置完成后同步到其他服务器

**配置参数解读：server.2=hadoop001:2888:3888 **

Server.A=B:C:D

• A是一个数字，表示这个是第几号服务器；

• B是这个服务器的ip地址；

• C是这个服务器与集群中的Leader服务器交换信息的端口；

• D是万一集群中的Leader服务器挂了，需要一个端口来重新进行选举，选出一个新的Leader，而这个端口就是用来执行选举时服务器相互通信的端口。

配置参数解读：zoo.cfg中参数

• tickTime =2000：通信心跳数，Zookeeper服务器与客户端心跳时间，单位毫秒。Zookeeper使用的基本时间，服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个tickTime时间就会发送一个心跳，时间单位为毫秒。它用于心跳机制，并且设置最小的session超时时间为两倍心跳时间。(session的最小超时时间是2*tickTime)

• initLimit =10：LF初始通信时限。集群中的Follower跟随者服务器与Leader领导者服务器之间初始连接时能容忍的最多心跳数（tickTime的数量），用它来限定集群中的Zookeeper服务器连接到Leader的时限。

• syncLimit =5：LF同步通信时限。集群中Leader与Follower之间的最大响应时间单位，假如响应超过syncLimit * tickTime，Leader认为Follwer死掉，从服务器列表中删除Follwer。

• dataDir：数据文件目录+数据持久化路径。主要用于保存Zookeeper中的数据。

• clientPort =2181：客户端连接端口。监听客户端连接的端口。

（2）myid

集群模式下配置一个文件myid，这个文件在dataDir目录下，这个文件里面有一个数据就是A的值，Zookeeper启动时读取此文件，拿到里面的数据与zoo.cfg里面的配置信息比较从而判断到底是哪个server。

在/opt/module/zookeeper-3.4.10/zkData目录下创建一个myid的文件 vi myid 在文件中添加与server对应的编号：hadoop001 为1， hadoop002为2, hadoop002 为3

拷贝配置好的zookeeper到其他机器上，并分别修改myid文件中内容为2、3

4）启动zookeeper

[root@hadoop001 zookeeper-3.4.10]# bin/zkServer.sh start
[root@hadoop002 zookeeper-3.4.10]# bin/zkServer.sh start
[root@hadoop003 zookeeper-3.4.10]# bin/zkServer.sh start

5）查看状态

[root@hadoop001 zookeeper-3.4.10]# bin/zkServer.sh status
JMX enabled by default
Using config: /opt/module/zookeeper-3.4.10/bin/../conf/zoo.cfg
Mode: follower

[root@hadoop002 zookeeper-3.4.10]# bin/zkServer.sh status
JMX enabled by default
Using config: /opt/module/zookeeper-3.4.10/bin/../conf/zoo.cfg
Mode: leader

[root@hadoop003 zookeeper-3.4.5]# bin/zkServer.sh status
JMX enabled by default
Using config: /opt/module/zookeeper-3.4.10/bin/../conf/zoo.cfg
Mode: follower

6）客户端常用命令行操作

3 节点类型

Zookeeper有三种节点类型，四种组合

四种组合的znode：

1)、PERSISTENT-持久化目录节点

客户端与zookeeper断开连接后，该节点依旧存在

2)、 PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点

客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号

3)、EPHEMERAL-临时目录节点

客户端与zookeeper断开连接后，该节点被删除

4)、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点

客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

Hadoop HA正是应用了这种组合类型

4 监听机制

Zookeeper提供三种监控方法：

1）数据是否发生变化：getData()

2）节点数目变化：getChildren()

3）节点是否存在：exists()

软负载均衡：

如图所示，Zookeeper使用临时节点进行监听，假设有两台服务器来做负载均衡，临时节点A、B分别由Server1、Server2创建，节点A、B可以存储Server的机器信息，如IP地址等，当Server1挂了后，节点A自动消失，Zookeeper通知proxy进行调整切换到Server2。在这个过程中proxy监听父节点，先调用节点数目变化机制getChildren()方法，然后再遍历调用子节点的节点是否存在exists()方法，判断哪些节点还存在，并进行切换。

统一配置管理：

假设有音乐地域限制业务场景，用户能收听的音乐会根据不同地域而发生限制，这种限制是通过每台服务器上的配置文件conf的内容来实现的，假设突然有政策原因必须立马调整某一地域的限制歌单，需同时更新所有服务器上的conf文件，传统的方法是采用配置分发服务器通过SCP的方式来实现，但服务器数量达到一定量后，传统的方式会造成配置文件同步延迟，不同用户通过proxy分发到不同服务器，会出现访问的歌单会出现不一致的情况。

大量服务器统一配置管理可交由Zookeeper实现：

（1）可将配置文件信息写入Zookeeper的一个ZNode上（采用永久节点，某些服务器挂了后节点依然会存在）；

（2）各个服务器监听这个ZNode；

（3）Zookeeper将通过数据是否发生变化getData()方法监听ZNode中数据是否发生变化，一旦发生变化，Zookeeper将通知各个服务器进行同步。

（Kafka集群通常也采用Zookeeper统一配置管理）

统一集群管理：见第5部分HA高可用

5 HA高可用

5.1 HA概述

1）HA（High Available），即高可用（7*24小时不中断服务）。

2）实现高可用最关键的策略是消除单点故障。HA严格来说应该分成各个组件的HA机制：HDFS的HA和YARN的HA。

3）Hadoop2.0之前，在HDFS集群中NameNode存在单点故障（SPOF）。

4）NameNode主要在以下两个方面影响HDFS集群

• NameNode机器发生意外，如宕机，集群将无法使用，直到管理员重启
• NameNode机器需要升级，包括软件、硬件升级，此时集群也将无法使用

HDFS HA功能通过配置Active/Standby两个NameNodes实现在集群中对NameNode的热备来解决上述问题。如果出现故障，如机器崩溃或机器需要升级维护，这时可通过此种方式将NameNode很快的切换到另外一台机器。

5.2 HDFS-HA工作机制

5.2.1 HDFS-HA工作要点

（1）元数据管理方式需要改变

内存中各自保存一份元数据；

Edits日志只有Active状态的NameNode节点可以做写操作；

两个NameNode都可以读取Edits；

共享的Edits放在一个共享存储中管理（qjournal和NFS两个主流实现）；

（2）需要一个状态管理功能模块

实现了一个zkfailover，常驻在每一个namenode所在的节点，每一个zkfailover负责监控自己所在NameNode节点，利用zk进行状态标识，当需要进行状态切换时，由zkfailover来负责切换，切换时需要防止brain split现象的发生。

（3）必须保证两个NameNode之间能够ssh无密码登录

（4）隔离（Fence），即同一时刻仅仅有一个NameNode对外提供服务

5.2.2 HDFS-HA故障转移机制

使用命令hdfs haadmin -failover可以手动进行故障转移，在该模式下，即使现役NameNode已经失效，系统也不会自动从现役NameNode转移到待机NameNode，如何配置部署HA自动进行故障转移。自动故障转移为HDFS部署增加了两个新组件：ZooKeeper和ZKFailoverController（ZKFC）进程，如图所示。

ZooKeeper是维护少量协调数据，通知客户端这些数据的改变和监视客户端故障的高可用服务。HA的自动故障转移依赖于ZooKeeper的以下功能：

1）故障检测：集群中的每个NameNode在ZooKeeper中维护了一个持久会话，如果机器崩溃，ZooKeeper中的会话将终止，ZooKeeper通知另一个NameNode需要触发故障转移。

2）现役NameNode选择：ZooKeeper提供了一个简单的机制用于唯一的选择一个节点为active状态。如果目前现役NameNode崩溃，另一个节点可能从ZooKeeper获得特殊的排外锁以表明它应该成为现役NameNode。

ZKFC是自动故障转移中的另一个新组件，是ZooKeeper的客户端，也监视和管理NameNode的状态。每个运行NameNode的主机也运行了一个ZKFC进程，ZKFC负责：

1）健康监测：ZKFC使用一个健康检查命令定期地ping与之在相同主机的NameNode，只要该NameNode及时地回复健康状态，ZKFC认为该节点是健康的。如果该节点崩溃，冻结或进入不健康状态，健康监测器标识该节点为非健康的。

2）ZooKeeper会话管理：当本地NameNode是健康的，ZKFC保持一个在ZooKeeper中打开的会话。如果本地NameNode处于active状态，ZKFC也保持一个特殊的znode锁，该锁使用了ZooKeeper对短暂节点的支持，如果会话终止，锁节点将自动删除。

3）基于ZooKeeper的选择：如果本地NameNode是健康的，且ZKFC发现没有其它的节点当前持有znode锁，它将为自己获取该锁。如果成功，则它已经赢得了选择，并负责运行故障转移进程以使它的本地NameNode为Active。故障转移进程与前面描述的手动故障转移相似，首先如果必要保护之前的现役NameNode，然后本地NameNode转换为Active状态。

配置可参考：https://www.jianshu.com/p/7904fcc727d7

5.3 Yarn-HA工作机制

http://hadoop.apache.org/docs/r2.7.2/hadoop-yarn/hadoop-yarn-site/ResourceManagerHA.html

配置可参考：https://www.cnblogs.com/benfly/p/8118525.html

5.4 HDFS Federation架构设计（补充）

1）NameNode架构的局限性

（1）Namespace（命名空间）的限制

由于NameNode在内存中存储所有的元数据（metadata），因此单个NameNode所能存储的对象（文件+块）数目受到NameNode所在JVM的heap size的限制。50G的heap能够存储20亿（200million）个对象，这20亿个对象支持4000个DataNode，12PB的存储（假设文件平均大小为40MB）。随着数据的飞速增长，存储的需求也随之增长。单个DataNode从4T增长到36T，集群的尺寸增长到8000个DataNode。存储的需求从12PB增长到大于100PB。

（2）隔离问题

由于HDFS仅有一个NameNode，无法隔离各个程序，因此HDFS上的一个实验程序就很有可能影响整个HDFS上运行的程序。

（3）性能的瓶颈

由于是单个NameNode的HDFS架构，因此整个HDFS文件系统的吞吐量受限于单个NameNode的吞吐量。

2）HDFS Federation架构设计 能不能有多个NameNode

3）HDFS Federation应用思考

不同应用可以使用不同NameNode进行数据管理

图片业务、爬虫业务、日志审计业务

Hadoop生态系统中，不同的框架使用不同的NameNode进行管理NameSpace。（隔离性）

6 选举机制

1）半数机制：集群中半数以上机器存活，集群可用。所以Zookeeper适合安装奇数台服务器。

2）Zookeeper虽然在配置文件中并没有指定Master和Slave。但是，Zookeeper工作时，是有一个节点为Leader，其他则为Follower，Leader是通过内部的选举机制临时产生的。

3）以一个简单的例子来说明整个选举的过程。

假设有五台服务器组成的Zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是一样的。假设这些服务器依序启动，来看看会发生什么，如图所示。

（1）服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成，服务器1状态保持为LOOKING；

（2）服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息：此时服务器1发现服务器2的ID比自己目前投票推举的（服务器1）大，更改选票为推举服务器2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服务器1，2状态保持LOOKING

（3）服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数，服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING；

（4）服务器4启动，发起一次选举。此时服务器1，2，3已经不是LOOKING状态，不会更改选票信息。交换选票信息结果：服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，并更改状态为FOLLOWING；

（5）服务器5启动，同4一样当小弟。

7 写数据流程