Zookeeper原理及应用汇总

最新推荐文章于 2024-07-30 22:39:23 发布

Tangyuewei

最新推荐文章于 2024-07-30 22:39:23 发布

阅读量2.2k

点赞数 1

分类专栏：开源框架文章标签： Zookeeper原理

本文链接：https://blog.csdn.net/qq_28077405/article/details/81699823

版权

开源框架专栏收录该内容

4 篇文章 0 订阅

订阅专栏

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	通过路径列出服务器 watch 的详细信息。它输出一个与 session相关的路径。

3 命令行工具

[sgwdev_linuxuser@tydic bin]$ ./zkCli.

zkCli.cmd zkCli.sh

[sgwdev_linuxuser@tydic 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软负载均衡

场景描述：

随着业务量的提高，访问量和数据流量的快速增长，其处理能力和计算强度也相应地增大，使得单一的服务根本无法承担。将负载（工作任务）进行平衡、分摊到多个操作单元上进行执行，在分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提供方都会部署多份，达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业务逻辑。

好处：高可用性,减轻服务的压力，实现软负载均衡