zookeeper 官方文档——综述
zookeeper设计上易于编码,数据模型构建在我们熟悉的树形结构目录风格的文件系统中。
zookeeper运行在java中,同时支持java和C 语言。正确的实现协调服务是公认的难干的差事。 他们及其容易出错,比如资源竞争和死锁.
zookeeper命名空间由数据寄存器组成,zookeeper中,我们称他为,znodes, 这跟文件和目录非常类似..
不像一个典型的文件系统,其设计时就是为了存储数据.而zookeeper 数据是保存在内存中的,这也就意味着zookeeper能实现一个高吞吐量和低延迟.(因为内存操作效率高)
zookeeper是有副本的, 就像分布式的处理协调服务一样,zookeeper 本身就打算在服务器集群中使用副本机制,我们称之为全体.
组成zookeeper 服务的所有机器节点互相之间都必须感知到对方. 他们维护着当前机器状态的内存快照,有事务日志和持久化存储的快照.
客户端连接到其中一台zookeeper服务器,客户端和zookeeper服务器保持一个tcp连接,通过tcp连接发送请求获得响应,
获取事件监听,发送心跳等等. 如果TCP连接被中断了,客户端会连接到另外一台zookeeper服务器.
zookeeper是有序的, zookeeper给每一次更新操作都赋予一个编号,他这个编号反应了对zookeeper的事务性修改顺序.
随后的操作能够使用这一顺序去实现更高级别的抽象,比如同步原语.
节点和临时节点
不像标准的文件系统,zookeeper 命名空间中的每个节点能够有数据关联,也有子节点.
就好比是文件系统中一个文件对象即可以是一个文件也可以是一个文件夹.(zookeeper被设计用来存储协调数据:
状态信息,配置信息,位置信息等等, 因此数据存储在每个节点中通常非常小,从几个字节到几千字节之间),
我们使用znode这个术语来使得我们讨论zookeeper数据节点相关内容时语义更加清晰明确.
znode管理着包含这一个状态结构数据,它包含数据修改的版本号,ACL修改及时间戳, 允许缓存校验和协调更新.
znode数据每修改一次,版本号加一. 举个实际的例子,每次客户端收到数据的同时,也收到当前数据的版本号.
zookeeper 也有会话级别的节点的语义支持,这些znode节点随着会话的创建而激活,会话的结束的时候节点被删除.
条件更新和监听
zookeeper支持监听, 客户端能够设置监听znode节点. 当znode节点变更时可能触发或者移除监听.当监听事件被触发了,
客户端将会收到数据通知包,告诉客户端节点数据被修改了. 同时如果当前客户端和zookeeper节点的连接被断开了.
zookeeper的保证
zookeeper 简单而性能优异. 由于他简单快速的目标,他成为构建许多更加复杂服务的基础,比如同步服务,他提供了一系列的保证.
1 顺序一致性: 来自客户端的更新操作将会按照顺序被作用.
2 原子性操作: 更新要么全部成功,要么全部失败,没有部分的结果.
3 统一的系统镜像: 无论客户端链接的是哪台服务器,都能获得同样的服务视图,也就是说他是无状态的.
4 可靠性保证: 一旦写入操作被执行(作用到服务器),这个状态将会被持久化,直到其他客户端的修改生效.
5 时间线特性:客户端访问服务器系统镜像能在一个特定时间访问内保证当前系统是实时更新的
简单的操作API
zookeeper的设计原则之一就是提供简单的编程接口. 因此,他仅仅提供了以下几个操作.
使用情况
zookeeper的编程接口 设计的非常简单,但是用这些能实现一些其他更高级别的操作,比如同步原语,对成员进行分组和选举等等.
性能
zookeeper 被设计的号称高性能框架,但是事实情况如何呢?
来自雅虎的zookeeper开发团队的研究证明了这点.
(可以查看下zookeeper 吞吐量随着读写比例变化的图表,即上图)
在读占主要比例的应用中,性能尤佳,因为写操作涉及到服务器之间状态的同步.尤其是在协调服务这个典型案例中表现的尤其突出.
zookeeper 吞吐量和读写比例的变化关系用的是zookeeper3.2版本,运行在 双核 2Ghz 及SATA 15k RPM 处理器配置的服务器中.
其中一个负责zookeeper 日志设备. 快照信息写入操作系统驱动中.
写入请求是1Kb写入, 读请求也是1kb的写入(读写单元都是1Kb).
servers 标示着 整个zookeeper的集群大小, 即组成zookeeper服务的服务器数.
可靠性
为了展示下,我们系统随着时间的推移及错误出现,我们运行了一个一个由7个机器组成的zookeeper服务中,我们使用和此前一样饱和度的基准测试,
这个图中有几个比较关键的观测点.首先,如果从节点失败并快速恢复了,即使从节点失败了,zookeeper仍然能够承受住一个比较高的吞吐量.
但是,更为重要的一点事,leader节点的选举算法 能让系统快速恢复,防止吞吐量在短时间内迅速降低.观察发现, zookeeper能在200毫秒内选举出新的leader节点,
zookeeper 项目
zookeeper 已经在许多企业级应用中获得成功,雅虎内部使用zookeeper 进行协调和失败恢复服务,及消息中间人服务
他管理成千上万个消息主题,可以实现副本和数据传输的功能.
zookeeper在雅虎内部还用于数据抓取服务,即网络爬虫,同时致力于失败恢复.