分布式服务难以管理, 他们容易造成死锁和竞争, ZooKepper的动机就是为了让分布式应用的责任从协调服务中解脱出来.
ZooKeeper通过共享一个类似于标准文件系统的命名空间(namespace)来协调分布式进程. 命名空间包括数据注册器(data registers) - 用ZooKeeper的语法说, 叫做 znode - 他们类似于文件系统中得文件和目录. 和典型文件系统不一样的是, ZooKeeper设计不是用来做存储的, 它把数据都保存在内存中, 这意味着它可以达到高吞吐量和低延迟的效果.
ZooKeeper的实现致力于高性能, 高可用, 严格的顺序访问. ZooKeeper的性能让他可以用于大型分布式系统.它的可靠性防止出现单点故障. 严格的顺序意味着复杂的同步原语也可以在客户端实现.
ZooKeeper跟他协调的分布式进程一样, 它自己也是个冗余结构, 分布在多个主机上, 这叫做一个"集合"(ensemble)
ZooKeeper Service
这些组成ZooKeeper服务的服务器必须彼此之间知道对方的存在. 他们维护了一个内存中的状态图, 并将事务日志以及快照做持久化存储. 只要大部分的服务器是可用的, ZooKeeper的服务就可用
客户端连接到单独的ZooKeeper服务器. 客户端维护了一个TCP连接, 它用来发送请求, 获取响应, 获取观察时间(watch events), 发送心跳检测. 如果这个TCP连接中断了, 客户端会连接到另一个服务器.
ZooKeeper为每次更新都标上一次数字标签, 这些数字代表ZooKeeper事务的顺序. 后续操作可以利用这个顺序是先更高层次的抽象, 例如同步原语.
在"以读为主"(read-dominant)的工作场合速度特别快. ZooKeeper 应用跑在成千上万台机器上, 它的度性能比写性能好得多, 大约为 10:1
ZooKeeper提供的命名服务很像标准的文件系统. 一个名字就是一个由斜杠(/)分隔的路径(sequence of path).
ZooKeeper 分层命名空间
跟标准文件系统不一样, ZooKeeper命名空间中的检点可以和数据相关联. 就像是一个允许一个文件同时是一个目录的文件系统. (ZooKeeper是设计用来存储协调数据的: 状态信息, 配置, 位置信息, 等等. 所以每个节点中得数据通常都很小, 从字节到KB之间都有). 我们用术语 znode 来说明谈论是ZooKeeper的数据节点.
Znode维护了一个状态结构, 它包括数据变更的版本号, ACL变化, 时间戳, 用于缓存验证和协调更新. 每当znode的数据改变, 版本号都会增加. 例如, 每当客户端获取数据时, 他同事也会获取数据的版本号.
Znode中的数据是自动可读可写的. 读操作获得跟一个znode相关的数据字节, 写操作覆盖所有的数据. 每个节点都有一个访问控制列表(ACL)用来限制谁可以读写.
ZooKeeper也有临时节点的概念. 这些znode只在创建它的会话期间存在. 当会话结束, 节点就会被删除. 临时节点在你想实现[tbd]的时候非常有用.
ZooKeeper有监视器(watches). 客户端可以在znode上设置一个监视器. 一个监视器在znode变化时会被触发并删除. 当一个监视器被触发, 客户端会收到一条znode变化的消息. 如果客户端和ZooKeeper服务器间的连接中断了, 客户端会收到一个本地通知. 这些可以用于[tbd]
ZooKeeper很快很简单. 因此他的目的, 思想, 都是作为更复杂的服务的构建基础, 例如同步, 它提供了一系列的保证. 如下:
ZooKeeper的设计目标之一就是提供非常简单的编程接口. 因此, 它仅仅支持下面的操作:
create: 创建一个节点
delete: 删除一个节点
exists: 测试节点是否存在
get data: 从节点中读取数据
set data: 将数据写入到一个节点中
get children: 获取节点的子节点
sync: 等待数据传输
ZooKeeper组件图展现了ZooKeeper服务的高级组件. 通过请求处理器, 组成ZooKeeper服务的每个服务器都会复制组件的副本.
ZooKeeper Components
这个冗余数据库是一个包含了整个数据树的内存数据库. 更新日志会被记录到硬盘中, 以用于恢复时使用, 而写操作在他们被应用到内存数据库之前, 会被序列化到硬盘中.
Zookeeper Tutorial 1 -- Overview
原文：http://www.cnblogs.com/zemliu/p/3554544.html