一、zookeeper: 一个应用于分布式系统的分布式协调服务器
zookeeper是一个针对于分布式应用的分布式、开源的协调服务器。它提供了一系列基础服务供分布式系统用来实现同步、配置管理、分组以及命名等上层服务。它使用了类似于树型文件系统的数据模型，运行于Java环境并且提供了非常容易使用的Java跟C的编程接口。
协调服务要想保证正确性是很困难的，非常容易出现资源竞争跟死锁问题。而zookeeper提供了这方面的服务，避免轮子的重复开发。
二、设计目标
Zookeeper是简单的：zookeeper提供了类型于文件系统的名称空间，分布式处理器通过共享这个名称空间来实现协调服务。这个名称空间有znodes构成，znodes被用来存储数据。zookeeper的所有数据保存在内存里，这保证了其具有很高的吞吐量跟较低的延迟。
Zookeeper将实现的重点放在了高性能，高可用，严格的访问顺序等方面。它的高性能保证了其可用于大型的分布式系统。高可用保证了其可处理单点故障问题。顺序型保证了可以在客户端实现了复杂的同步原语。
Zookeeper是可复制的：像其他分布式系统一样，zookeeper也是通过复制技术使得多个zookeeper服务成为一个集群。
集群中的每个zookeeper服务器都可感知其他服务器的存在。它们通过将事务日志跟快照文件保存到持久化设备保证了其在内存中具有同意的镜像状态。只要集群中，多数的服务可用，那么集群整体亦是可用的。
客户端是与单一的一个zookeeper服务器进行交互的。它通过使用TCP连接来发送请求，获取回应跟响应事件同时发送心跳。 如果客服端于zookeeper的TCP连接被异常断开，则会自动连接到另外一台zookeeper服务器上。
Zookeeper是有序的：zookeeper会给每个更新操作打上一个数字标签来显示事务操作的顺序性。有序操作可被用来实现一些高级的抽象功能，比如同步原语。
Zookeeper是快速的：zookeeper在读远大于写的场景表现出非常优异的性能。在大量zookeeper构成的集群中，往往读的性能将是写的10倍。
三、数据模型
zookeeper的名字空间非常类似于一个标准的文件系统。一个名字是有一个以/分割的路径组成。 zookeeper中的任何一个节点都等同于一个路径。
四、节点与临时节点
同文件系统不一样的是，zookeeper中节点不仅可以保存数据也可以拥有子节点。zookeeper主要用来保存一些协调信息：（状态、配置、位置等信息），这些信息通常都非常小只在KB级别。 通常我们使用将zookeeper节点简称为znode。
每个znode都有一个状态，这个状态包含了数据的版本信息、ACL（访问控制 ）以及时间戳，这些信息可用来进行缓存校验跟协调更新。每当znode数据更新后，它的版本都会增加，同时每次查询操作都会返回节点的版本信息。
znode的读写是原子性的，并且通过ACL来限制用户的操作权限。
zookeeper也提供了临时节点的概念。只要节点的创建者的SESSION还存活，那么这些临时节点就会一直存在，直到连接断开SESSION被销毁。如果你想实现
[tbd]，那么临时节点将非常有用。
ps: what fuck the tbd is ?
五、有条件的更新与监视器
zookeeper提供了监视器的概念。客户端可以在一个节点上设置一个监视器，当节点的数据发生变化时，这个监视器将被触发同时会被移除。当客户端收到监视器被触发的报文则说明节点数据发生了变化。当客户端与其中一台zookeeper服务器断开，则客户端会收到一个本地通知，这一特性将在[tbd]进行使用。
六、保证
zookeeper即快又简单。鉴于它的目标是为构建复杂系统提供基础服务，例如同步，所以它提供以下几方面的保证:
1、
顺序一致性，一个客户端的所有更新将被有序的执行，这个顺序跟这个客户端发送这些请求的顺序一致
2、
原子性，更新操作要么成功要么失败，不存在第三种不完整的状态
3、
单一系统镜像、无论客户端连接到集群中那台zookeeper服务器，它都会看到相同的数据视图
4、
可靠性，一旦数据被更新，它将一致保留，直到下一次被更新
5、
实时性，客户端看到的数据是最新的，但这有一个时间窗口。
ps：这项属于伪实时性，最终需要通过同步数据操作在一个时间窗口将数据同步到其他服务器上，达到最终一致性。
七、简单的API
zookeeper的另一设计目标是提供极其简单的编程接口，鉴于此，其只提供了以下几个操作：
create
在一个指定路径上创建节点
delete
删除一个节点
exists
判断节点是否存在
get data
从一个节点上获取数据
set data
给一个节点设置数据
get children
获取一个节点的子节点
sync
等待数据同步完成
关于这方面更深入的讨论以及如何使用它们实现上层应用，请参考
[tbd]
八、实现
zookeeper的简化组件图如下：
这个可复制的数据库是一个包含整个数据空间的内存数据库。为了可恢复性，所有的更新操作都会被记录到磁盘里，同时所有的写操作也都会先被序列化到磁盘之后才会对内存数据库做更新。
每个zookeeper服务器都可以为客户端提供服务，客户端连接其中一个服务器，这个服务器使用本地数据库来响应读请求。对于更新操作，zookeeper集群通过使用一致性协议来完成。
作为一致性协议额一部分，所有来自客户端的写请求将会被转发至一台服务器，这个服务器被称为
leader，其中的服务器则被成为
followers。
followers接受来自
leader发起的投票信息并对消息投递进行投票。这个消息层将会在
leader挂掉时进行
leader选举
zooKeeper采用一个自定义的信息原子操作协议，由于信息层的操作是原子性的，ZooKeeper能保证本地的复制数据库不会产生不一致。当leader接收到一个写请求，它计算出写之后系统的状态，把它变成一个事务。
阅读(1228) | 评论(0) | 转发(0) |
