Zookeeper学习笔记(概要)

原文链接:http://zookeeper.apache.org/doc/current/zookeeperOver.html

1.Zookeeper是什么?

ZooKeeper是一种用于分布式应用程序的分布式开源协调服务。意思就是,比如几个人想要协商一件事情,就需要一个协商平台来帮助他们完成,比如投票选举leader,那得有个选举桌吧,每个人得发几张选举票吧,Zookeeper就是把“基础设施”的活儿给干了,让开发者的精力只放在“协调”上。

2.设计目标

ZooKeeper很简单。(可以理解为轻量级文件目录服务)
ZooKeeper允许分布式进程通过共享的分层命名空间相互协调,该命名空间的组织方式与标准文件系统类似。名称空间由数据寄存器组成 - 在ZooKeeper用语中称为znodes - 这些与文件和目录类似。与专为存储而设计的典型文件系统不同,ZooKeeper数据保存在内存中,这意味着ZooKeeper可以实现高吞吐量和低延迟数量。
高性能
ZooKeeper实现非常重视高性能,高可用性,严格有序的访问。ZooKeeper的性能方面意味着它可以在大型分布式系统中使用。可靠性方面使其不会成为单点故障。严格的排序意味着可以在客户端实现复杂的同步原语。
数据同步
与它协调的分布式进程一样,ZooKeeper本身也可以在称为集合的一组主机上进行数据同步。
在这里插入图片描述
组成ZooKeeper服务的服务器必须彼此了解。它们维护内存中的状态图像,以及持久化存储中的事务日志和快照。只要大多数服务器可用,ZooKeeper服务就可用。
客户端连接到单个ZooKeeper服务器。客户端维护TCP连接,通过该连接发送请求,获取响应,获取监视事件以及发送心跳。如果与服务器的TCP连接中断,则客户端将连接到其他服务器。
有序
ZooKeeper使用反映所有ZooKeeper事务顺序的数字标记每个更新。后续操作可以使用该顺序来实现更高级别的抽象,例如同步原语。

它在“读取主导”工作负载中特别快。ZooKeeper应用程序在数千台计算机上运行,​​并且在读取比写入更常见的情况下表现最佳,比率大约为10:1。

3.数据模型和分层命名空间

ZooKeeper提供的名称空间非常类似于标准文件系统。名称是由斜杠(/)分隔的路径元素序列。ZooKeeper名称空间中的每个节点都由路径标识。
在这里插入图片描述

4.节点和临时节点

与标准文件系统不同,ZooKeeper命名空间中的每个节点都可以包含与之关联的数据以及子项。这就像拥有一个允许文件也是目录的文件系统。(ZooKeeper旨在存储协调数据:状态信息,配置,位置信息等,因此存储在每个节点的数据通常很小,在字节到千字节范围内。)我们使用术语znode来说明我们正在谈论ZooKeeper数据节点。具体意思下图可以解释,这里也通过命令解释一下,比如,set /week 123,意思就是我在目录/week上存放了123,当我get /week的时候,就可以取到123。在这个基础之上,我还可以 set /week/temp 456,然后get /week/temp 也可以得到456,就是一个节点即是目录,也是Map的一个Key。自己实现的话也很简单,树+HashMap。
在这里插入图片描述
Znodes维护一个stat结构,其中包括数据更改,ACL更改和时间戳的版本号,以允许缓存验证和协调更新。每次znode的数据更改时,版本号都会增加。而每当客户端检索数据时,它也接收数据的版本,从而返回相对应的信息。自己去设计实现的话,就是搞一个线程安全的队列。
存储在命名空间中每个znode的数据以原子方式读取和写入。读取获取与znode关联的所有数据字节,写入替换所有数据。每个节点都有一个访问控制列表(ACL),限制谁可以做什么。
ZooKeeper也有临时节点的概念。只要创建znode的会话处于活动状态,就会存在这些znode。会话结束时,znode将被删除。

5.有条件的更新和watch机制

ZooKeeper支持watch的概念。客户端可以在znode上设置watch监视。当znode更改时,将触发并删除watch(注意这里是触发并删除,也就说watch的监听只会生效一次,要实现永久监听,要实现反复注册,这个业务很多开源的java客户端都有封装)。触发监视时,客户端会收到一个数据包,指出znode已更改。如果客户端与其中一个ZooKeeper服务器之间的连接中断,则客户端将收到本地通知。

6.担保

ZooKeeper非常快速而且非常简单。但是,由于其目标是构建更复杂的服务(如同步)的基础,因此它提供了一系列保证。这些是:

  • 顺序一致性 - 客户端的更新将按发送顺序应用。
  • 原子性 - 更新成功或失败。没有部分结果。
  • 单系统映像 -无论服务器连接到哪个服务器,客户端都将看到相同的服务视图。
  • 可靠性 - 一旦应用了更新,它将从那时起持续到客户端覆盖更新。
  • 及时性 -系统的客户视图保证在特定时间范围内是最新的。

7.简单的原始API

ZooKeeper的设计目标之一是提供一个非常简单的编程接口。因此,它仅支持以下操作:

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

8.应用

除请求处理器外,构成ZooKeeper服务的每个服务器都复制其自己的每个组件的副本。
在这里插入图片描述
复制数据库是包含整个数据树的内存数据库。更新将记录到磁盘以获得可恢复性,并且写入在应用于内存数据库之前会序列化到磁盘。
每个ZooKeeper服务器都为客户端提供服务。客户端只连接到一台服务器以提交请求。读取请求由每个服务器数据库的本地副本提供服务。更改服务状态,写请求的请求由协议协议处理。
作为协议协议的一部分,来自客户端的所有写入请求都被转发到称为leader的单个服务器。其余的ZooKeeper服务器(称为follower)接收来自leader的消息提议并同意消息传递。消息传递层负责替换失败的leader并将follower与leader同步。
ZooKeeper使用自定义原子消息传递协议。由于消息传递层是原子的,因此ZooKeeper可以保证本地副本永远不会发散。当leader收到写入请求时,它会计算应用写入时系统的状态,并将其转换为捕获此新状态的事务。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章