ZooKeeper

ZooKeeper：ZooKeeper是一种分布式协调服务，用于管理大型主机。

分布式应用：分布式应用可以在给定时间（同时）在网络中的多个系统上运行，通过协调它们以快速有效的方式完成特定任务

分布式应用有两部分：Server（服务器）和 Client（客户端）应用程序。

服务器应用程序：实际上是分布式的，并具有通用接口，以便客户端可以连接到集群中的任何服务器并获得相同的结果。
客户端应用程序：是与分布式应用进行交互的工具。

分布式应用的优点：

可靠性：单个或几个系统的故障不会使整个系统出现故障。
可扩展性：可以在需要时增加性能，通过添加更多机器，在应用程序配置中进行微小的更改，而不会有停机时间。
透明性：隐藏系统的复杂性，并将其显示为单个实体/应用程序。

分布式应用的缺点：

竞争条件：两个或多个机器尝试执行特定任务，实际上只需在任意给定时间由单个机器完成。例如，共享资源只能在任意给定时间由单个机器修改。
死锁：两个或多个操作等待彼此无限期完成
不一致：数据的部分失败。

Apache ZooKeeper是由集群（节点组）使用的一种服务，用于在自身之间协调，并通过稳健的同步技术维护共享数据。ZooKeeper本身是一个分布式应用程序，为写入分布式应用程序提供服务。

ZooKeeper集群奇数个节点的原因：

防止由脑裂造成的集群不可用
在容错能力相同的情况下，奇数台更节省资源。

ZooKeeper提供的常见服务如下 :

命名服务：按名称标识集群中的节点。它类似于DNS，但仅对于节点。
配置管理：加入节点的最近的和最新的系统配置信息。
集群管理：实时地在集群和节点状态中加入/离开节点。
选举算法：选举一个节点作为协调目的的leader。
分布式锁和队列同步服务：在修改数据的同时锁定数据。此机制可帮助你在连接其他分布式应用程序（如Apache HBase）时进行自动故障恢复。
高度可靠的数据注册表：即使在一个或几个节点关闭时也可以获得数据。

ZooKeeper的好处：

简单的分布式协调过程
最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。
实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。
序列化：根据特定规则对数据进行编码。确保应用程序运行一致。这种方法可以在MapReduce中用来协调队列以执行运行的线程。
可靠性：具有简单、健壮、良好的性能，如果消息m被到一台服务器接受，那么它将被所有的服务器接受。
原子性：数据转移完全成功或完全失败，但没有事务是部分的。
等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。

分布式与数据复制：Zookeeper作为一个集群提供一致的数据服务，自然，它要在所有机器间做数据复制。

数据复制的好处：

容错：一个节点出错，不致于让整个系统停止工作，别的节点可以接管它的工作；
提高系统的扩展能力：把负载分布到多个节点上，或者增加节点来提高系统的负载能力；
提高性能：让客户端本地访问就近的节点，提高用户访问速度。

从客户端读写访问的透明度来看，数据复制集群系统分下面两种：

写主(WriteMaster)：对数据的修改提交给指定的节点。读无此限制，可以读取任何一个节点。这种情况下客户端需要对读与写进行区别，俗称读写分离；
写任意(Write Any)：对数据的修改可提交给任意的节点，跟读一样。这种情况下，客户端对集群节点的角色与变化透明。

zookeeper安装：

独立配置的ZooKeeper集群，进程名称QuorumPeerMain

单机模式

Zookeeper 的配置文件在 conf 目录下，这个目录下有 zoo_sample.cfg 和 log4j.properties，你需要做的就是将 zoo_sample.cfg 改名为 zoo.cfg，因为 Zookeeper 在启动时会找这个文件作为默认配置文件。

1  tickTime=2000
2  dataDir=D:/devtools/zookeeper-3.2.2/build 
3  clientPort=2181

下面详细介绍一下，这个配置文件中各个配置项的意义。

tickTime：这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个 tickTime 时间就会发送一个心跳。
dataDir：顾名思义就是 Zookeeper 保存数据的目录，默认情况下，Zookeeper 将写数据的日志文件也保存在这个目录里。
clientPort：这个端口就是客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。

集群模式

集群模式除了上面的三个配置项还要增加下面几个配置项：

1.  initLimit=5 
2.  syncLimit=2 
3.  server.1=192.168.211.1:2888:3888 
4.  server.2=192.168.211.2:2888:3888

initLimit：这个配置项是用来配置 Zookeeper 接受客户端（这里所说的客户端不是用户连接 Zookeeper 服务器的客户端，而是 Zookeeper 服务器集群中连接到 Leader 的 Follower 服务器）初始化连接时最长能忍受多少个心跳时间间隔数。当已经超过 10 个心跳的时间（也就是 tickTime）长度后 Zookeeper 服务器还没有收到客户端的返回信息，那么表明这个客户端连接失败。总的时间长度就是 5 * 2000=10 秒
syncLimit：这个配置项标识 Leader 与 Follower 之间发送消息，请求和应答时间长度，最长不能超过多少个 tickTime 的时间长度，总的时间长度就是 2 * 2000=4 秒
server.A=B：C：D：其中 A 是一个数字，表示这个是第几号服务器；B 是这个服务器的 ip 地址；C 表示的是这个服务器与集群中的 Leader 服务器交换信息的端口；D 表示的是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader，而这个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配置方式，由于 B 都是一样，所以不同的 Zookeeper 实例通信端口号不能一样，所以要给它们分配不同的端口号。

zookeeper的节点类型：

PERSISTENT（持久化目录节点）：客户端与zookeeper断开连接后，该节点依旧存在
PERSISTENT_SEQUENTIAL（持久化顺序编号目录节点）：客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
EPHEMERAL（临时目录节点）：客户端与zookeeper断开连接后，该节点被删除
EPHEMERAL_SEQUENTIAL（临时顺序编号目录节点）：客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

ZooKeeper 角色：（zookeeper服务主要有两个角色leader和follower）

在这里插入图片描述

ZooKeeper工作原理：

Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。
为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。

每个Server在工作过程中有三种状态：

LOOKING：当前Server不知道leader是谁，正在搜寻
LEADING：当前Server即为选举出来的leader
FOLLOWING：leader已经选举出来，当前Server与之同步

zookeeper中的命令

连接到Zookeeper服务

zkCli.sh -server hadoop2:2181

可用命令

help

使用ls命令查看当前Zookeeper中所包含的内容

ls

创建一个新的Znode节点"aa"，以及和它相关字符，默认是不带编号的

create /aa "my first zk"

创建带编号的持久性节点"bb"，

create -s /bb "the bb node"

创建不带编号的临时节点"cc"

create -e /cc "the cc node"

创建带编号的临时节点"dd"

create -s -e /dd "the dd node"

关闭本次连接回话session，再重新打开一个连接

close
connect haddoop1:2181

获取节点

get /aa

通过set命令来对zk所关联的字符串进行设置

set /aa haha123

删除节点

delete /aa

退出

quit

查看一个文件的状态信息

stat /a

close
connect haddoop1:2181