**Hadoop纵览之(四)分布式应用程序协调服务工具Zookeeper**

1. 官网介绍

Welcome to Apache ZooKeeper™
欢迎来到Apache Zookeeper的世界。

Apache ZooKeeper is an effort to develop and maintain an open-source server which enables highly reliable distributed coordination.
Apache ZooKeeper致力于开发和维护开源的支持高度可靠的分布式协作服务器

What is ZooKeeper?
Zookeeper是什么？

ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications. Each time they are implemented there is a lot of work that goes into fixing the bugs and race conditions that are inevitable. Because of the difficulty of implementing these kinds of services, applications initially usually skimp on them ,which make them brittle in the presence of change and difficult to manage. Even when done correctly, different implementations of these services lead to management complexity when the applications are deployed.

ZooKeeper是一个集中的服务，用于维护配置信息、命名、提供分布式同步和提供组服务。所有这些类型的服务都以某种形式被分布式应用程序使用。每次实现它们时，都有许多工作要做，以修复不可避免的bug和竞争条件。由于实现这类服务的困难度，应用程序最初通常会对它们进行’吝啬’操作，这使得它们在出现更改时变得脆弱，难以管理。即使操作正确，在部署应用程序时，这些服务的不同实现也会导致管理复杂性。

2. 概念理解

ZooKeeper是一个分布式的，开源的分布式应用程序协调服务，ZooKeeper是以Fast Paxos协议为基础，实现同步服务，配置维护和命名服务等分布式应用。 ZooKeeper 意欲设计一个易于编程的环境，它的文件系统使用我们所熟悉的目录树结构。 ZooKeeper 使用 Java 所编写，但是支持 Java 和 C 两种编程语言。
众所周知，协调服务非常容易出错，但是却很难恢复正常，例如，协调服务很容易处于竞态以至于出现死锁。设计 ZooKeeper 的目的是为了减轻分布式应用程序所承担的协调任务。

Zookeeper是一个分布式协调服务；就是为用户的分布式应用程序提供协调服务
1、Zookeeper是为别的分布式程序服务的
2、Zookeeper本身就是一个分布式程序（只要有半数以上节点存活，zk就能正常服务）
3、Zookeeper所提供的服务涵盖：主从协调、服务器节点动态上下线、统一配置管理、分布式共享锁、统一名称服务……
4、虽然说可以提供各种服务，但是zookeeper在底层其实只提供了两个功能：
a、管理(存储，读取)用户程序提交的数据；
b、并为用户程序提供数据节点监听服务；

3. Zookeeper的基本概念

3.1 集群角色

通常在分布式系统中，构成一个集群的每一台机器都有自己的角色，最典型的集群模式是Master/Slave模式（主从模式）。在这种模式中，我们把能够处理所有写操作的机器称为Master，把所有通过异步复制方式获取最新数据，并提供读服务的机器称为Slave机器。
Hadoop就是一个典型的案例。
而在zookeeper中，这些概念被颠覆了。它没有沿用传统的Master/Slave概念，而是引入了Leader、Follower和Observer（3.3版本开始启用）三种角色。Zookeeper集群中的所有机器通过一个Leader选举过程来选定一台称为“Leader”的机器，Leader服务器为客户端系统读和写服务。除Leader外，其他机器包括Follower和Observer。Follower和Observer都能够提供读服务，唯一的区别在于，Observer机器不参与Leader选举过程，也不参与写操作的“过半写成功”策略，因此Observer可以在不影响写性能的情况下提升集群的读性能。总结如下图所示

3.2 系统模型

3.3 会话（Session）

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

3.4 数据节点（Znode）

在分布式中我们通常说的“节点”是指组成集群的每一台机器。然而，在Zookeeper中，“节点”分为两类，第一类同样是指构成集群的机器，我们称之为机器节点。第二类则是指数据模型中的数据单元，我们称之为数据节点——Znode。Zookeeper将所有数据存储在内存中，数据模型是一棵树（ZNode Tree），由斜杠（/）进行分割的路径，就是一个Znode，例如/foo/path1。每个ZNode上都会保存自己的数据内容，同时还会保存一系属性信息。

在Zookeeper中，ZNode可以分为持久节点和临时节点两类。所谓持久节点是指一旦这个ZNode被创建了，除非主动进行ZNode的移除操作，否则ZNode将一直保存在Zookeeper上。而临时节点就不一样了，他的生命周期和客户会话绑定，一旦客户端会话失效，那么这个客户端创建的所有临时节点都会被删除。另外，Zookeeper还允许用户为每一个节点添加一个特殊的属性SEQUENTIAL。一旦节点被标记上这个属性，那么在这个节点被创建的时候，Zookeeper会自动在其节点名后面追加上一个整形数字，这个整形数字是由父节点维护的自增数字。
Zookeeper在各种分布式场景下发挥作用的主要方式就是数据节点和监控器，我们可以给数据节点赋予任意我们想赋予的含义，来协助我们更好的处理分布式程序中所面临的问题。

3.5 版本

Zookeeper的每个ZNode上都会存储数据，对应于每个ZNode，Zookeeper都会为其维护一个叫作stat的数据结构，stat中记录了这个ZNode的三个数据版本，分别是version（当前ZNode的版本）、cversion（当前ZNode子节点的版本）和aversion（当前ZNode的acl版本）。
Acl: access control list（防火墙）

3.6 Watcher

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

3.7 ACL

Zookeeper采用ACL（Access Control Lists）策略来进行权限控制，类似于UNIX文件系统的权限控制。Zookeeper定义了如下5种权限。
CREATE：创建子节点的权限。
READ：获取子节点数据和子节点列表的权限。
WRITE：更新节点数据的权限。
DELETE：删除子节点的权限。
ADMIN：设置节点ACL的权限。

4.Zookeeper的设计目的

1.最终一致性：client不论连接到哪个server，展示给它都是同一个视图，这是Zookeeper最重要的性能。
2.可靠性：具有简单、健壮、良好的性能，如果消息m被一台服务器接受，那么它将被所有的服务器接受。
3.实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。
4.等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。
5.原子性：更新只能成功或者失败，没有中间状态。
6.顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面

5.Zookeeper是怎样保证自身的高可用的？

首先可以想到的是，假如Zookeeper只有一个的话，其也无法保证其自身的高可用，所以zookeeper本身也是以集群的形式存在的。对比学校大门的安保问题，我们很容易能都想到的一种方法是可以有多个Zookeeper，在某一时刻由一个主要的Zookeeper对外提供服务，当其出现问题时，从剩下的多个Zookeeper中快速选出来一个继续对外提供服务就可以了。Zookeeper本身就是基于这种思想来设计的。

Zookeeper采用了一个称之为ZAB的协议来保证自身的高可用。其来源于Paxos选举协议，其也是一个用来保证分布式一致的一个经典协议。在历史上，Paxos协议是从二阶段提交协议演变到三阶段提交协议之后再演变成的。

在分布式系统中，每一个机器节点虽然都能够明确的知道自己在进行事务操作过程中的结果是成功或失败，但是无法直接获取到其他分布式节点的操作结果（需要通过网络进行结果传输）。因此，当一个事务操作需要跨越多个分布式节点的时候，为了保持事务处理的ACID（原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability））特性，就需要引入一个称之为“协调者（Coordinator）”的组件来统一调度所有分布式节点的执行逻辑，这些被调度的分布式节点则被称为“参与者”（Participant）。协调者负责调度参与者的行为，并最终决定这些参与者是否要把事务真正提交。基于这个思想，衍生出了二阶段提交和三阶段提交两种协议两种一致性算法。
生活中大部分工作的形式都是分布式的，比如我们将来最常见的工作情景：项目经理将一个大项目分成了前后台（或者更多的部分），指派给不同的员工，每个人只负责自己的事情，所有干活的员工就是参与者的角色，项目经理就是协调者的角色。

6.Zookeeper集群模式的安装

官网
http://zookeeper.apache.org/
下载地址
http://apache.opencas.org/zookeeper/

从官方网站上下载tar.gz包，我们这里使用的是：zookeeper-3.4.7.tar.gz
安装前的准备
本安装示例中的zk集群共有三台机器，机器名分别为master、slave1、slave2
安装步骤
将gz文件放置在一个合适的地方，例如：/home/bigdata
注意：以下举例中zookeeper所在的地址为/home/bigdata

将gz文件解压缩：
> tar –xzvf zookeeper-3.4.7.tar.gz

将解压后的文件重命名成zookeeper：
> mv zookeeper-3.4.7 zookeeper

使用多台机器，确保每台机器的配置文件中都写上下列配置

创建新目录
#mkdir /home/bigdata/zookeeper/zkmyid
创建新文件
#vi /home/bigdata/zookeeper/zkmyid/myid
修改myid文件内容
#vi /home/bigdata/zookeeper/zkmyid/myid

创建新文件
Vi /home/bigdata/zookeeper/conf/zoo.cfg
多台机器中每台机器的配置文件内容都相同，内容如下：
tickTime=2000
initLimit=10
syncLimit=5
dataDir=/home/bigdata/zkmyid
clientPort=2181
server.1=master:2888:3888
server.2=slave1:2888:3888
server.3=slave2:2888:3888

配置每台机器上的myid文件（保证每台服务器的唯一性）
每一台机器都需要做如下操作：
在上面的配置项dataDir所指定的地址下新建一个名字为myid的文件，文件中的内容对应为server.后面的数字

export ZK_HOME=/bigdata/zookeeper
exprt PATH=PATH:PATH:PATH:ZK_HOME/bin:$ZK_HOME/conf

7.Zookeeper 典型应用场景

7.1 HDFS HA

前言：正式引入HA机制是从hadoop2.0开始，之前的版本中没有HA机制

注意，在 Hadoop 2.0 中，不再需要 secondary namenode 或者 backup namenode，它们的 工作由 Standby namenode 承担

（1）hadoop-HA集群运作机制介绍
所谓HA，即高可用（7*24小时不中断服务）
实现高可用最关键的是消除单点故障
hadoop-ha严格来说应该分成各个组件的HA机制——HDFS的HA、YARN的HA

（2）HDFS的HA机制详解
通过双namenode消除单点故障
双namenode协调工作的要点：
A、元数据管理方式需要改变：
内存中各自保存一份元数据
Edits日志只能有一份，只有Active状态的namenode节点可以做写操作
两个namenode都可以读取edits
共享的edits放在一个共享存储中管理（qjournal和NFS两个主流实现）
B、需要一个状态管理功能模块
实现了一个zkfailover，常驻在每一个namenode所在的节点
每一个zkfailover负责监控自己所在namenode节点，利用zk进行状态标识
当需要进行状态切换时，由zkfailover来负责切换
切换时需要防止brain split现象的发生

7.2服务器上下线动态感知

某分布式系统中，主节点可以有多台，可以动态上下线
任意一台客户端都能实时感知到主节点服务器的上下线

7.3基于zookeeper的配置管理中心

7.3.1使用场景

配置中心一般用作系统的参数配置，它需要满足如下几个要求：高效获取、实时感知、分布式访问。对于一些少量频次访问的场景我们可以使用mysql数据库实现，但是有些参数在系统中访问频次较高，甚至是接口每访问一次就需要调起获取一次，特别在是大规模系统访问量的情况下，我们就需要一个高效获取实时感知的分布式配置中心。我们使用Zookeeper来实现一个分布式配置管理中心组件

7.3.2实现逻辑

7.4分布式共享锁

7.4.1、需求描述

在我们自己的分布式业务系统中，可能会存在某种资源，需要被整个系统的各台服务器共享访问，但是只允许一台服务器同时访问

7.4.2、设计思路

7.4.3实现步骤

利用 Zookeeper 实现分布式共享锁的步骤大致可以分为以下几步：

1. 客户端上线即向 Zookeeper 注册，创建一把锁
2. 判断是否只有一个客户端工作，若只有一个客户端工作，此客户端可以处理业务
3. 若否,获取父节点下注册的所有锁，通过判断自己是否是号码最小的那一把锁，若是则可以处理业务，否则等待
   值的注意的是，在某一客户端获取到锁处理完业务后，必须释放锁

8.原理补充

8.1 zookeeper的选举机制（zk的数据一致性核心算法paxos）

以一个简单的例子来说明整个选举的过程.
假设有五台服务器组成的Zookeeper集群,它们的id从1-5,同时它们都是最新启动的,也就是没有历史数据,在存放数据量这一点上,都是一样的.假设这些服务器依序启动,来看看会发生什么。

1、 服务器1启动,此时只有它一台服务器启动了,它发出去的报没有任何响应,所以它的选举状态一直是LOOKING状态
2、服务器2启动,它与最开始启动的服务器1进行通信,互相交换自己的选举结果,由于两者都没有历史数据,所以id值较大的服务器2胜出,但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3),所以服务器1,2还是继续保持LOOKING状态.
3、服务器3启动,根据前面的理论分析,服务器3成为服务器1,2,3中的老大,而与上面不同的是,此时有三台服务器选举了它,所以它成为了这次选举的leader.
4、 服务器4启动,根据前面的分析,理论上服务器4应该是服务器1,2,3,4中最大的,但是由于前面已经有半数以上的服务器选举了服务器3,所以它只能接收当follower的命了.
5、服务器5启动,同4一样,当follower.

8.2 非全新集群的选举机制(数据恢复)

那么，初始化的时候，是按照上述的说明进行选举的，但是当Zookeeper运行了一段时间之后，有机器down掉，重新选举时，选举过程就相对复杂了。
需要加入数据version、leader id和逻辑时钟。
数据version：数据新的version就大，数据每次更新都会更新version。
Leader id：就是我们配置的myid中的值，每个机器一个。
逻辑时钟：这个值从0开始递增,每次选举对应一个值,也就是说: 如果在同一次选举中,那么这个值应该是一致的 ; 逻辑时钟值越大,说明这一次选举leader的进程更新.
选举的标准就变成：
1、逻辑时钟小的选举结果被忽略，重新投票
2、统一逻辑时钟后，数据version大的胜出
3、数据id相同的情况下，leader id大的胜出
根据这个规则选出leader。