Zookeeper原理及应用汇总
1 Zookeeper简介-分布式服务框架
ZooKeeper为分布式应用程序提供高效且可靠的分布式协调服务，提供的服务：配置管理、统一命名服务、分布式同步、组服务等，是Google Chubby的开源实现，Hadoop和Hbase的重要组件;是一个典型的分布式数据一致性的解决方案，分布式应用程序可基于它实现诸如数据发布/订阅、负载均衡、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。
ZooKeeper的设计目标就是将复杂易出错的分布式一致性服务封装起来，构成高效可靠的原语集，并以一系列简单易用的接口提供给用户使用，支持Java和C的接口。
ZooKeeper代码版本中，提供了分布式独享锁、选举、队列的接口。其中分布锁和队列有Java和C两个版本，选举只有Java版本。
ZooKeeper是以Fast Paxos算法为基础的，Paxos 算法存在活锁的问题，即当有多个proposer交错提交时，有可能互相排斥导致没有一个proposer能提交成功，而Fast Paxos作了一些优化，通过选举产生一个leader (领导者)，只有lead才能提交proposer[申请]。在解决分布式数据一致性方面，ZooKeeper并没有直接采用Paxos算法，而是使用ZAB的一致性协议 。
ZooKeeper的基本运转流程：
1、选举Leader。 2、同步数据。
3、选举Leader过程中算法有很多，但要达到的选举标准是一致的。
4、Leader要具有最高的zxid。
5、集群中大多数的机器得到响应并follow选出的Leader
2 常用命令
|
四字命令 |
功能描述 |
|
conf |
输出相关服务配置的详细信息。 |
|
cons |
列出所有连接到服务器的客户端的完全的连接 / 会话的详细信息。包括“接受 / 发送”的包数量、会话 id 、操作延迟、最后的操作执行等等信息。 |
|
dump |
列出未经处理的会话和临时节点。 |
|
envi |
输出关于服务环境的详细信息（区别于 conf 命令）。 |
|
reqs |
列出未经处理的请求 |
|
ruok |
测试服务是否处于正确状态。如果确实如此，那么服务返回“imok ”，否则不做任何相应。 |
|
stat |
输出关于性能和连接的客户端的列表。 |
|
wchs |
列出服务器 watch 的详细信息。 |
|
wchc |
通过 session 列出服务器 watch 的详细信息，它的输出是一个与watch 相关的会话的列表。 |
|
wchp |
3 命令行工具
[[email protected] bin]$ ./zkCli.
zkCli.cmd zkCli.sh
[[email protected] bin]$ ./zkCli.sh -server 192.168.1.165:2181
Connecting to 192.168.1.165:2181
4 简单操作
1)ls 查看ZooKeeper指定节点下一级所有子节点
ls path [watch]
2)get 获取ZooKeeper指定节点的数据内容和属性信息
get path [watch]
3）set 更新指定节点的数据内容,version为指定ZNode数据结点的版本，不指定更新后
dataVersin会+1
set path data [version]
4)create 创建一个ZooKeeper节点,-s:顺序节点;-e:临时节点;默认为永久节点;
acl: 权限控制，默认不做控制
create [-s] [-e] path data acl
5)delete 在没有没有子结点时删除ZooKeeper指定节点
delete path [version]
5 开源客户端
Curator（全世界应用最广泛） , ZkClient
6 目标
1）简单的数据模型
ZooKeeper服务器内存中的数据模型，由系列的ZNode节点构成，树型结构命名空间-7.1.1
2）构建集群 7.3
3）顺序访问 7.8
对于客户端每个请求会分配一个全局唯一的递增编号，编号反映所有事务操作的先后顺序。
4）高性能
全量数据存储在内存中，直接服务于客户端所有非事务请求，尤其适合于以读操作为主场景
7 概念
1）集群角色
通常分布式集群是主备模式（Master/Slave);ZooKeeper采用Leader、Follower、Observer三角色，通过Leader选举选定Leader服务器，为客户端提供读和写服务，Follower和Observer节点提供读服务，Observer节点不参与Leader选举和写操作“过半写成功”策略，故可以在不影响写性能的情况下提升集群的读性能 7.7
2）会话
3）数据节点ZNode
所有ZNode以模型结构存储在内存中，数据节点ZNode包含数据内容和系列的属性信息，
如。分持久PERSISTENT,临时节点EPHEMERAL和顺序节点SEQUENTIAL，可组成4种组合型节点。持久节点:创建后只有主动进行删除操作才移除，否则一直有效;临时节点：生命周期与Client会话绑定，在Client会话失效时，这个客户端所创建的所有临时结点都会删除，SEQUENTIAL，创建节点后追加整形数字，由父节点维护的自增数字，
4）版本
ZNode内Stat数据结构，记录ZNode三个数据版本，version当前版本;cversion当前子节点版本;aversion当前ACL版本 7.1.3
5）Watcher 事件监听器
用户在指定节点注册一些Watcher，并且在特定事件触发的时候，ZooKeeper服务端会将事件通知到感兴趣的客户端上去，该机制是ZooKeeper实现分布式协调服务的重要特性。7.1.4
6）ACL 访问控制列表(Access Control List) ，通过ACL策略进行权限控制，5种权限
CREATE：创建子节点权限 READ：获取节点数据和子节点列表的权限
WRITE：更新节点数据的权限 DELETE：删除子节点数据的权限
ADMIN：设置节点ACL的权限 7-1-5
7)ZAB协议ZooKeeper Atomic Broadcast 原子消息广播协议，保证数据一致性的核心算法
8 Zookeeper结构
角色：Zookeeper=服务端+客户端
|
服务端 |
支持群集，包括文件系统和通知机制 |
|
客户端 |
连接服务端，操作数据，注册要监听的数据，接收通知 |
功能：Zookeeper=文件系统+通知机制
|
文件系统 |
存储和管理数据，以树型的结构存储 |
|
通知机制 |
监控文件系统的数据变化，通知监听的客户端 |
8.1文件系统
|
Zookeeper数据结构特点： |
|
|
路径唯一标识 |
树型存储结构，与文件系统目录树结构类似 例：/Apps/App3/SubApp1 |
|
节点下可以创建子节点 |
可以针对节点进行增，删，改，查，创建子节点操作 各个节点下可以存储数据,数据可以有多个版本。 |
|
临时节点 |
一旦创建这个节点的客户端与服务器失去联系，这个节点也将自动删除， Zookeeper 的客户端和服务器通信采用长连接方式， 每个客户端和服务器通过心跳来保持连接， 这个连接状态称为 session，如果节点是临时节点， 这个 session 失效，节点也就删除了. 临时节点下不能创建子节点 |
|
永久节点 |
创建这个节点的客户端与服务器失去联系，这个节点不会删除。 |
|
节点的名称可以自动编号 |
如 App1 已经存在，再创建的话，将会自动命名为 App2 |
|
节点可以被监控 |
节点中存储数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是 Zookeeper 的核心特性，Zookeeper 的很多功能都是基于这个特性实现的. |
8.2通知机制
Zookeeper 的客户端和服务器通信采用长连接方式，客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，每个客户端和服务器通过心跳来保持连接，zookeeper会通知客户端。
8.3总结
Zookeeper原理：
|
1 |
存储 |
负责存储和管理数据 |
|
2 |
注册 |
然后接受客户端的注册，监听相关的数据 |
|
3 |
变化 |
一旦这些数据的状态发生变化 |
|
4 |
通知 |
Zookeeper 负责通知已经在 Zookeeper 上注册的那些客户端 |
|
5 |
业务处理 |
客户端做出相应的反应 |
Zookeeper 特点：
|
顺序一致性 |
按照客户端发送请求的顺序更新数据。 |
|
原子性 |
更新要么成功，要么失败，不会出现部分更新。 |
|
单一性 |
无论客户端连接哪个server，都会看到同一个视图。 |
|
可靠性 |
一旦数据更新成功，将一直保持，直到新的更新。 |
|
及时性 |
客户端会在一个确定的时间内得到最新的数据。 |
Zookeeper功能：
|
1 |
名称服务 |
统一命名服务,唯一的名称,树形的名称结构,便于人识别和记住,不会重复 |
|
2 |
配置维护 |
分布式应用配置项的管理 |
|
3 |
分布式同步 |
状态同步服务 |
|
4 |
组服务 |
集群管理 |
注：Zoopkeeper 提供了一套很好的分布式集群管理的机制，从而可以设计出多种多样的分布式的数据管理模型，而不仅仅局限于下面提到的几个常用应用场景。
8.4容错节点
zookeeper集群的容错能力情况：若2n+1=集群PC总数，n即为可容纳的故障节点。
例如：3台能容错1台，5台能容错2台，7台能容错3台。
9 Zookeeper应用场景
9.1配置数据管理
场景描述：
数据发布与订阅模型，即配置中心
发布者将数据发布到一个或一系列节点上，供订阅者动态获取数据。
实现模式：
推Push或拉Pull模式，推Push模式由服务器主动将数据更新推送给所有订阅的客户端，拉Pull模式是由客户端主动请求来获取最新数据，通过采用定时进行轮询拉取的方式。
ZooKeeper采用是推拉相结合模式，客户端向服务端注册自己关注的数据节点ZNode，一旦节点的数据发生改变，服务端向相应订阅的客户端发送Watcher事件通知，客户端收到通知后主动获取最新配置信息，达到数据的同步。
好处：实现配置信息的集中式管理和动态更新，实时同步。
应用场景：配置数据量小但数据运行时更新比较频繁、配置共享，例如：
解决方案：参考ZooKeeper的配置信息存储方案的设计与实现.pdf
JAVA DEMO：zkpublisher
9.2软负载均衡
场景描述：
随着业务量的提高，访问量和数据流量的快速增长，其处理能力和计算强度也相应地增大，使得单一的服务根本无法承担。将负载（工作任务）进行平衡、分摊到多个操作单元上进行执行，在分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提供方都会部署多份，达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业务逻辑。
好处：高可用性,减轻服务的压力，实现软负载均衡
实现：客户请求服务，服务中间件读取Zookeeper服务端取得提供服务的列表，根据规则，把请求定位到某个服务器执行相关的业务。
9.3集群管理
集群机器管理:
监控：监控集群中机器状态,监控机器在线率，实时检测集群机器是否存活
实现：
1.客户端启动时，向 Zookeeper上注册.
2.客户端在节点 x 上注册一个Watcher，那么如果 x的子节点变化了，会通知该客户端。
3.创建临时类型的节点，一旦客户端和服务器的会话结束或过期，那么该节点就会删除。
Master选举:
有些业务逻辑（例如一些耗时的计算，网络I/O处理），往往只需要让整个集群中的某一台机器进行执行，提高性能。
实现：创建节点时，分配一个序号，选举时，取***最小的那个机器作为Master
9.4分布式锁
锁：不同线程间，操作一个资源，存在资源竞争，要用到锁。分布式锁在进程与进程之间提供了一种互斥机制，在任何时刻，只有一个进程可以持有锁。锁服务可以分为两类：
保持独占：得益于ZooKeeper为我们保证了数据的强一致性。就是所有试图来获取这个锁的客户端，最终只有一个可以成功获得这把锁。(实现：大家都在某个节点下创建节点，只有一个成功，其它都是失败的)
控制时序：就是所有视图来获取这个锁的客户端，最终都是会被安排执行，只是有个全局时序了,（实现：创建有编号节点，查询按编号排序，取最小的编号，就能得到锁）
一个用户创建一个节点，分配数值,检测父节点下的节点列表的最小数据是否为自已创建的数据，如果是，代表获得锁。如果不是，代表别的用户已经锁住.
9.5队列管理
|
1 |
同步队列 |
描述：当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达，这种是同步队列.例如实现 (发并处理) 实现：在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目。 |
|
2 |
FIFO队列 |
描述：队列按照 FIFO 方式进行入队和出队操作,例如实现(生产者和消费者模型) 实现：和分布式锁服务中的控制时序场景基本原理一致，入队有编号，出队按编号。 |
10常用接口（JAVA API）
1) 创建会话
2) 创建节点
3) 删除节点
4) 读取数据
5) 更新数据
6) 节点是否存在
说明：
7) 权限控制
通过设置服务器上Znode数据节点的ACL，来控制客户端对该数据节点的访问权限。
11集群部署
前提：所有集群PC机必须安装JRE或JDK1.6+）
1 下载： http://zookeeper.apache.org/releases.html 版本ZooKeeper 3.4.9
2 安装： tar -xzvf xxxx.tar.gz解压到某个目录(如：%用户Root%/zookeeper349)
3 配置：
3.1）复制%用户Root%/zookeeper349/conf/zoo_sample.cfg文件，命名为：zoo.cfg
3.2）修改zoo.cfg内容
tickTime=2000
dataDir=%用户Root%/zookeeper349/zookeeper-3.4.9/data
dataLogDir=%用户Root%/zookeeper349/zookeeper-3.4.9/log
clientPort=2181
server.1=192.168.1.165:2888:3888
server.2=192.168.1.74:2888:3888
server.3=192.168.1.73:2888:3888
zoo.cfg说明：
tickTime：这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个 tickTime 时间就会发送一个心跳。
dataDir： Zookeeper 保存数据的目录，默认情况下，Zookeeper 将写数据的日志文件也保存在这个目录里。
dataLogDir： Zookeeper 保存Log数据的目录.
clientPort：这个端口就是客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。
server.1:集群机器节点1，ServerID为1，值格式：IP：端口1：端口2
server.2:集群机器节点2，ServerID为2，值格式：IP：端口1：端口2
server.3:集群机器节点3，ServerID为3，值格式：IP：端口1：端口2
3.3）增加名为myid文件
myid文件位置为dataDir指定的目录下，myid文件内容为集群本机器节点的ServerID值。即server1、server2、server3分别对应为：1、2、3
3.4）启动服务器
cd %用户Root%/zookeeper349/zookeeper-3.4.9/bin
./zkServer.sh start
3.5）检查是否成功，可执行如下命令：
1）telnet 192.168.1.74 2181回车后输入 stat
2) echo conf | nc 192.168.1.165 2181