zookeeper 介绍(译)

zookeeper (译)

原文地址: http://zookeeper.apache.org/doc/trunk/zookeeperOver.html

zookeeper: 为分布式应用提供协调服务

zookeeper 是一个分布的,开源的协调服务. zookeeper 提供一系列的简单原语，为分布式应用提供靠可用的服务(分布式同步,维护配置,域名服务, 组服务). 它的编程被设计的很简单,
在熟悉文件系统的属性结构后就可以使用它的数据模型。 zookeeper 运行在java和绑定Java和C.

众所周知,协调服务式是很难处理的. 它们特别难于处理一些问题,例如: 竞争条件和死锁问题. zookeeper设计原则就是为了避免分布式应用程序从头实现协调服务.

设计目标

简单

zookeeper允许分布式进程,通过一个共享的命名空间(类似于标准的文件系统)来相互协调合作. 命名空间由一个个叫znodes的数据寄存器构成, 对zookeeper而言，它们就类似于文件和目录. 和传统的文件系统不同，zookeeeper 将数据存储在内存中, 可以实现高吞吐量和低延迟.

zookeeper的设计重视高性能,高可用, 严格的顺序访问. 对于zookeeper的性能而言，它完全可以应用在大型的分布式系统中. 即使单点故障后仍然保证它的可靠性.

复制性

与它协调的分布式进程一样，zookeeper自身刻意通过一组集群主机复制.

组成zookeeper服务各个server必须彼此知道对方. 他们维持在一个内存状态的镜像中,以及一个事务日志和一个持久化存在的快照中. 只要大部分的服务器是可用的，zookeeper服务就是可用.

连接在一台zookeeper服务器的客户端. 它们与服务器通过tcp连接保持通信(发送请求,获取相应，获取监听事件,发送心跳),如果他们的连接断了，再次连接后，他们有可能连接在不同的服务器上.

zookeeper 更新操作是有序的

zookeeper将每个更新标记一个数字,这个数字反映着zookeeper事务的顺序性. 后面的操作可以使用实现了更高的抽象, 例如:sync.

快速读取

在”read-dominant”模式下,zookeeper读取非常快. zookeeper应用可以运行在上千台机器上, 它执行读取比写更有优势，他们的执行效率比例是10:1.

数据模型和命名空间

zookeeper提供类似于标准的文件系统的命名空间. 每一名称就是一个序列路径，元素通过”/”分开. 每个节点都是通过一个路径表示.

节点与临时节点

zookeeper中每个节点都可以关联数据和子节点. zookeeper中节点设计存储“coordination data” (状态信息,配置,位置信息..),所以每个节点存储数据通常很小, 大概在千字节范围内. 我们这样使用节点是为了保证zookeeper 数据节点的简洁.

znodes 维持着一个状态结构，它包括数据改变的版本号, ACL改变,和时间戳, 允许缓存验证和协调更新. 每次znodes的数据改变,对应的版本号就会增加. 一个client接受节点数据时候,也会接受它的版本信息.

存储在命名空间上的数据节点的读写都是原子性的. 读：从节点中读取所有数据, 写：替换原有节点的内容. 每个节点都具有访问权限ACL,约束操作权限.

zookeeper也具有临时节点的概念, 这些临时节点生命周期和创建它的session 息息相关. 当session 结束后znode也将被删除.
临时节点对于实现tbd很有用.

条件更新和监控

zookeeper 支持监控概念. clients 可以对某一个节点设置监控, 当被监控的znodes发生改变时，监控事件就会被触发,触发完成后自动删除监控.
监控被触发时,clients会收到一个监控节点被改变的通知包. 如果clients与zookeeper server 连接断开了，client就会接受到一个本地的通知 .

提供的保证

zookeeper非常而简单. 尽管它是复杂服务的结构的一部分, 但它提供了一系列的保证.
- 顺序一致性 - 来自客户端的发送更新竟会按顺序执行
- 原子性 - 无论更新成功或者失败，不会出现部分修改的情况.
- 单系统镜像 - 客户端无论连接哪一个server, 都将看到的相同的视图 .
- 可靠性 - 一旦一个更新被应用, 这个更新将立即被持久化, 直达客户端再次更新修改，否则更新的值永久不变.
- 及时性 - 客户端看到视图保证在在“特定的时间内” 是最新的数据

ApI简述

zookeeper的设计目标之一就是提供非常简单的编程接口. 正因此才只提供这些操作:

create

  在树下创建一个节点

delete

  删除节点

exists

  判断节点是否存在某一位置

get data

  从节点中读取数据

set data

  将数据写到节点中

get children

  检索某一节点下的所有子节点

sync

  等待数据传播

实现

zookeeper服务的高级组件.除了请求处理器(request processor), 每个服务器都是由每个组件的自有拷贝.

replicated database 是内存级数据库. 它存储了整个树形数据. 更新操作在 应用到内存数据库之前，会以日志的形式序列化存储到磁盘上，以便恢复.

每个zookeeper服务器为clients提供服务. clients连接到一个server提交它的请求. Read请求可以直接从连接服务器上数据备份获取. 改变状态请求和 write请求由一致协议处理.

作为一致协议的一部分,来自所有客户端的请求都会分发到一个叫做leader的服务器, 其余server作为follower, followers接受来自leader的消息并根据消息最终达成一致. 消息传递层负责更换失败leader和同步follower和leader信息.

zookeeper使用了自定义的一致协议， 由于消息是原子性的,zookeeper 可以保证本地副本不会发散(diverge). leader接受到写请求，会计算写入系统后的状态, 将其转换成一个捕获此状态的事务.

使用

zookeeper编程接口比较简单. 使用它高等顺序操作中, 例如: 同步原语、组成员管理、所有者关系管理等.

性能介绍

zookeeper的设计原则之一就是高性能. 下图是在Yahoo的zookeeper研发团队的对zooKeeper集群的读写的测试结果. 从结果看出zookeeper在读写比例越大时候，表现的性能越高,因为写操作需要在所有的servers进行同步.

图表显示结果使用的是zooKeeper 3.2版本，运行在2个2Ghz的Xeon处理器和两个SATA 15K RPM驱动器的服务器上. 一个磁盘驱动器作为ZooKeeper日志的专用设备. 快照写在系统的磁盘驱动上. 读写请求都是1K. “servers”代表所有的zookeeper服务器. 另外有30台服务器模拟clients. zookeeper服务配置中禁止了,所有client连接leader.

提示：3.2版的r/w性能是3.1版的2倍

可靠性描述

下面基准测试报表,显示zookeeper出现错误的可靠性.
下面是被标记的事件:

1. 一个follower出现故障并恢复的情况
2. 另外一个follower出现故障并恢复的情况
3. leader出现故障情况
4. 有两个follower出现故障并恢复的情况
5. 另外一个leader发生故障情况

为了展示当发生故障时候系统的行为表现，我们的zookeeper服务由7台物理构成. 和上面的测试一样我们使用相同的基准测试, 但是这次我将写的百分比设置为保守设为了30%.

图表可以显示以下几点:
1. 如果followers发生故障能够快速恢复过来,zookeeper服务仍然可以维持一个相当的高的吞吐量.
2. 第二点很重要,leader选举算法可以让系统快速恢复,避免系统吞吐量实质性下降. 在我们观察中zookeeper选举一个新的leader不超过200ms.
3. 一旦followers恢复并且开始处理请求, zookeeper服务就可以恢复高吞吐率.

zookeeper 项目

zookeeper 目前已经成功的被应用到很多应用程序中. 雅虎也在使用它, 为雅虎提供协调和故障恢复服务! Message Broker是具有高扩展性的订阅发布系统(kfaka也在使用zookeeper)，管理着成千上万个消息同步主题. Yahoo!的很多广告系统也使用ZooKeeper来实现可靠服务