文章目录[隐藏]

一、Zookeeper

一、Zookeeper

Zookeeper 概述

ZooKeeper是一种分布式协调服务，用于管理大型主机。在分布式环境中协调和管理服务是一个复杂的过程。ZooKeeper通过其简单的架构和API解决了这个问题。ZooKeeper允许开发人员专注于核心应用程序逻辑，而不必担心应用程序的分布式特性。

分布式应用

分布式应用可以在给定时间（同时）在网络中的多个系统上运行，通过协调它们以快速有效的方式完成特定任务。通常来说，对于复杂而耗时的任务，非分布式应用（运行在单个系统中）需要几个小时才能完成，而分布式应用通过使用所有系统涉及的计算能力可以在几分钟内完成。

通过将分布式应用配置为在更多系统上运行，可以进一步减少完成任务的时间。分布式应用正在运行的一组系统称为集群，而在集群中运行的每台机器被称为节点。

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

什么是Apache ZooKeeper？

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

ZooKeeper提供的常见服务如下 :

命名服务 - 按名称标识集群中的节点。它类似于DNS，但仅对于节点。

配置管理 - 加入节点的最近的和最新的系统配置信息。

集群管理 - 实时地在集群和节点状态中加入/离开节点。

选举算法 - 选举一个节点作为协调目的的leader。

锁定和同步服务 - 在修改数据的同时锁定数据。此机制可帮助你在连接其他分布式应用程序（如Apache HBase）时进行自动故障恢复。

高度可靠的数据注册表 - 即使在一个或几个节点关闭时也可以获得数据。

分布式应用程序提供了很多好处，但它们也抛出了一些复杂和难以解决的挑战。ZooKeeper框架提供了一个完整的机制来克服所有的挑战。竞争条件和死锁使用故障安全同步方法进行处理。另一个主要缺点是数据的不一致性，ZooKeeper使用原子性解析。

ZooKeeper的架构

看看下面的图表。它描述了ZooKeeper的“客户端-服务器架构”。

作为ZooKeeper架构的一部分的每个组件在下表中进行了说明。

部分	描述
Client（客户端）	客户端，我们的分布式应用集群中的一个节点，从服务器访问信息。对于特定的时间间隔，每个客户端向服务器发送消息以使服务器知道客户端是活跃的。类似地，当客户端连接时，服务器发送确认码。如果连接的服务器没有响应，客户端会自动将消息重定向到另一个服务器。
Server（服务器）	服务器，我们的ZooKeeper总体中的一个节点，为客户端提供所有的服务。向客户端发送确认码以告知服务器是活跃的。
Ensemble	ZooKeeper服务器组。形成ensemble所需的最小节点数为3。
Leader	服务器节点，如果任何连接的节点失败，则执行自动恢复。Leader在服务启动时被选举。
Follower	跟随leader指令的服务器节点。

层次命名空间

下图描述了用于内存表示的ZooKeeper文件系统的树结构。ZooKeeper节点称为 znode 。每个znode由一个名称标识，并用路径(/)序列分隔。

在图中，首先有一个由“/”分隔的znode。在根目录下，你有两个逻辑命名空间 config 和 workers 。

config 命名空间用于集中式配置管理，workers 命名空间用于命名。

在 config 命名空间下，每个znode最多可存储1MB的数据。这与UNIX文件系统相类似，除了父znode也可以存储数据。这种结构的主要目的是存储同步数据并描述znode的元数据。此结构称为 ZooKeeper数据模型。

ZooKeeper数据模型中的每个znode都维护着一个 stat 结构。一个stat仅提供一个znode的元数据。它由版本号，操作控制列表(ACL)，时间戳和数据长度组成。

版本号 - 每个znode都有版本号，这意味着每当与znode相关联的数据发生变化时，其对应的版本号也会增加。当多个zookeeper客户端尝试在同一znode上执行操作时，版本号的使用就很重要。

操作控制列表(ACL) - ACL基本上是访问znode的认证机制。它管理所有znode读取和写入操作。

时间戳 - 时间戳表示创建和修改znode所经过的时间。它通常以毫秒为单位。ZooKeeper从“事务ID"(zxid)标识znode的每个更改。Zxid 是唯一的，并且为每个事务保留时间，以便你可以轻松地确定从一个请求到另一个请求所经过的时间。

数据长度 - 存储在znode中的数据总量是数据长度。你最多可以存储1MB的数据。

Znode的类型

Znode被分为持久（persistent）节点，顺序（sequential）节点和临时（ephemeral）节点。

持久节点 - 即使在创建该特定znode的客户端断开连接后，持久节点仍然存在。默认情况下，除非另有说明，否则所有znode都是持久的。

临时节点 - 客户端活跃时，临时节点就是有效的。当客户端与ZooKeeper集合断开连接时，临时节点会自动删除。因此，只有临时节点不允许有子节点。如果临时节点被删除，则下一个合适的节点将填充其位置。临时节点在leader选举中起着重要作用。

顺序节点 - 顺序节点可以是持久的或临时的。当一个新的znode被创建为一个顺序节点时，ZooKeeper通过将10位的序列号附加到原始名称来设置znode的路径。例如，如果将具有路径 /myapp 的znode创建为顺序节点，则ZooKeeper会将路径更改为 /myapp0000000001 ，并将下一个序列号设置为0000000002。如果两个顺序节点是同时创建的，那么ZooKeeper不会对每个znode使用相同的数字。顺序节点在锁定和同步中起重要作用。

Sessions（会话）

会话对于ZooKeeper的操作非常重要。会话中的请求按FIFO顺序执行。一旦客户端连接到服务器，将建立会话并向客户端分配会话ID 。

客户端以特定的时间间隔发送心跳以保持会话有效。如果ZooKeeper集合在超过服务器开启时指定的期间（会话超时）都没有从客户端接收到心跳，则它会判定客户端死机。

会话超时通常以毫秒为单位。当会话由于任何原因结束时，在该会话期间创建的临时节点也会被删除。

Watches（监视）

监视是一种简单的机制，使客户端收到关于ZooKeeper集合中的更改的通知。客户端可以在读取特定znode时设置Watches。Watches会向注册的客户端发送任何znode（客户端注册表）更改的通知。

Znode更改是与znode相关的数据的修改或znode的子项中的更改。只触发一次watches。如果客户端想要再次通知，则必须通过另一个读取操作来完成。当连接会话过期时，客户端将与服务器断开连接，相关的watches也将被删除。

Zookeeper 工作流

一旦ZooKeeper集合启动，它将等待客户端连接。客户端将连接到ZooKeeper集合中的一个节点。它可以是leader或follower节点。一旦客户端被连接，节点将向特定客户端分配会话ID并向该客户端发送确认。如果客户端没有收到确认，它将尝试连接ZooKeeper集合中的另一个节点。一旦连接到节点，客户端将以有规律的间隔向节点发送心跳，以确保连接不会丢失。

如果客户端想要读取特定的znode，它将会向具有znode路径的节点发送读取请求，并且节点通过从其自己的数据库获取来返回所请求的znode。为此，在ZooKeeper集合中读取速度很快。

如果客户端想要将数据存储在ZooKeeper集合中，则会将znode路径和数据发送到服务器。连接的服务器将该请求转发给leader，然后leader将向所有的follower重新发出写入请求。如果只有大部分节点成功响应，而写入请求成功，则成功返回代码将被发送到客户端。否则，写入请求失败。绝大多数节点被称为 Quorum 。

ZooKeeper集合中的节点

让我们分析在ZooKeeper集合中拥有不同数量的节点的效果。

如果我们有单个节点，则当该节点故障时，ZooKeeper集合将故障。它有助于“单点故障"，不建议在生产环境中使用。

如果我们有两个节点而一个节点故障，我们没有占多数，因为两个中的一个不是多数。

如果我们有三个节点而一个节点故障，那么我们有大多数，因此，这是最低要求。ZooKeeper集合在实际生产环境中必须至少有三个节点。

如果我们有四个节点而两个节点故障，它将再次故障。类似于有三个节点，额外节点不用于任何目的，因此，最好添加奇数的节点，例如3，5，7。

我们知道写入过程比ZooKeeper集合中的读取过程要贵，因为所有节点都需要在数据库中写入相同的数据。因此，对于平衡的环境拥有较少数量（例如3，5，7）的节点比拥有大量的节点要好。

下图描述了ZooKeeper工作流，后面的表说明了它的不同组件。

组件	描述
写入（write）	写入过程由leader节点处理。leader将写入请求转发到所有znode，并等待znode的回复。如果一半的znode回复，则写入过程完成。
读取（read）	读取由特定连接的znode在内部执行，因此不需要与集群进行交互。
复制数据库（replicated database）	它用于在zookeeper中存储数据。每个znode都有自己的数据库，每个znode在一致性的帮助下每次都有相同的数据。
Leader	Leader是负责处理写入请求的Znode。
Follower	follower从客户端接收写入请求，并将它们转发到leader znode。
请求处理器（request processor）	只存在于leader节点。它管理来自follower节点的写入请求。
原子广播（atomic broadcasts）	负责广播从leader节点到follower节点的变化。

Zookeeper leader选举

让我们分析如何在ZooKeeper集合中选举leader节点。考虑一个集群中有N个节点。leader选举的过程如下：

所有节点创建具有相同路径 /app/leader_election/guid_ 的顺序、临时节点。
ZooKeeper集合将附加10位序列号到路径，创建的znode将是 /app/leader_election/guid_0000000001，/app/leader_election/guid_0000000002等。
对于给定的实例，在znode中创建最小数字的节点成为leader，而所有其他节点是follower。
每个follower节点监视下一个具有最小数字的znode。例如，创建znode/app/leader_election/guid_0000000008的节点将监视znode/app/leader_election/guid_0000000007，创建znode/app/leader_election/guid_0000000007的节点将监视znode/app/leader_election/guid_0000000006。
如果leader关闭，则其相应的znode/app/leader_electionN会被删除。
下一个在线follower节点将通过监视器获得关于leader移除的通知。
下一个在线follower节点将检查是否存在其他具有最小数字的znode。如果没有，那么它将承担leader的角色。否则，它找到的创建具有最小数字的znode的节点将作为leader。
类似地，所有其他follower节点选举创建具有最小数字的znode的节点作为leader。

leader选举是一个复杂的过程，但ZooKeeper服务使它非常简单。让我们在下一章中继续学习ZooKeeper安装，以用于开发目的。

zookeeper启动

./zookeeper-3.4.12/bin/zkServer.sh start

JMX enabled by default

Using config: /Users/../zookeeper-3.4.6/bin/../conf/zoo.cfg

Starting zookeeper ... STARTED

./zookeeper-3.4.12/bin/zkServer.sh status

#JMX:Java Management Extensions

docker

Dockerfile:

FROM centos:6.9

ARG myid=1

ADD jdk-8u162-linux-x64.tar.gz /java/

ENV JAVA_HOME=/java/jdk1.8.0_162

ENV PATH=$PATH:$JAVA_HOME/bin

ADD zookeeper-3.5.4-beta.tar.gz /

RUN mkdir -p /var/zookeeper/data

RUN touch /var/zookeeper/data/myid

RUN echo $myid > /var/zookeeper/data/myid

RUN cp /zookeeper-3.5.4-beta/conf/zoo_sample.cfg /zookeeper-3.5.4-beta/conf/zoo.cfg

RUN echo "server.1=192.168.121.1:2888:3888" >> /zookeeper-3.5.4-beta/conf/zoo.cfg

RUN echo "server.2=192.168.121.2:2888:3888" >> /zookeeper-3.5.4-beta/conf/zoo.cfg

RUN echo "server.3=192.168.121.4:2888:3888" >> /zookeeper-3.5.4-beta/conf/zoo.cfg

CMD ["/zookeeper-3.5.4-beta/bin/zkServer.sh","start"]

docker build -t myzookeeper1:v1 --build-arg myid=1 .

docker build -t myzookeeper2:v1 --build-arg myid=2 .

docker build -t myzookeeper3:v1 --build-arg myid=3 .

四字命令

命令	描述
conf	(New in 3.3.0)输出相关服务配置的详细信息。比如端口、zk数据及日志配置路径、最大连接数，session超时时间、serverId等
cons	(New in 3.3.0)列出所有连接到这台服务器的客户端连接/会话的详细信息。包括“接受/发送”的包数量、session id 、操作延迟、最后的操作执行等信息。
crst	(New in 3.3.0)重置当前这台服务器所有连接/会话的统计信息
dump	列出未经处理的会话和临时节点（只在leader上有效）。
envi	输出关于服务器的环境详细信息（不同于conf命令），比如host.name、java.version、java.home、user.dir=/data/zookeeper-3.4.6/bin之类信息
ruok	测试服务是否处于正确运行状态。如果正常返回"imok"，否则返回空。
srst	重置服务器的统计信息
srvr	(New in 3.3.0)输出服务器的详细信息。zk版本、接收/发送包数量、连接数、模式（leader/follower）、节点总数。
stat	输出服务器的详细信息：接收/发送包数量、连接数、模式（leader/follower）、节点总数、延迟。所有客户端的列表。
wchs	(New in 3.3.0)列出服务器watches的简洁信息：连接总数、watching节点总数和watches总数
wchc	(New in 3.3.0)通过session分组，列出watch的所有节点，它的输出是一个与 watch 相关的会话的节点列表。如果watches数量很大的话，将会产生很大的开销，会影响性能，小心使用。
wchp	(New in 3.3.0)通过路径分组，列出所有的 watch 的session id信息。它输出一个与 session相关的路径。如果watches数量很大的话，将会产生很大的开销，会影响性能，小心使用。
mntr	(New in 3.4.0)列出集群的健康状态。包括“接受/发送”的包数量、操作延迟、当前服务模式（leader/follower）、节点总数、watch总数、临时节点总数。

使用四字命令，例：

echo conf | nc 127.0.0.1 2181

1、conf:输出相关服务配置的详细信息。

输出结果：

clientPort=2181 #客户端端口号

dataDir=/var/lib/zookeeper/version-2 数据文件目录

dataLogDir=/var/lib/zookeeper/version-2 #日志文件目录

tickTime=2000 间隔单位时间

maxClientCnxns=50 最大连接数

minSessionTimeout=4000 最小session超时

maxSessionTimeout=40000 最大session超时

serverId=0 id

2、cons：列出所有连接到这台服务器的客户端连接/会话的详细信息。

输出结果：

/127.0.0.1:50788[1](queued=0,recved=2875,sent=2876,sid=0x1651c50045a000a,lop=PING,est=1533791548370,to=10000,lcxid=0x5b6b999e,lzxid=0x18d6,lresp=1533801122620,llat=1,minlat=0,avglat=0,maxlat=5)

/127.0.0.1:52916[0](queued=0,recved=1,sent=0)

/127.0.0.1:50800[1](queued=0,recved=2869,sent=2870,sid=0x1651c50045a000f,lop=PING,est=1533791568845,to=10000,lcxid=0x5b6bcd5e,lzxid=0x18d6,lresp=1533801122851,llat=1,minlat=0,avglat=0,maxlat=20)

/127.0.0.1:50794[1](queued=0,recved=2868,sent=2868,sid=0x1651c50045a000d,lop=PING,est=1533791568824,to=10000,lcxid=0x5b6bcd5a,lzxid=0x18d6,lresp=1533801122676,llat=0,minlat=0,avglat=0,maxlat=20)

/127.0.0.1:50796[1](queued=0,recved=2869,sent=2870,sid=0x1651c50045a000e,lop=PING,est=1533791568828,to=10000,lcxid=0x5b6bcd5d,lzxid=0x18d6,lresp=1533801122812,llat=0,minlat=0,avglat=0,maxlat=25)

/127.0.0.1:50798[1](queued=0,recved=2868,sent=2868,sid=0x1651c50045a0010,lop=PING,est=1533791568844,to=10000,lcxid=0x5b6bcd5b,lzxid=0x18d6,lresp=1533801122681,llat=1,minlat=0,avglat=0,maxlat=20)

解释：

ip:端口（queued=所在队列，received=收包数，sent=发包数，sid=session id，lop=最后操作，est=连接时间戳，to=超时时间，lcxid=最后id(未确认具体id)，lzxid=最后id(状态变更id)，lresp=最后响应时间戳，llat=最后/最新延时，minlat=最小延时，maxlat=最大延时，avglat=平均延时）

3、crst:重置当前这台服务器所有连接/会话的统计信息。

输出结果：

Connection stats reset.

4、dump:列出未经处理的会话和临时节点（只在leader上有效）。

输出结果：

SessionTracker dump:

Session Sets (3):

0 expire at Thu Aug 09 15:59:04 CST 2018:

0 expire at Thu Aug 09 15:59:08 CST 2018:

5 expire at Thu Aug 09 15:59:10 CST 2018:

0x1651c50045a000d

0x1651c50045a000a

0x1651c50045a000e

0x1651c50045a0010

0x1651c50045a000f

ephemeral nodes dump:

Sessions with Ephemerals (2):

0x1651c50045a000e:

/mesos/json.info_0000000151

0x1651c50045a000d:

/mesos/log_replicas/0000000151

5、envi:输出关于服务器的环境详细信息（不同于conf命令）。

输出结果：

Environment:

zookeeper.version=3.4.6-1569965, built on 02/20/2014 09:09 GMT #zookeeper版本

host.name=localhost #host信息

java.version=1.8.0_171 #java版本

java.vendor=Oracle Corporation #java供应商

java.home=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.171-8.b10.el7_5.x86_64/jre #jdk目录

java.class.path=/opt/mesosphere/zookeeper/bin/../build/classes:/opt/mesosphere/zookeeper/bin/../build/lib/*.jar:/opt/mesosphere/zookeeper/bin/../lib/slf4j-log4j12-1.6.1.jar:/opt/mesosphere/zookeeper/bin/../lib/slf4j-api-1.6.1.jar:/opt/mesosphere/zookeeper/bin/../lib/netty-3.7.0.Final.jar:/opt/mesosphere/zookeeper/bin/../lib/log4j-1.2.16.jar:/opt/mesosphere/zookeeper/bin/../lib/jline-0.9.94.jar:/opt/mesosphere/zookeeper/bin/../zookeeper-3.4.6.jar:/opt/mesosphere/zookeeper/bin/../src/java/lib/*.jar:/etc/zookeeper/conf:

java.library.path=/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib

java.io.tmpdir=/tmp #temp目录

java.compiler=<NA>

os.name=Linux

os.arch=amd64

os.version=3.10.0-862.3.2.el7.x86_64

user.name=root

user.home=/root

user.dir=/opt/mesosphere/zookeeper

6、ruok:测试服务是否处于正确运行状态。如果正常返回"imok"，否则返回空。

7、srst:重置服务器的统计信息。

输出结果：

Server stats reset.

8、srvr：输出服务器的详细信息。

输出结果：

Zookeeper version: 3.4.6-1569965, built on 02/20/2014 09:09 GMT #Zookeeper版本

Latency min/avg/max: 0/0/1 #延时

Received: 26 #收包数

Sent: 26 #发包数

Connections: 6 #连接数

Outstanding: 0 #堆积数

Zxid: 0x18d6 #操作id

Mode: standalone #服务器类型

Node count: 77 #节点数

9、stat：输出服务器的详细信息。

输出结果：

Zookeeper version: 3.4.6-1569965, built on 02/20/2014 09:09 GMTClients: /192.168.147.102:56168[1](queued=0,recved=41,sent=41) /192.168.144.102:34378[1](queued=0,recved=54,sent=54) /192.168.162.16:43108[1](queued=0,recved=40,sent=40) /192.168.144.107:39948[1](queued=0,recved=1421,sent=1421) /192.168.162.16:43112[1](queued=0,recved=54,sent=54) /192.168.162.16:43107[1](queued=0,recved=54,sent=54) /192.168.162.16:43110[1](queued=0,recved=53,sent=53) /192.168.144.98:34702[1](queued=0,recved=41,sent=41) /192.168.144.98:34135[1](queued=0,recved=61,sent=65) /192.168.162.16:43109[1](queued=0,recved=54,sent=54) /192.168.147.102:56038[1](queued=0,recved=165313,sent=165314) /192.168.147.102:56039[1](queued=0,recved=165526,sent=165527) /192.168.147.101:44124[1](queued=0,recved=162811,sent=162812) /192.168.147.102:39271[1](queued=0,recved=41,sent=41) /192.168.144.107:45476[1](queued=0,recved=166422,sent=166423) /192.168.144.103:45100[1](queued=0,recved=54,sent=54) /192.168.162.16:43133[0](queued=0,recved=1,sent=0) /192.168.144.107:39945[1](queued=0,recved=1825,sent=1825) /192.168.144.107:39919[1](queued=0,recved=325,sent=325) /192.168.144.106:47163[1](queued=0,recved=17891,sent=17891) /192.168.144.107:45488[1](queued=0,recved=166554,sent=166555) /172.17.36.11:32728[1](queued=0,recved=54,sent=54) /192.168.162.16:43115[1](queued=0,recved=54,sent=54) Latency min/avg/max: 0/0/599Received: 224869Sent: 224817Connections: 23Outstanding: 0Zxid: 0x68000af707Mode: followerNode count: 101081

10、wchs:列出服务器watches的简洁信息。

输出结果：

0 connections watching 0 paths

Total watches:0

11、wchc:通过session分组，列出watch的所有节点，它的输出是一个与 watch 相关的会话的节点列表。如果watches数量很大的话，将会产生很大的开销，会影响性能，小心使用。

session id 对应 path

12、wchp:通过路径分组，列出所有的 watch 的session id信息。它输出一个与 session相关的路径。如果watches数量很大的话，将会产生很大的开销，会影响性能，小心使用。

path 对应 session id

13、mntr:列出集群的健康状态。

输出结果：

zk_version 3.4.6-1569965, built on 02/20/2014 09:09 GMT #版本

zk_avg_latency 0 #平均延时

zk_max_latency 1 #最大延时

zk_min_latency 0 #最小延时

zk_packets_received 297 #收包数

zk_packets_sent 297 #发包数

zk_num_alive_connections 6 #连接数

zk_outstanding_requests 0 #堆积请求数

zk_server_state standalone #服务器状态

zk_znode_count 77 #znode数量

zk_watch_count 5 #watch数量

zk_ephemerals_count 2 #临时节点数量

zk_approximate_data_size 7434 #数据大小

zk_open_file_descriptor_count 33 #打开的文件描述符数量

zk_max_file_descriptor_count 4096 #最大文件描述符数量

ZooKeeper命令行界面命令：

$ ./bin/zkCli.sh

Connecting to localhost:2181

................

Welcome to ZooKeeper!

................

WATCHER::

WatchedEvent state:SyncConnected type: None path:null

[zk: localhost:2181(CONNECTED) 0] #进入Cli命令行

1、create创建znode节点

持久节点，/FirstZnode为节点名称，"Myfirstzookeeper-app"为节点数据内容：

create /FirstZnode "Myfirstzookeeper-app"

顺序节点。保证znode路径将是唯一的：

create -s /FirstZnode "second-data"

临时节点。当客户端断开连接时，临时节点将被删除：

create -e /SecondZnode "Ephemeral-data"

2、get获取数据

get [-s] /path

3、get -w监视znode的变化

当指定的znode或znode的子数据更改时，监视器会显示通知。

get -w /FirstZnode

4、set设置数据

set /FirstZnode "weakness"

5、create创建znode的子节点

create /FirstZnode/Child1 "firstchildren"

6、ls列出znode的子节点

ls /MyFirstZnode

7、stat检查状态

stat /FirstZnode

结果包含时间戳，版本号，ACL，数据长度和子znode等细项:

cZxid	创建节点时的事务ID
ctime	创建节点时的时间
mZxid	最后修改节点时的事务ID
mtime	最后修改节点时的时间
pZxid	表示该节点的子节点列表最后一次修改的事务ID，添加子节点或删除子节点就会影响子节点列表，但是修改子节点的数据内容则不影响该ID
cversion	子节点版本号，子节点每次修改版本号加1
dataversion	数据版本号，数据每次修改该版本号加1
aclversion	权限版本号，权限每次修改该版本号加1
dataLength	该节点的数据长度
numChildren	该节点拥有子节点的数量