标签：zookeeper
zookeeper：中文翻译动物园管理员，是用来协调分布式程序的服务框架。之所以起名zookeeper，是因为作者把这些分散的、分布式的系统协调任务看成是一个动物园管理员做的事情。
- 设计目标
- 操作简单：zookeeper主要用来协调处理分布式任务通过一个叫多层次的命名空间的东东，这个东东很类似文件系统。一个命名空间就是一个数据寄存器 - 称为znode，按照zookeeper的说法，多层次的命名空间就是文件与目录的关系。但zookeeper的数据是保存在内存中
- 自我复制：像下面的这个分布式系统，zookeeper主要是在各个server间复制数据，zookeeper 服务必须彼此知道对方的存在。它们将维持同一个内存镜像，通过事务控制。只要大多数的zookeeper机器可以运行，zookeeper就可以提供正常的服务。当一个client需要服务是可通过tcp链接到一个server，如果这个server挂掉了，它就会自动链接另一个server
- 有序：zookeeper通过更新一个计数器，来反映zookeeper的事务顺序，子操作可以通过这个这个计数器来实现更高层次的抽象，例如原语同步。
- 快速：zookeeper尤其在读取时表现的性能更为强悍，因为zookeeper service可以同时有很多机器提供且读是写的速度的10倍；
ZooKeeper 的多层次命名空间：zookeeper的命名空间就像常见的文件系统，每个节点的路径是唯一的，如下
- 节点
- zookeeper不像标准的文件系统，每个节点都会关联这个节点和它子节点相关的信息（zookeeper被设计主要是用来存储协调信息，比如状态信息，配置，zookeeper位置信息等）
- 条件更新和观察
zookeeper支持观察的概念，客户端可以设置对一个节点的观察岗。如果节点发生改变将会触发观察事件同时移除观察事件。当一个观察岗发现一个节点发生变化，客户端就会收到一个消息包说这个节点发生改变了。假如这个客户端和服务器不能建立连接，客户端将会收到一个本地消息通知。
- 数据保证机制
- zookeeper的运行时非常快和简单的。尽管设计目标如此，但它是构造复杂服务的基础。例如异步，它可以提供很多保证机制
- 顺序一致性-来自于客户端的更新请求将会按顺序被发送
- 原子性 - 更新结果要么是成功要么是失败，没有其它可能性。
- 单一系统映像 - 客户端不管连接到哪台服务器看到的结果都是一样的
- 可靠性 - 一旦更新被运用，它将持续覆盖客户端。
- 及时 - 客户端及时收到消息
- 简单的API接口
- zookeeper 设计要达到的目标之一是提供一个很简单的程序接口。正如下面的结果，它仅支持下面这些操作
- create
creates a node at a location in the tree
delete
deletes a node
exists
tests if a node exists at a location
get data
reads the data from a node
set data
writes data to a node
get children
retrieves a list of children of a node
sync
waits for data to be propagated
zookeeper 展现了自己高水平的组件服务，在允许一些请求异常外，组成zookeeper服务的每台服务器都会在彼此之间复制。
ZooKeeper Components
复制数据是在内存中维持整个数据树，更新的log被记录子啊磁盘上以便为了恢复，在它们更新的内存中数据库之前先被序列化到磁盘上，每个zookeeper服务器为好几个客户端提供服务，客户端连接到一台服务器上提交请求，提供服务的是本地服务的数据库，对于状态改变的数据请求和写入请求是按照一种叫做统一意见的协议。
统一意见协议是这样的，所有写入的请求都被送到一个统一的服务器，可以叫这台服务器为老大，其余的zookeeper服务器可以叫做小弟。老大发布信息，小弟们收到信息进行同步，信息传送层值关心小弟们是否成功更新，和数据是否和老大保持了一致。
zookeeper使用了常用的原子信息传送协议，正因为原子性，zookeeper才能保证各个小弟上得数据是无误的，当老大收到一条写入的数据的请求，它会计算整个系统的状态当数据被复制在各个小弟上，它把它作为一种事物并且捕获各个状态
zookeeper接口故意设计的很简单，但是你也可以实现更高水平的操作，例如，异步原语，分组等等，一些分布式程序已经开始这样这样干了
zookeeper设计特点是高性能。下面是雅虎开发团队研究的结果，特别是在读和写做对比时，zookeeper表现出了更高的性能，因为写操作是在所有的zookeeper服务器上同步数据状态
ZooKeeper Throughput as the Read-Write Ratio Varies
下面是zookeeper运行在7台服务器上发生错误时的行为记录，我们运行饱和测试，写入的速读的30%，下面是保守的数据测试
Reliability in the Presence of Errors
从上面这个图表中可以看到几点重要的观测，假如同步失败并且立马恢复，zookeeper也是能保持在一个非常高的吞吐量。更重要的是，老大选择的算法允许整个系统快速的恢复并在不影响吞吐量的情况下。zookeeper不在选出一个新老大时耗时超过200ms。第三，zookeeper在恢复后可以立马处理请求。
zookeeper已经成功的运行在很多商业项目中。在雅虎中，用来协调和失败恢复
Apache zookeeper Overview翻译
标签：zookeeper
原文地址：http://blog.csdn.net/wangjuntytl/article/details/39673633
