ZooKeeper和Hadoop高可用（主备切换）

ZooKeeper概述

ZooKeeper概念: Zookeeper是一个分布式协调服务的开源框架。本质上是一个分布式的小文件存储系统
ZooKeeper作用: 主要用来解决分布式集群中应用系统的一致性问题。
ZooKeeper结构: 采用树形层次结构，ZooKeeper树中的每个节点被称为---Znode。且树中的每个节点可以拥有子节点

ZooKeeper集群环境

1.提前准备好zookeeper集群环境

2.配置zookeeper环境变量(注意三台都可以配置下)

[root@node1 ~]# echo 'export ZOOKEEPER_HOME=/export/server/zookeeper' >> /etc/profile 

[root@node1 ~]# echo 'export PATH=$PATH:$ZOOKEEPER_HOME/bin' >> /etc/profile 

[root@node1 ~]# source /etc/profile

3.启动zookeeper服务

启动服务

[root@node1 bin]# zkServer.sh start

查看状态

[root@node1 bin]# zkServer.sh status

如果想关闭可以使用stop

[root@node1 bin]# zkServer.sh stop

zookeeper概念: 分布式协调服务,搭建hadoop高可用环境时,至少需要两个hadoop服务(NameNode和ResourceManager),一主一备,主服务对外提供业务功能,备用服务等待主服务不可用时,启用备用服务器对外提供业务功能.

​

zookeeper的服务角色分别为:

leader: 管理者 ,负责管理follower,处理所有的事务请求(数据的保存,修改,删除)

follower: 追随者,负责选举(选举leader)和数据的同步及获取

observer: 观察者,负责数据的同步及获取(需要在配置文件中指定才能生效)

ZooKeeper的客户端操作

连接服务

**方式1:**直接连接本地

[root@node1 ~]# zkCli.sh

**方式2:**连接其他节点

[root@node1 ~]# zkCli.sh -server node2

查看所有shell命令：help

常见命令解释:

ls path [watch] : 查看节点信息

get path [watch]: 获取数据

ls2 path [watch]: 查看节点详情信息

create [-s] [-e] path data acl: 创建数据节点

delete path [version]: 删除节点

rmr path: 删多层除节点

set path data [version] ：设置/修改节点数据

history: 查看操作历史

quit: 退出

示例:

[root@node1 ~]# zkCli.sh
...
WatchedEvent state:SyncConnected type:None path:null
[zk: localhost:2181(CONNECTED) 0] ls /
[zookeeper]
[zk: localhost:2181(CONNECTED) 1] create /binzi 666
Created /binzi
[zk: localhost:2181(CONNECTED) 2] create /binzi/b1 111
Created /binzi/b1
[zk: localhost:2181(CONNECTED) 3] create /binzi/b2 222
Created /binzi/b2

[zk: localhost:2181(CONNECTED) 4] ls /
[binzi, zookeeper]
[zk: localhost:2181(CONNECTED) 5] ls /binzi
[b2, b1]
[zk: localhost:2181(CONNECTED) 6] set /binzi 888
...
[zk: localhost:2181(CONNECTED) 7] get /binzi
888
...

[zk: localhost:2181(CONNECTED) 8] delete /binzi/b1
[zk: localhost:2181(CONNECTED) 9] ls /binzi
[b2]

# 注意: delete不能删除有子节点的节点
[zk: localhost:2181(CONNECTED) 10] delete /binzi
Node not empty: /binzi 
# rmr可以删除多层节点
[zk: localhost:2181(CONNECTED) 11] rmr /binzi
[zk: localhost:2181(CONNECTED) 12] ls /
[zookeeper]

[zk: localhost:2181(CONNECTED) 13] history
...
[zk: localhost:2181(CONNECTED) 14] quit
Quitting...shut down
[root@node1 ~]# 

ZooKeeper的数据模型

ZooKeeper的数据模型，在结构上和标准文件系统的非常相似，都是采用树形层次结构，和文件系统的目录树一样，ZooKeeper树中的每个节点可以拥有子节点。

但也有不同之处：

Znode兼具文件和目录两种特点: Znode没有文件和目录之分,Znode既有像文件一样存储数据,也能像目录一样作为路径标识的一部分

Znode具有原子性操作: 读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据

Znode存储数据大小有限制: 每个Znode的数据大小至多1M，当时常规使用中应该远小于此值

Znode通过路径引用:路径必须是绝对的， 因此他们必须由斜杠字符来开头。除此以外，他们必须是唯一的，也就是说每一个路径只有一个表示，因此这些路径不能改变。 **默认已经提供了/zookeeper节点,**用以保存关键的管理信息。

ZooKeeper的节点类型

Znode有两种，分别为 永久节点 和临时节点。节点的类型在创建时即被确定，并且不能改变。

**永久节点：**该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。

注意: 永久节点可以拥有子节点

创建永久节点: create /节点名 节点值

**临时节点：**该节点的生命周期依赖于创建它们的会话。一旦会话结束，临时节点将被自动删除，也可手动删除。

注意: 临时节点不允许拥有子节点。

创建临时节点: create -e /节点名 节点值

ZooKeeper的节点类型

**序列化节点:**Znode还有一个序列化的特性，就是如果创建的时候加 -s 指定的话，该Znode的名字后面会自动追加一个不断增加的序列号。

序列化节点特点: 它的序列号对于此节点的父节点来说是唯一的，这样便会记录每个子节点创建的先后顺序。它的格式为/设定节点名+10位数字，没有数值的数位用0补充，例如'/binzi0000000001'。

创建永久序列化节点: create -s /节点名 节点值

创建临时序列化节点: create -e -s /节点名 节点值

ZooKeeper的节点属性

每个znode都包含了一系列的属性，通过命令get /节点名，可以获得节点的属性

对于zk来说，每次的变化都会产生一个唯一的事务id，zxid（ZooKeeper Transaction Id）。通过zxid，可以确定更新操作的先后顺序。例如，如果zxid1小于zxid2，说明zxid1操作先于zxid2发生，zxid对于整个zk都是唯一的，即使操作的是不同的znode。

**cZxid ：**Znode创建的事务id。

**ctime ：**Znode创建时的时间戳.

**mZxid ：**Znode被修改的事务id，即每次对当前znode的修改都会更新mZxid。

**mtime ：**Znode最新一次更新发生时的时间戳.

**pZxid ：**Znode的子节点列表变更的事务ID，添加子节点或删除子节点就会影响子节点列表

**cversion ：**子节点进行变更的版本号。添加子节点或删除子节点就会影响子节点版本号

**dataVersion：**数据版本号，每次对节点进行set操作，dataVersion的值都会增加1（即使设置的是相同的数据），可有效避免了数据更新时出现的先后顺序问题。

**aclVersion :**权限变化列表版本 access control list Version

ephemeralOwner : 字面翻译临时节点拥有者，持久节点值为0x0，非持久节点不为0（会话ID）

dataLength : Znode数据长度

numChildren: 当前Znode子节点数量(不包括子子节点）

Zookeeper特性

**1. 全局数据一致：**集群中每个服务器保存一份相同的数据副本，client无论连接到哪个服务器，展示的数据都是一致的，这是最重要的特征；

**2. 可靠性：**如果消息被其中一台服务器接受，那么将被所有的服务器接受。

**3. 顺序性：**包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布； 偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。

**4. 数据更新原子性：**一次数据更新要么成功（半数以上节点成功），要么失败，不存在中间状态；

**5. 实时性：**Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。

watch监听机制

ZooKeeper中，引入了Watcher机制来实现数据发布/订阅功能，一个典型的发布/订阅模型系统定义了一种一对多的订阅关系，能让多个订阅者同时监听某一个主题对象，当这个主题对象自身状态变化时，会通知所有订阅者，使他们能够做出相应的处理。

ZooKeeper允许客户端向服务端注册一个Watcher监听，当服务端的一些事件触发了这个Watcher，那么就会向指定客户端发送一个事件通知来实现分布式的通知功能。

watch监听机制过程：

客户端向服务端注册Watcher

服务端事件发生触发Watche

客户端回调Watcher得到触发事件情况

Watch监听机制格式: get /节点名 watch

Watch监听机制特点:

先注册再触发: Zookeeper中的watch机制，必须客户端先去服务端注册监听，这样事件发送才会触发监听，通知给客户端

一次性触发: 事件发生触发监听，一个watcher event就会被发送到设置监听的客户端，这种效果是一次性的，后续再次发生同样的事件，不会再次触发。

异步发送: watcher的通知事件从服务端发送到客户端是异步的。

**通知内容:**通知状态（keeperState），事件类型（EventType）和节点路径（path）

示例

node1上创建临时节点

[zk: localhost:2181(CONNECTED) 1] create -e /master 1111

Created /master

node2上设置监听

[zk: localhost:2181(CONNECTED) 28] get /master watch

node1退出

[zk: localhost:2181(CONNECTED) 2] quit

node2查看消息

[zk: localhost:2181(CONNECTED) 29]

WATCHER::

​

WatchedEvent state:SyncConnected type:NodeDeleted path:/master

Zookeeper典型应用

1. 数据发布/订阅

数据发布/订阅系统,就是发布者将数据发布到ZooKeeper的一个节点上，提供订阅者进行数据订阅，从而实现动态更新数据的目的，实现配置信息的集中式管理和数据的动态更新。

主要用到知识点：监听机制

2. 提供集群选举

在分布式环境下，不管是主从架构集群，还是主备架构集群，要求在服务的时候有且有一个正常的对外提供服务，我们称之为master。

当master出现故障之后，需要重新选举出的新的master。保证服务的连续可用性。zookeeper可以提供这样的功能服务。

主要用到知识点：znode唯一性、临时节点短暂性、监听机制。

集群选举

选举要求: 过半原则,所以搭建集群一般奇数,只要某个node节点票数过半立刻成为leader

集群第一次启动

启动follower每次投票后,他们会相互同步投票情况,如果票数相同,谁的myid大,谁就当选leader

一旦确定了leader,后面来的默认就是follower,即使它的myid大,leader也不会改变(除非leader宕机了)

leader宕机后启动

每一个leader当老大的时候,都会产生新纪元epoch,且每次操作完节点数据都会更新事务id(高32位_低32位) ,当leader宕机后,剩下的follower就会综合考虑几个因素选出最新的leader

先比较最后一次更新数据事务id(高32位_低32位),谁的事务id最大,谁就当选leader

如果更新数据的事务id都相同的情况下,就需要再次考虑myid,谁的myid大,谁就当选leader

hadoop高可用(主备切换)

概述

hadoop2.x之后，Cloudera提出了QJM/Qurom Journal Manager，这是一个基于Paxos算法（分布式一致性算法）实现的HDFS HA方案，它给出了一种较好的解决思路和方案,QJM主要优势如下：不需要配置额外的高共享存储，降低了复杂度和维护成本。消除spof(单点故障)。系统鲁棒性(Robust)的程度可配置、可扩展。

在HA架构里面SecondaryNameNode已经不存在了，为了保持standby NN, 实时的与Active NN的元数据保持一致，他们之间交互通过JournalNode进行操作同步。

任何修改操作在 Active NN上执行时，JournalNode进程同时也会记录修改log到至少半数以上的JN中，这时 Standby NN 监测到JN 里面的同步log发生变化了会读取 JN 里面的修改log,然后同步到自己的目录镜像文件里面

当发生故障时，Active的 NN 挂掉后，Standby NN 会在它成为Active NN 前，读取所有的JN里面的修改日志，这样就能高可靠的保证与挂掉的NN的目录镜像文件一致，然后无缝的接替它的职责，维护来自客户端请求，从而达到一个高可用的目的。

在HA模式下，datanode需要确保同一时间有且只有一个NN能命令DN。为此：每个NN改变状态的时候，向DN发送自己的状态和一个序列号。

DN在运行过程中维护此序列号，当failover时，新的NN在返回DN心跳时会返回自己的active状态和一个更大的序列号。DN接收到这个返回则认为该NN为新的active。

如果这时原来的active NN恢复，返回给DN的心跳信息包含active状态和原来的序列号，这时DN就会拒绝这个NN的命令。

Failover Controller

HA模式下，会将FailoverController部署在每个NameNode的节点上，作为一个单独的进程用来监视NN的健康状态。

FailoverController主要包括三个组件:

**HealthMonitor:**监控NameNode是否处于unavailable或unhealthy状态。当前通过RPC调用NN相应的方法完成。

**ActiveStandbyElector:**监控NN在ZK中的状态。

**ZKFailoverController:**订阅HealthMonitor 和ActiveStandbyElector 的事件，并管理NN的状态,另外zkfc还 负责解决fencing（也就是脑裂问题）。

ZKFailoverController主要职责

**健康监测：**周期性的向它监控的NN发送健康探测命令，从而来确定某个NameNode是否处于健康状态，如果机器宕机，心跳失败，那么zkfc就会标记它处于一个不健康的状态

**会话管理：**如果NN是健康的，zkfc就会在zookeeper中保持一个打开的会话，如果NameNode同时还是Active状态的，那么zkfc还会在Zookeeper中占有一个类型为短暂类型的znode，当这个NN挂掉时，这个znode将会被删除，然后备用的NN将会得到这把锁，升级为主NN，同时标记状态为Active

**master选举：**通过在zookeeper中维持一个短暂类型的znode，来实现抢占式的锁机制，从而判断那个NameNode为Active状态

当宕机的NN新启动时，它会再次注册zookeper，发现已经有znode锁了，便会自动变为Standby状态，如此往复循环，保证高可靠

高可用服务

NN: NameNode
DN: DataNode

​
RM: ResourceManager
NM: NodeManager

​
JN: JournalNode
ZK: ZooKeeper
ZKFC: DFSZKFailoverController

启动hadoop高可用环境

1.先恢复快照到高可用环境

​

2.三台服务器启动zookeeper服务

[root@node1 ~]# zkServer.sh start

[root@node2 ~]# zkServer.sh start

[root@node3 ~]# zkServer.sh start

​

3.在node1中启动hadoop集群

[root@node1 ~]# start-all.sh

​

4.检查服务

[root@node1 ~]# jps

[root@node2 ~]# jps

[root@node3 ~]# jps

NameNode高可用:

web链接:

node1:50070

node2:50070

可以使用==kill -9 NN进程号==把其中主服务杀掉,观察效果,然后使用 ==hdfs --daemon start namenode== 重启,再次观察效果

active: namenode主服务
standby: namenode备份服务

ResourceManager高可用

web链接:

node1:8088

node2:8088

可以使用==kill -9 RM进程号==把其中主服务杀掉,观察效果,然后使用 ==yarn --daemon start resourcemanager== 重启,再次观察效果

注意: 两个服务同时启动,按照上述链接去访问会自动跳到同一个主节点页面