zookeeper学习笔记

zookeeper学习笔记

前言

ZooKeeper是一种用于分布式应用程序的分布式开源协调服务。它提供了一些简单的源函数，分布式应用程序能够调用这些源函数，以实现更高级别的服务，能够实现同步、配置文件维护以及分组和命名。它被设计为易于编程，并使用相似文件系统目录树结构的数据模型。它使用java实现，里面也能够调用C语言。

设计目标

1. zookeeper是简单的
   ZooKeeper容许分布式进程经过共享的层级命名空间相互协调，该命名空间的结构与标准文件系统相似。名称空间由数据寄存器组成--在ZooKeeper中称为znodes，这些与文件和目录相似。与专为存储而设计的典型文件系统不一样，ZooKeeper数据保存在内存中，将支持ZooKeeper能够实现高吞吐量和低延迟。
2. zookeeper是可复制的
   与它协调的分布式进程同样，ZooKeeper自己也能够在称为集合的一组主机上进行复制。组成ZooKeeper服务的ZK服务之间必须彼此了解。它们维护内存中的状态图像，以及持久性存储(硬盘存储)中的事务日志和快照。只要大多数ZK服务可用，ZooKeeper服务就可用。客户端链接到单个ZK服务，客户端维护TCP链接，经过该链接发送请求，获取响应，获取监视事件以及发送心跳。若是与ZK服务的TCP链接中断，则客户端将链接到其余ZK服务。
   
3. zookeeper是可排序的
   ZooKeeper使用反映全部ZooKeeper事务顺序的数字标记每一个更新。后续操做可使用该特性来实现更高级别的抽象，例如同步源函数。
4. zookeeper是迅速的
   它在以读取数据为主的系统中，是很是快的。ZooKeeper应用程序在数千台计算机上运行，而且在读取比写入更常见的状况下表现最佳，比例大约为10：1。
5. 数据模型和分层命名空间
   ZooKeeper提供的名称空间很是相似于标准文件系统。名称是由斜杠"/"分隔的路径组成,ZooKeeper名称空间中的每一个节点都由路径标识。

ZooKeeper's Hierarchical Namespace

1. 节点和临时节点
   ZooKeeper中使用术语znode表示数据节点。与标准文件系统不一样，ZooKeeper命名空间中的每一个节点均可以包含与之关联的数据以及子项。就像一个容许文件也是目录的文件系统。(zookeeper的设计是用来保存协调数据，好比状态信息、配置信息、本地信息等，一般存储在一个节点上的数据都比较小，处于byte到kb之间。)

   Znodes维护一个stat结构，其中包括数据更改，ACL更改和时间戳的版本号，以容许缓存验证和协调更新。每次znode的数据更改时，版本号会自增。例如，每当客户端检索数据时，它也接收数据的版本号。

   存储在命名空间中每一个znode的数据的读取和写入是原子性的。znode关联的全部数据的读取，写入替换全部的数据。每一个节点都有一个访问控制列表（ACL），限制谁能够作什么。

   ZooKeeper也有临时节点的概念。只要建立znode的会话处于活动状态，就会存在这些znode。会话结束时，znode将被删除。当您想要实现[tbd]时，临时节点颇有用。

2. 有条件的更新和监听。
   Zookeeper支持监听。Client能够设置监听指定的znode。当znode更改时，将触发并删除watch。当触发watch时，Client会收到一个数据包，说明znode已更改。若是Client与其中一个ZK服务之间的链接中断，Client将收到本地通知，这些能够用于[tbd]。

3. 担保
   ZooKeeper很是快速并且很是简单。可是，因为其目标是构建更复杂的服务（如同步）的基础，所以它提供了一系列保证。这些是：

   • 顺序一致性 - 客户端的更新将按发送顺序应用。
   • 原子性 - 更新成功或失败。没有其余结果。
   • 单系统映像 - 不管服务器链接到哪一个服务器，客户端都将看到相同的服务视图。
   • 可靠性 - 一旦数据更新成功，它将保证客户端也覆盖更新。
   • 及时性 - 系统的客户视图保证在特定时间范围内是最新的。

4. 简单的API
   ZooKeeper的设计目标之一是提供一个很是简单的编程接口。所以，它仅支持如下操做：

   • create：在树中的某个位置建立一个节点。
   • delete：删除节点。
   • exists：测试节点是否存在。
   • get data：从节点读取数据。
   • set data：将数据写入节点。
   • get children：检索节点的子节点列表。
   • sync：等待数据传播。

5. 实现原理
   下图显示ZooKeeper的高级组件。
   ZooKeeper Components
   

   复制数据库是包含整个数据树的内存数据库。将更新记录到磁盘以得到可恢复性，而且写入的数据在应用于内存数据库以前会序列化到磁盘。

   每一个ZooKeeper服务器都为客户端服务。客户端只链接到一台服务器提交请求，读取请求由每一个服务器数据库的本地副本提供服务。更改状态的服务请求，写请求，由agreement协议处理。

   做为agreement协议的一部分，来自客户端的全部写入请求都被转发到Leader服务器。其他的ZooKeeper服务器（fllowers）接收来自Leader的消息提议并赞成消息传递。消息传递层负责Leader更新失败时，同步Fllowers和Leader。

   ZooKeeper使用自定义原子消息传递协议。因为消息传递层是原子的，所以ZooKeeper能够保证本地副本永远不会出现误差。当领导者收到写入请求时，它会查看写入并被应用到内存数据库时的系统状态，并在一个事务中更改状态为新状态。

6. 性能表现
   

   图中数据为910个Client去发请求，横轴为读请求在全部请求中的占比，纵轴为服务吞吐量。读请求和写请求的数据量都是1KB。servers表示ZK集群大小，即ZooKeeper的服务器数量。大约30个Client，其中ZooKeeper的Lwader节点不容许Client链接。
   在读取数量超过写入的应用程序中，它的性能尤为高，由于写入涉及同步全部服务器的状态。

7. 可靠性
   为了在注入故障时显示系统随时间的行为，咱们运行了由7台机器组成的ZooKeeper集群服务。咱们运行与之前相同的饱和度基准，但此次咱们将写入百分比保持在恒定的30％，这是咱们预期工做量的保守比率。
   

在请求失败时，可以成功的响应，图中标记的错误事件以下：
①fllower的宕机和恢复
②另外一个fllower的宕机和恢复
③一个leader的宕机
④两个fllower的宕机和恢复
⑤另外一个leader的宕机

观察图中的数据能够获得，首先看fllower宕机并迅速恢复，即便fllower宕机，ZooKeeper也可以维持高吞吐量。也许更重要的是，leader选举算法容许系统足够快地恢复以防止吞吐量大幅降低。咱们能够看到，ZooKeeper选择新leader的时间不到200毫秒。随着fllower的恢复，ZooKeeper可以在新fllower开始处理请求后再次提升吞吐量。

转载请注明出处：https://www.cnblogs.com/zooqkl