论文在这里:
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明天继续看。