zookeeper服务管理页面 zookeeper 管理

zookeeper是一个开源的分布式的，为分布式应用提供协调服务的apache，zookeeper=文件系统和通知机制

zookeeper的工作机制

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

zookeeper的特点

• 1、zookeeper：一个领导者（leader），多个跟谁者（follower）组成的集群。
• 2、集群中只有半数以上节点存活，zookeeper集群就能正常服务
• 3、全局数据一致，每个server保存一份相同的数据副本，client无论连接到那个server，数据都是一致的
• 4、更新请求顺序进行，来自同一个client的更新请求安其发送顺序依次执行。
• 5、数据更新原子性，一次数据更新要么成功，要么失败。
• 6、实时性，在一定时间范围内，client能读到最新的数据。

数据结构

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

 

应用场景

提供的服务包括：统一命名服务、统一配置管理、统一集群管理、服务节点动态上下线、软负载均衡。

统一命名服务：

• 在分布式环境下，经常需要对应用/服务进行统一命名，便于识别。

统一配置管理：

1、分布式环境下，配置文件同步非常常见

• 1.1、一般要求一个集群中，所有节点的配置信息是一致的，比如kafka集群。
• 1.2、对配置文件修改后，希望能够快速同步到各个节点上。

2、配置管理可交由zookeeper实现

• 2.1、颗将配置信息写入zookeeper上的znode。
• 2.2、各个客户端服务器监听这个znode。
• 2.3、一旦znode中的数据被修改，zookeeper将通知各个客户端服务器。

统一集群管理

1、分布式环境中，实时掌握每个节点的状态是必要的。

• 1.1、可根据节点实时状态做出一些调整。

2、zookeeper可以实现实时监控节点状态的变化

• 2.1、可将节点信息写入zookeeper上的一个znode。
• 2.2、监听这个znode可获取它的实时状态变化。

服务器动态上下线

客户端实时洞察到服务器上下线的变化

软负载均衡

• 在zookeeper中记录每台服务器的访问数，让访问数少量的服务器去处理最新的客户端请求

zookeeper内部原理

1、半数机制：集群中半数以上机器存活，集群可用。所以zookeeper适合安装奇数台服务器。（单点故障）

2、zookeeper虽然在配置文件中并没有指定master和slave。但是，zookeeper工作时，是有一个节点为leader，其他则为follower，leader是通过内部的选举机制零时产生的。

3、以一个简单的例子来说明整个选举的过程。假设有五台服务器组成的zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这点上，都是一样的。假设这些服务器依次启动。第一台服务器，起来之后，先给自己投一票，如果没有达到半数以上，就投它人...其他服务器都是这样，直到选到leader

 选举机制：（两种情况）

（1）全新集群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,所以它只能接收当小弟的命了.
• 　　5) 服务器5启动,同4一样,当小弟.

（2）非全新集群（数据恢复）

初始化的时候，是按照上述的说明进行选举的，但是当zookeeper运行了一段时间之后，有机器down掉，重新选举时，选举过程就相对复杂了。

需要加入数据id、leader id和逻辑时钟。

• 　　数据id：数据新的id就大，数据每次更新都会更新id。
• 　　Leader id：就是我们配置的myid中的值，每个机器一个。
• 　　逻辑时钟：这个值从0开始递增,每次选举对应一个值,也就是说:  如果在同一次选举中,那么这个值应该是一致的 ;  逻辑时钟值越大,说明这一次选举leader的进程更新.

选举的标准就变成：

• 　　1、逻辑时钟小的选举结果被忽略，重新投票
• 　　2、统一逻辑时钟后，数据id大的胜出
• 　　3、数据id相同的情况下，leader id大的胜出

根据这个规则选出leader。

znode节点数据模型

znode是zookeeper树形结构中存储数据的节点，它的组成为 :

path(路径) + value（值）+stat（状态&属性）

znode维护了一个stat结构，这个stat包含数据变化的版本号、访问控制列表变化、还有时间戳。版本号和时间戳一起，可让Zookeeper验证缓存和协调更新。每次znode的数据发生了变化，版本号就增加。

例如，无论何时客户端检索数据，它也一起检索数据的版本号。并且当客户端执行更新或删除时，客户端必须提供他正在改变的znode的版本号。如果它提供的版本号和真实的数据版本号不一致，更新将会失败。

znode节点存在类型（临时&持久）

znode是由连接到zookeeper服务器的客户端创建的，它和创建它的客户端的内在联系，决定了它的存在性：

持久化（persistent）：客户端和服务器断开连接后，创建的节点不删除。

•  PERSISTENT-持久化节点：创建这个节点的客户端在与zookeeper服务的连接断开后，这个节点也不会被删除（除非您使用API强制删除）。
• PERSISTENT_SEQUENTIAL-持久化顺序编号节点：当客户端请求创建这个节点A后，zookeeper会根据parent-znode的zxid状态，为这个A节点编写一个全目录唯一的编号（这个编号只会一直增长）。当客户端与zookeeper服务的连接断开后，这个节点也不会被删除。

短暂|临时（Ephemeral）：客户端和服务端断开连接后，创建的节点删除。  

•     EPHEMERAL-临时目录节点：创建这个节点的客户端在与zookeeper服务的连接断开后，这个节点（还有涉及到的子节点）就会被删除。
•     EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点：当客户端请求创建这个节点A后，zookeeper会根据parent-znode的zxid状态，为这个A节点编写一个全目录唯一的编号（这个编号只会一直增长）。当创建这个节点的客户端与zookeeper服务的连接断开后，这个节点被删除。

另外，无论是EPHEMERAL还是EPHEMERAL_SEQUENTIAL节点类型，在zookeeper的client异常终止后，节点也会被删除

 

zookeeper的一些命令

ZooKeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是树形结构，每个节点称做一个znode，每个znode都可以通过其路径名称进行唯一标识.

每一个znode都可以保存数据(默认存储1MB)，然后通过路径标识进行查找。类似于map集合中的key/value的感觉，路径标识就是key, 存储的数据就是value.所以也可以认为zookeeper是一个树形结构的数据库。

通过相应的客户端指令可以保存数据或操作数据

命令基本语法	功能描述
help	显示所有操作命令
ls path [watch]	使用 ls 命令来查看当前znode中所包含的内容
Create path val	普通创建 -s  含有序列 -e  临时（重启或者超时消失）
get path [watch]	获得节点的值
Set path val	设置节点的具体值
Stat path	查看节点状态
Delete path	删除节点

• 启动客户端 ： ./zkCli.sh
• 显示所有操作命令 : help
• 查看当前znode中所包含的内容 : ls path(使用斜杠开头)
• 创建普通节点 : create path val
• 获取节点的值 : get path
• 修改节点的值 :set path newValue
• 删除节点 : delete path
• 查看节点状态 :stat path
• 查看节点同时查看节点状态 ls2 path
• 递归删除节点 : rmr path

Stat的结构体

• 1)czxid- 引起这个znode创建的zxid，创建节点的事务的zxid
• 2)ctime - znode被创建的毫秒数(从1970年开始)
• 3)mzxid - znode最后更新的zxid
• 4)mtime - znode最后修改的毫秒数(从1970年开始)
• 5)pZxid-znode最后更新的子节点zxid
• 6)cversion - znode子节点变化号，znode子节点修改次数
• 7)dataversion - znode数据变化号
• 8)aclVersion - znode访问控制列表的变化号
• 9)ephemeralOwner- 如果是临时节点，这个是znode拥有者的session id。如果不是临时节点则是0
• 10)dataLength- znode的数据长度
• 11)numChildren - znode子节点数量
   

zookeeper的监听原理

1、监听原理详解：

• 1.1、首先要有一个main()线程
• 1.2、在main线程中创建zookeeper客户端，这时就会创建两个线程，一个负责网络连接通信（connet），一个负责监听（listener）。
• 1.3通过connect线程将注册的监听事件发送给zookeeper。
• 1.4、在zookeeper的注册监听器类标中将注册的监听事件添加到列表中。
• 1.5、zookeeper监听到有数据或路径变化，就会将这个消息发送给listener线程。
• 1.6、listener线程内部调用了process的方法。 

2、常见的监听

• 2.1、监听节点数据的变化  get path [watch]
• 2.2、监听自节点增减的变化  ls path [watch]

Session

客户端使用某种语言绑定创建一个到服务的句柄时，就建立了一个ZooKeeper会话。会话创建后，句柄处于CONNECTING（connecting-------------）状态，客户端库会试图连接到组成ZooKeeper服务的某个服务器；连接成功则进入到CONNECTED状态。通常操作中句柄将处于这两个状态之一。如果发生不可恢复的错误，如会话过期、身份鉴定失败，或者应用显式关闭，则句柄进入到CLOSED状态。下图显式了ZooKeeper客户端可能的状态转换

 

监听

Zookeeper要想在服务发生变化的时候，能及时的通知客户端，那么必须要有相应的监听机制来实现变化的通知功能。

客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端

ZooKeeper 支持watch(观察)的概念。客户端可以在每个znode结点上设置一个观察。如果被观察服务端的znode结点有变更，那么watch就会被触发，这个watch所属的客户端将接收到一个通知包被告知结点已经发生变化，把相应的事件通知给设置Watcher的Client端。

Zookeeper里的所有读取操作：getData(),getChildren()和exists()都有设置watch的选项

一次触发 当数据有了变化时zkserver向客户端发送一个watch,它是一次性的动作，即触发一次就不再有效，类似一次性纸杯。只监控一次 如果想继续Watch的话，需要客户端重新设置Watcher。因此如果你得到一个watch事件且想在将来的变化得到通知，必须新设置另一个watch。

发往客户端 Watches是异步发往客户端的，Zookeeper提供一个顺序保证：在看到watch事件之前绝不会看到变化，这样不同客户端看到的是一致性的顺序。 在（导致观察事件被触发的）修改操作的成功返回码到达客户端之前，事件可能在去往客户端的路上，但是可能不会到达客户端。观察事件是异步地发送给观察者（客户端）的。ZooKeeper会保证次序：在收到观察事件之前，客户端不会看到已经为之设置观察的节点的改动。网络延迟或者其他因素可能会让不同的客户端在不同的时间收到观察事件和更新操作的返回码。这里的要点是：不同客户端看到的事情都有一致的次序。

为数据设置watch 节点有不同的改动方式。可以认为ZooKeeper维护两个观察列表：数据观察和子节点观察。getData()和exists()设置数据观察。getChildren()设置子节点观察。此外，还可以认为不同的返回数据有不同的观察。getData()和exists()返回节点的数据，而getChildren()返回子节点列表。所以，setData()将为znode触发数据观察。成功的create()将为新创建的节点触发数据观察，为其父节点触发子节点观察。成功的delete()将会为被删除的节点触发数据观察以及子节点观察（因为节点不能再有子节点了），为其父节点触发子节点观察。 观察维护在客户端连接到的ZooKeeper服 务器中。这让观察的设置、维护和分发是轻量级的。客户端连接到新的服务器时，所有会话事件将被触发。同服务器断开连接期间不会收到观察。客户端重新连接 时，如果需要，先前已经注册的观察将被重新注册和触发。通常这都是透明的。有一种情况下观察事件将丢失：对还没有创建的节点设置存在观察，而在断开连接期 间创建节点，然后删除。

时序性和一致性 Watches是在client连接到Zookeeper服务端的本地维护，这可让watches成为轻量的，可维护的和派发的。当一个client连接到新server，watch将会触发任何session事件，断开连接后不能接收到。当客户端重连，先前注册的watches将会被重新注册并触发。 关于watches，Zookeeper维护这些保证： （1）Watches和其他事件、watches和异步恢复都是有序的。Zookeeper客户端保证每件事都是有序派发 （2）客户端在看到新数据之前先看到watch事件 （3）对应更新顺序的watches事件顺序由Zookeeper服务所见

变化备注 data watches and child watches. watch之数据变化 watch之节点变化

写数据

 

 

zoo.cfg文件：

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

initLimit：LF初始通信时限 集群中的follower跟随者服务器(F)与leader领导者服务器(L)之间初始连接时能容忍的最多心跳数（tickTime的数量），用它来限定集群中的Zookeeper服务器连接到Leader的时限。 投票选举新leader的初始化时间 Follower在启动过程中，会从Leader同步所有最新数据，然后确定自己能够对外服务的起始状态。 Leader允许F在 initLimit 时间内完成这个工作。

syncLimit：LF同步通信时限 集群中Leader与Follower之间的最大响应时间单位，假如响应超过syncLimit * tickTime， Leader认为Follwer死掉，从服务器列表中删除Follwer。 # 在运行过程中，Leader负责与ZK集群中所有机器进行通信，例如通过一些心跳检测机制，来检测机器的存活状态。 如果L发出心跳包在syncLimit之后，还没有从F那收到响应，那么就认为这个F已经不在线了。

dataDir：数据文件目录+数据持久化路径 保存内存数据库快照信息的位置，如果没有其他说明，更新的事务日志也保存到数据库。

clientPort：客户端连接端口，监听客户端连接的端口。

 

zookeeper四字命令

zookeeper支持某些特定的四字命令，他们大多是用来查询ZK服务的当前状态及相关信息的，通过telnet或nc向zookeeper提交相应命令，如：echo ruok | nc 127.0.0.1 2181

运行公式：echo 四字命令 | nc 主机IP zookeeper端口

ruok：测试服务是否处于正确状态。如果确实如此，那么服务返回“imok ”，否则不做任何相应

stat：输出关于性能和连接的客户端的列表

conf：输出相关服务配置的详细信息

cons：列出所有连接到服务器的客户端的完全的连接 /会话的详细信息。包括“接受 / 发送”的包数量、会话id 、操作延迟、最后的操作执行等等信息

dump：列出未经处理的会话和临时节点

envi：输出关于服务环境的详细信息（区别于conf命令）

reqs：列出未经处理的请求

wchs：列出服务器watch的详细信息

wchc：通过session列出服务器watch的详细信息，它的输出是一个与watch相关的会话的列表

wchp：通过路径列出服务器 watch的详细信息。它输出一个与 session相关的路径

安装zookeeper的过程：

可以参考的网址：

    我把zookeeper安装在：/usr/local/soft/zookeeper底下

• 下载安装包zookeeper-3.4.9.tar.gz（或者其他版本）
• 拷贝进入到/opt目录下并解压
• 新建专属zookeeper目录，mkdir /myzookeeper，随后将上一步解压的zookeeper内容拷贝进/myzookeeper目录内cp -r zookeeper-3.4.9 /myzookeeper
• 进入conf文件夹，拷贝zoo_sample.cfg改为zoo.cfg : cp zoo_sample.cfg zoo.cfg
• 开启服务+客户端连接

• 进入指定文件夹：cd /myzookeeper/zookeeper-3.4.9/bin

执行启动命令： ./zkServer.sh start

执行关闭命令 ./zkServer.sh stop

• 使用客户端工具连接服务器：./zkCli.sh , 如果打印内容中包含Welcome to ZooKeeper! 说明安装成功。
• 也可以使用zookeeper四字命令连接：echo ruok | nc 127.0.0.1 2181
• 使用quit退出服务

• 出现这个错误的解决：

• 问题：如果出现192.168.X.X:2181. Will not attempt to authenticate using SASL错误，可能是linux服务器防火墙没有开放2181端口，请在linux服务器中按照下面步骤进行操作。（下面这些操作要自己手打，不然有可能无效）
• Ø  /sbin/iptables -I INPUT -p tcp --dport 2181 -j ACCEPT

                Ø  /etc/rc.d/init.d/iptables save

                Ø  service iptables restart

              /etc/init.d/iptables status

集群：

  在zoo.cfg里面配置：dataDir=/usr/local/soft/zookeeper/zk02/mydata

                        dataLogDir=/usr/local/soft/zookeeper/zk02/mylog

                        zookeeper端口：2181,2282,2383

server.1=127.0.0.1:2881:3991

server.2=127.0.0.1:2882:3992

server.3=127.0.0.1:2883:3993

分别在mydata目录下创建myid ，里面只需要的值为1（server.1=127.0.0.1:2881:3991和这个1相对应上）、2、3

之后全部启动后，在任何一个zookeeper的bin下面执行：

.zkCli.sh –server 127.0.0.1:2383

出现下面异常：

2018-01-22 13:30:29,663 - WARN  [main-SendThread(localhost:2383):ClientCnxn$SendThread@1185] - Session 0x0 for server null, 

unexpected error, closing socket connection and attempting reconnect

java.net.ConnectException: Connection refused

at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)

at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)

at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1143)

这个的原因是myid配置文件错了

 

在搭建集群的时候会出现停止服务：

[root@localhostbin]# sh zkServer.sh stop

ZooKeeper JMXenabled by default

Using config:/root/zookeeper-3.4.8/bin/../conf/zoo.cfg

Stopping zookeeper... zkServer.sh: line 182: kill: (16834) - No such process

STOPPED

这个可能是zookeeper的有些服务和他是有冲突的

在搭建集群的时候要把其他和他无关的zookeeper进程关闭掉，不然有可能有出现问题的