作者:刘旭晖 Raymond 转载请注明出处

Email:colorant at 163.com

BLOG:http://blog.csdn.net/colorant/

更多云计算相关项目快速理解文档  http://blog.csdn.net/colorant/article/details/8255910


== 是什么 ==

 

目标Scope(解决什么问题)

 

为分布式系统提供高可靠性的协同工作机制

 

官方定义

 

ZooKeeper is acentralized service for maintaining configuration information, naming,providing distributed synchronization, and providing group services.

 

个人理解

 

基本上ZooKeeper提供了一个简化并支持特定功能的分布式文件系统接口,加上数据同步,变更通知,客户端Cache等辅助机制。基于这样的接口,用户可以自己在此之上构建逻辑,来实现各种分布式系统系统工作所需的各种功能,如配置管理,名称服务,Master选举,同步,锁等,类似于googleChubby,但是没有内建锁的支持。

 

== 如何实现 ==

 

核心思路,架构

 

zookeeper的核心思想是提供一个非锁机制的Wait Free的用于分布式系统同步的核心服务,提供简单的文件创建读写操作接口,其系统核心本身对文件读写并不提供加锁互斥的服务,但是提供基于版本比对的更新操作,客户端可以基于此自己实现加锁逻辑。客户端可以连接任意zookeeper服务节点来读写数据,zookeeper内部会分为LeaderFollower角色。

 


 

Zookeeper使用简单的同步策略,通过以下两条基本保证来实现数据的一致性:

  • 全局串行化所有的写操作
  • 保证同一客户端的指令被FIFO执行(以及消息通知的FIFO

 

客户端尽可能通过Cache和消息通知机制来减少与服务器之间不必要的信息沟通,来减轻服务器负担

 


 

数据更新操作需要服务器Leader节点协同Slave节点通过ZAB协议(基本就是两阶段提交)进行全局广播来实现,因此随着Slave节点增加,性能是下降的。

 

数据读操作可以由任意服务器节点提供,如果不是Lead节点,读操作本身不保证数据是最新的,但是可以通过一个Sync(大概就是一个空的写操作)+read的模式来实现对最新数据的读取(由前述两条基本保证可推得)

 

Zookeeper自身文件系统维护在内存中,通过定期SnapshotLog记录来实现灾难恢复

 

zookeeper对用户暴露简单的API接口,读写创建Znode数据节点,Znode节点分为普通节点和临时节点,零时节点当创建它的客户端连接结束/丢失以后会自动删除。API主要包括

 

Create : 创建node

Delete : 删除node

Exists : 判断node是否存在

get data : 读取node内存储的数据

set data : node写数据

get children : 获取一个node的子node列表

Sync : 等待数据更新的同步完成

 

 

适用领域

 

需要一个中心服务提供协同工作原语支持的分布式系统。能够将协同工作部分简单的剥离(或者添加)使用外部服务的场合。

 

细节

 

Snapshot创建时不Block数据更新操作,因此不保证精确再现zookepper某一个特定时间点的状态,不过由于串行化更新操作和数据更新的幂等特性,只要完整数量的LOG被顺序更新(可以重复),由非精确状态再现的Snapshot是可以恢复得到精确的最新状态的。

 

== 相关项目 ==

 

上下游项目

Hbase : 使用ZookeeperMaster选举等

Hadoop2.0 (YARN)

BookKeeper: Zookeeper内置项目,基于Zookeeper实现的一个Log记录系统

 

类似项目

chubby

 

== 相关文献 ==

 

项目主页

http://zookeeper.apache.org

 

Paper 论文

 

ZooKeeper: Wait-freecoordination for Internet-scale systems

A simple totallyordered broadcast protocol


Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐