Zookeeper论文笔记

论文在这里:

ZooKeeper: wait-free coordination for internet-scale systems (http://www.usenix.org/event/usenix10/tech/full_papers/Hunt.pdf)

今天看下来(还没看完),感觉上比较理解它的设计了,当然其中最关键的zab协议(基于master的原子广播)还要看看。做一些记录:

相比于chubby,zk不提供分布式锁的API。简单说起来,它提供了一套类似于文件系统的API,并通过分布式协议保证它们的一些原子特性,在这些有保证的API基础上可以实现很多典型分布式协同程序。另外它还保证操作流的线性、FIFO。

术语有:server(单个zookeeper实例),client(调用API访问server的进程),session(client到server的连接),ensemble(zookeeper server集群)

其数据模型是一个类似于文件系统的data tree,其中是znode,每个默认允许放最多1MB数据,不同与文件系统API,它没有文件handle概念,open, close等API,只按路径读写,并且只能是全读全写。不多说,以下是其API:

create(path, data, flags) // flags包括regular|ephemeral(生命周期在一个session以内,session结束就断开)|sequential(返回一个递增序列号,这个序列比在它之前创建的兄弟节点都大)

delete(path,version)

exists(path, watch)

getData(path,watch)

setData(path,data,version)

getChildren(path, watch)

sync(path) // 同步整个data tree数据,path参数暂时无用

注意到上面的API中有watch,就是可以监控znode的更新通知(不包括更新内容)而不用一直向服务器轮询。更新操作都带version,只有version匹配才更新。

以上API都有同步和异步版本,异步适用于需要并发的程序,其中需要设置回调,需要在客户端回调时保证时序。

读操作直接从那个zookeeper server本地读取,写操作需要交给master,master通过zab协议广播处理。

可以实现的协同操作原语(primitives)有配置管理、各种锁(包括简单锁、读写锁)。

使用例子例子有:Yahoo Fetching service、Katta(分布式建索引)、Yahoo Message Broker。

zookeeper有relay op log,在更新写入in-memory database之前会写入硬盘。down掉恢复时可以直接relay。

基本是这样,zab明天继续看。

你可能感兴趣的:(zookeeper,分布式)