ZooKeeper 简介
ZooKeeper 通过一个可共享的分层数据注册(称之为znode)命名空间来协调分布部署的各个进程,这与文件系统很相像。与一般的文件不同,ZooKeeper提供给客户端的服务是高吞吐、低延迟、高可用和严格有序的。性能上的特点使得ZooKeeper常被用于大规模分布式集群。它的高可靠性使得它能够避免大型系统中常见的单点故障。严格有序的特点使得客户端可以实现复杂的同步逻辑。
ZooKeeper的命名空间非常像一个标准文件系统。每个名称都是用“/”分隔的一系列路径。每个znode都被用一个路径标示,每个路径都以“/”也就是根路径开始。与标准文件系统很相似,当znode还有子路径的时候不能够被删除。
ZooKeeper与标准文件系统最主要的不同是数据存储在多个znode节点上,每个znode节点上存放的数据是有限的。设计ZooKeeper的目的是存储元数据,例如状态信息,配置,位置信息等等。这些元数据通常是Kbytes级别的。ZooKeeper有一个检查机制来避免存储大于1m的文件,不过一般存储的数据大小都小于这个值。
ZooKeeper的服务可以由多台机器提供。这些机器共同维护着一个存在内存中的数据树形结构,还有事务日志以及持久化的快照。因为数据保存在内存中,所以ZooKeeper才能做到高吞吐和低延迟。但是这也有一个缺点就是它能管理的数据大小受制于内存。这也就是为什么要限制znode上存储的数据量的深层次原因。
组成ZooKeeper的每个节点都要知道集群中其他节点的信息。只要大多数接电视可用的,整个服务就可用。客户端也需要保留一份节点列表,并用这个来使用ZooKeeper服务。
客户端在一个时间只会连接一个节点。它通过建立一个TCP连接来发送请求,获取响应,得到事件通知和发送心跳信息。假如这个TCP连接中断了,客户端会重新连接另一个节点。ZooKeeper服务会在客户端第一次连接到它的时候在客户端所连接到的节点上开启一个会话。如果客户端需要连接另一个节点,这个会话会被新节点重置。
客户端发出的读请求由它所连接的那个节点处理。假如读请求在某个znode注册了一个监视事件,这个监视也由这个节点来负责。写请求会被发给多个节点,在所有节点都完成之后才会返回响应,这是为了保证一致性。同步请求也会被发送给多个节点,但是不保证一致性。因此读操作的吞吐能力会随着节点的数目增多而增加,但是写吞吐能力却会下降。
对于ZooKeeper顺序很重要。因此它用了强制性措施来保证有序。所有的更新都是统一有序的。ZooKeeper会给每个更新一个序号,称之为zxid(ZooKeeper Transaction Id)。每次更新的zxid都是唯一的。读操作是相对于写有序的。读请求的响应会被所请求的服务器标记上它(这台服务器)所处理的最后一个zxid。
英文原文:ZooKeeper Overview