ZooKeeper 学习笔记(二)-API 操作和应用

客户端

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 操作和应用_第1张图片
zkCli 连接成功

其中 0x15a0d2841340001 是本次 session 的 id。

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

  • 同时开两个 zkCli 分别为 A,B;

A 连接至 127.0.0.1:2181

ZooKeeper 学习笔记(二)-API 操作和应用_第2张图片
A连接到 ZooKeeper 集群

B 连接至 127.0.0.1:2182。

ZooKeeper 学习笔记(二)-API 操作和应用_第3张图片
B连接到 ZooKeeper 集群
  • A 创建临时节点:create -e /temp_a "temp a znode"
ZooKeeper 学习笔记(二)-API 操作和应用_第4张图片
A 创建节点
  • B 查看节点数据并设置监控点:get /temp_a true
ZooKeeper 学习笔记(二)-API 操作和应用_第5张图片
B 查看节点
  • A 关闭模拟客户端崩溃。

A 创建的临时节点被删除

ZooKeeper 学习笔记(二)-API 操作和应用_第6张图片
A 关闭连接

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

ZooKeeper 学习笔记(二)-API 操作和应用_第7张图片
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 操作和应用_第8张图片
分布式锁
ZooKeeper 和 Dubbo

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

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

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

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

ZooKeeper 学习笔记(二)-API 操作和应用_第9张图片
分布式锁
  • /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

你可能感兴趣的:(ZooKeeper 学习笔记(二)-API 操作和应用)