ZooKeeper 学习笔记（二）－API 操作和应用

2019年6月9日 240次阅读 来源: PFF

客户端

znode 可能含有数据，也可能没有。如果 znode 包含数据，那么数据存储为字节数组（byte array）。字节数组的具体格式特定于每个应用的实现，ZooKeeper 不直接 提供解析支持。不过一般情况下，以 UTF-8 或 ASCII 编码的字符串就已经够用了。

API 概述

ZooKeeper 的 API 可以抽象成以下方法：

  • create /path data

    创建一个名为 /path 的 znode 节点，并包含数据 data

  • delete /path

    删除名为 /path 的 znode

  • exists /path

    检查是否存在名为 /path 的节点

  • setData /path data

    设置名为 /path 节点数据为 data

  • getData /path

    返回名为 /path 节点的所有子节点列表

需要注意的是，ZooKepper 并不允许局部写入或读取 znode 节点的数据。当设置一个 znode 节点的数据或读取时，znode 节点的内容会被整个替换或者全部读取。

zkCli.sh

ZooKeeper 安装包提供了客户端工具 zkCli.sh（zkCli.cmd）方便我们学习实验 API 接口，该工具位于 bin 目录下，启动命令格式为：

bin/zkCli.sh -server 127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183

后面一段“127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183”是 ZooKeeper 集群的 IP 和端口组成的字符串，客户端会以随机顺序连接到服务器中。连接上集群后，如下图显示：

《ZooKeeper 学习笔记（二）－API 操作和应用》 zkCli 连接成功

其中 0x15a0d2841340001 是本次 session 的 id。

这儿简单的演示临时节点和监视点特性：

  • 同时开两个 zkCli 分别为 A，B；

A 连接至 127.0.0.1:2181

《ZooKeeper 学习笔记（二）－API 操作和应用》 A连接到 ZooKeeper 集群

B 连接至 127.0.0.1:2182。

《ZooKeeper 学习笔记（二）－API 操作和应用》 B连接到 ZooKeeper 集群

  • A 创建临时节点：create -e /temp_a “temp a znode”

《ZooKeeper 学习笔记（二）－API 操作和应用》 A 创建节点

  • B 查看节点数据并设置监控点：get /temp_a true

《ZooKeeper 学习笔记（二）－API 操作和应用》 B 查看节点

  • A 关闭模拟客户端崩溃。

A 创建的临时节点被删除

《ZooKeeper 学习笔记（二）－API 操作和应用》 A 关闭连接

因为监视点的设置，B 收到 /temp_a 删除通知

《ZooKeeper 学习笔记（二）－API 操作和应用》 B 收到删除通知

开源客户端库

zkCli 只适合学习和试验 ZooKeeper 集群，如果我们需要利用 ZooKeeper 实际开发分布式协同任务的系统时，可以使用 ZooKeeper 自带的客户端库。不过这些 jar 包只提供基本的阻塞和非阻塞 API 接口，需要开发人员自己实现类似会话超时重连，重复设置监视点等功能。除了 ZooKeeper 自带的客户端包，还可以使用以下客户端模块。

  • zkClient

zkClient 是 Github 上一个开源的 ZooKeeper 客户端，是由 Datameer的工程师 Stefan Groschupf 和 Peter Voss 一起开发的。zkClient 在原生 API 上进行封装，是一个更简单易用的 ZooKeeper 客户端。同时，zkClient 在内部实现了诸如 session 超时重练，Watcher 反复注册等功能，使这些繁琐复杂的功能对开发人员透明。

地址：https://github.com/sgroschupf/zkclient

  • Curator

Curator 是 Netflix 公司开源的一套 ZooKeeper 客户端框架，和 zkClient 一样，Curator 解决了很多 ZooKeeper 客户端非常底层的细节开发工作，目前已成为 Apache 的顶级项目，是全世界范围内使用最广泛的 ZooKeeper 客户端之一。

除了封装底层细节，使之对开发透明，Curator 还提供了一套易用性和可读性更强的 Fluent 风格的 API 框架。

除此之外，Curator 还提供饿了 ZooKeeper 各种应用场景的抽象封装（Recipe），如共享锁服务，Master 选举机制和分布式计数器等。

地址：http://curator.apache.org/curator-recipes/index.html

典型应用

需要再次说明 ZooKeeper 是保证分布式数据一致性和任务协调的框架，它并不会直接实现具体的分布式锁，Master 选举等分布式功能，而是提供一些简单易用的 API 接口，具体的功能实现需要开发者根据情况自行实现。另一方面，ZooKeeper 同时也是一个典型的发布／订阅模式的分布式数据管理与协调方案，配合监视点事件通知机制，可以非常方便地构建一些列分布式应用中都会涉及的核心功能：

  • 数据发布/订阅
  • 负载均衡
  • 命名服务
  • 分布式协调/通知
  • 集群管理
  • Master 选举
  • 分布式锁
  • 分布式队列

下面简单介绍下分布式锁的实现思路。

分布式锁

假设一个应用由 n 个进程组成，分别为 p1, p2 …. pn，这些进程尝试获取一个锁从而进入临界区进行操作。这儿我们可以使用 ZooKeeper 的 znode 来代表一个锁，如“/lock”。

  1. 所有进程同时尝试创建这个 znode，由 ZooKeeper 来保证顺序性。
  2. 如果某进程成功创建了 “/lock”，假设为 p4，则代表 p4 抢占到了该分布式锁，p4 可以执行临界区代码，其他进程则会因为 znode 存在而创建失败。
  3. 它们可以在 “/lock”节点上创建监视器后等待 znode 删除通知，如果删除通知到来，则重复 1 抢占锁。
  4. p4 释放锁时，删除 “/lock”节点即可，需要注意，因为 p4 很可能执行临界区代码时崩溃，所以“/lock”节点应该临时节点，如果 p4 崩溃，则该节点自行删除。
羊群效应

上述分布式锁的实现简单易用，但是却会造成“羊群效应”。想象一下，如果有 1000 个客户端同时调用 exists 监视“/lock”节点变化。那么当这个 znode 创建或删除时就会发送 1000 个通知，这个被监视的 znode 的一个变化会产生一个尖峰的通知，该尖峰时刻提交的操作可能会产生很高的延迟。

为了防止羊群效应的产生，利用有序节点，分布式锁不妨换一种实现方式：

  1. 系统已经存在“/lock”节点，争抢锁的进程在该节点下创建临时有序子节点，形如：/lock/192.168.1.200:2222-00000001;
  2. 进程获取 /lock 下子节点列表，判断自己的节点位置:
    • 如果自己的节点序号最小，则表示获得锁，执行临界区代码;
    • 如果不是，则在自己序号前一个子节点增加监视点 Watcher，等待删除通知。
  3. 获取锁的进程，执行外临界代码，删除自己的子节点，表示释放锁；
  4. 下一个子节点序号的进程获取删除通知，重复动作 2。

这种实现方式下，进程只监测排在它前面进程的节点，而不是 所有进程都监测 /lock 节点，避免了“羊群效应”。结构如下图所示：

《ZooKeeper 学习笔记（二）－API 操作和应用》 分布式锁

ZooKeeper 和 Dubbo

Dubbo 是阿里巴巴开源（好像开源版本已经停止更新）的由 Java 语言编写的分布式服务框架，致力于提供高性能和透明化的远程服务调用方案和 SOA 服务治理方案。

目前 Github 地址：https://github.com/alibaba/dubbo
主页地址： http://dubbo.io/

Dubbo 基于 ZooKeeper 实现服务注册中心。注册中心是 RPC 框架最核心的模块之一，用于服务的注册和订阅。在 Dubbo 的实现中，对注册中心模块进行抽象封装，因此可以基于其提供的外部接口实现各种不同类型的注册中心，例如数据库，Redis 等。

在 Dubbo 注册中心的整体架构中，ZooKeeper 上服务的节点设计如下图所示：

《ZooKeeper 学习笔记（二）－API 操作和应用》 分布式锁

  • /dubbo 这是 Dubbo 在 ZooKeeper 上创建的根节点
  • /dubbo/com.foo.BarService 是服务节点，代表了 Dubbo 的一个服务
  • /dubbo/com.foo.BarService/providers 这是服务提供者的根节点，其子节点代表每一个服务真正提供者
  • /dubbo/com.foo.BarService/consumers 这是服务消费者的根节点，其子节点代表每一个服务的真正消费者

流程说明：

  • 服务提供者（Provider）启动
    • 向 /dubbo/com.foo.BarService/providers 目录下写入自己的URL地址。
  • 服务消费者（Consumer）启动时
    1. 订阅 /dubbo/com.foo.BarService/providers 目录下的提供者URL地址。
    2. 并向 /dubbo/com.foo.BarService/consumers 目录下写入自己的URL地址。
  • 监控中心（Monitor）启动时
    • 订阅 /dubbo/com.foo.BarService 目录下的所有提供者和消费者URL地址。

需要注意的是，所有提供者和消费者在 ZooKeeper 上创建的节点都是临时节点，利用临时节点生命周期和会话绑定的特性，一旦机器发生故障导致服务提供者无法对外提供服务，该临时节点就会自动从 ZooKeeper 上删除。

内容来源

从 Paxos 到 ZooKeeper 分布式一致性原理与实践

ZooKeeper 分布式过程协同技术详解

https://github.com/alibaba/dubbo

http://dubbo.io/User+Guide-zh.htm#UserGuide-zh-Zookeeper%E6%B3%A8%E5%86%8C%E4%B8%AD%E5%BF%83

    原文作者：PFF
    原文地址: https://www.jianshu.com/p/2144b34d2afe
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞