Zookeeper 第一章 初识Zookeeper

简介

ZooKeeper是一个集中的服务，用于维护配置信息、命名、提供分布式同步和提供组服务。所有这些类型的服务都以某种形式被分布式应用程序使用。每次
实现它们时，都有大量的工作要做，以修复不可避免的bug和竞争条件。由于实现这类服务的困难，应用程序最初通常会忽略它们，这使得它们在发生变化
时变得脆弱，难以管理。即使操作正确，这些服务的不同实现在部署应用程序时也会导致管理复杂性。
ZooKeeper的目标是将这些不同服务的本质提炼成一个非常简单的接口，以实现一个集中式的协调服务。服务本身是分布式的并且高度可靠。共识、组管理和
存在协议将由服务实现，这样应用程序就不需要自己实现它们。这些应用程序的特定用途将由动物园管理员的特定组件和特定应用程序的约定组成。ZooKeep
er展示了如何使用这个简单的服务来构建更强大的抽象。
Zookeeper应用程序本身提供了Java和C接口。多种客户端绑定可用于多种语言，包括Python、Ruby和Go。

设计目标

简单：ZooKeeper 允许分布式进程通过共享的分层命名空间相互协调，该命名空间的组织类似于标准文件系统。命名空间由数据寄存器组成在（ZooKeeper
中称为znodes）这些类似于文件和目录。与典型的为存储而设计的文件系统不同，ZooKeeper 数据保存在内存中，这意味着 ZooKeeper 可以实现高吞吐
量和低延迟。
高性能：ZooKeeper 实现非常重视高性能、高可用、严格有序的访问。ZooKeeper 的性能方面意味着它可以用于大型分布式系统。可靠性方面使其不会成
为单点故障。严格的排序意味着可以在客户端实现复杂的同步原语。
自我复制：就像它协调的分布式进程一样，ZooKeeper 本身旨在通过一组称为集合的主机进行复制。

组成 ZooKeeper 服务的服务器必须做互信。它们维护内存中的image状态，以及持久存储中的事务日志和快照。只要大多数服务器可用，ZooKeeper 服务
就可用。
客户端连接到单个 ZooKeeper 服务器。客户端维护一个 TCP 连接，通过它发送请求、获取响应、获取监视事件和发送心跳。如果与服务器的 TCP 连接
中断，客户端将连接到其他的服务器。
ZooKeeper 排序：ZooKeeper 用反映所有 ZooKeeper 事务顺序的数字标记每个更新。后续操作可以使用顺序来实现更高级别的抽象，例如同步原语。
ZooKeeper 速度很快。它在“读取主导”工作负载中特别快。ZooKeeper 应用程序在数千台机器上运行，它在读取比写入更常见的情况下表现最佳，比率约
为 10:1。

数据模型和分层命名空间

ZooKeeper 提供的命名空间很像标准文件系统的命名空间。名称是由斜杠 (/) 分隔的一系列路径元素。
ZooKeeper 命名空间中的每个节点都由路径标识

节点和临时节点

与标准文件系统不同，ZooKeeper 命名空间中的每个节点都可以拥有与其关联的数据以及子节点。这就像一个允许文件也成为目录的文件系统。（ZooKee
per 旨在存储协调数据：状态信息、配置、位置信息等，因此每个节点存储的数据通常很小，在byte到KB范围内。）我们使用术语znode来明确我们正在
谈论 ZooKeeper 数据节点。
Znodes 维护一个统计结构，其中包括数据更改、ACL 更改和时间戳的版本号，以允许缓存验证和协调更新。每次 znode 的数据更改时，版本号都会增加
例如，每当客户端检索数据时，它也会收到数据的版本号。存储在命名空间中每个 znode 的数据是原子读写的。读取获取与znode关联的所有数据，写入
替换所有数据。每个节点都有一个访问控制列表 (ACL)，它限制了谁可以做什么。
ZooKeeper 也有临时节点的概念。只要创建 znode 的会话处于活动状态，这些 znode 就存在。当会话结束时，znode 被删除。

数据保证

ZooKeeper 非常快速且非常简单。但是，由于它的目标是成为构建更复杂服务（例如同步）的基础，因此它提供了一组保证。这些都是：
顺序一致性 	- 来自客户端的更新将按发送顺序被使用。
原子性 		- 更新要么成功要么失败，没有其他状态。
单一系统映像 	- 无论连接到哪个服务器，客户端都将看到相同的服务视图。即使客户端由于故障转移到具有相同会话的不同服务器，客户端也永远不会
              看到系统的旧视图。
可靠性 		- 应用更新后，它将从那时起一直存在，直到客户端覆盖更新。
及时性 		- 系统的客户视图保证在特定时间范围内是最新的。

提供的API接口

ZooKeeper 的设计目标之一是提供一个非常简单的编程接口。因此，它仅支持以下操作：
create 			: 在目录树中的某个位置创建一个节点
delete 			: 删除一个节点
exists 			: 测试节点是否存在于某个位置
get data 		: 从节点读取数据
set data 		:	将数据写入节点
get children 	: 检索节点的子节点列表
sync 			: 等待数据被广播

可靠性的检测

运行了一个由 7 台机器组成的 ZooKeeper 服务。运行了与之前相同的饱和基准测试，但这次将写入百分比保持在 30% 不变，模拟以下5种场景，下图是
我们预期工作负载的保守比例
 1. 一个follower的失败和恢复
 2. 不同follower的故障和恢复
 3. leader的故障
 4. 两个follower的故障与恢复
 5. 另一个leader的故障

从这张图中有一些重要的观察结果。首先，如果跟随者失败并快速恢复，那么即使出现故障，ZooKeeper 也能够维持高吞吐量。但也许更重要的是，
leader选举算法允许系统足够快地恢复以防止吞吐量大幅下降。在我们的观察中，ZooKeeper 花费不到 200 毫秒的时间来选举一个新的leader。第三，
随着follower的恢复，一旦他们开始处理请求，ZooKeeper 能够再次提高吞吐量

相关资料

zookeeper 官网：https://zookeeper.apache.org/