ZooKeeper学习笔记——概述

What

    是一个分布式应用的高效协同服务，开放了一些公共服务，如维护配置信息、命名管理、分布式同步、集群服务等。可用于实现一致性集群管理，leader选举和特定的业务协议等。

设计目标

简单

    ZK允许分布式进程间可以互相协同，这是通过共享一个组织结构类似于标准文件系统的层级命名空间来实现的。该命名空间由一些数据暂存器(registers)，称为znodes，他们类似于文件和目录。但区别于典型的文件系统是为了存储持久化存储，ZK的数据会维护在内存中，所以拥有高吞吐量和低延迟。

可复制

    支持在一组主机集群上进行复制

    这些server服务器必须互相感知，他们在内存中维护了一个状态镜像，以及持久化存储的事务日志和快照。只要大多数ZK服务器是可用的，整个ZK服务就是可用的。

    客户端维护了与到某一台ZK服务器的TCP连接，通过该连接可以发送请求、接收应答、接收监听事件并且发送心跳。如果该TCP连接断开，客户端将尝试连接其他的ZK服务器。

有序性

    ZK强制server间的互相更新基于有序的事务序号，在此基础上可以实现更高级的抽象，比如同步原语。

快速

对于读操作特别快。ZK集群部署上千台机器，读操作表现非常完美，读写速率大致是1:10。

数据模型和层级命名空间

ZK提供的命名空间非常类似于标准文件系统。一个名称(name)是指由‘/’分隔的路径元素的一个序列 

nodes和临时nodes

      不同于标准文件系统，ZK命名空间里的每一个node都可以拥有数据内容，就像其子节点一样。可以理解为文件系统中的一个文件，也可以是一个目录。ZK的存储设计是用于存储协同数据(状态信息，配置，位置信息等，所以node存储的数据应该小，通常在KB数量级)。后面以znode术语替代讨论ZK node。

      对于节点数据或ACL的修改，znode维护了一个包含版本序号的状态结构体(包含时间戳)，这也有助于缓存数据的校验和协同更新。每次修改znode数据，版本序号也递增。此外，客户端每次获取数据，同时也会得到数据的版本信息。 在一个命名空间下的每个znode的数据，其读写操作都是原子性的。读取操作将获取相关znode的所有数据，写操作将覆盖所有数据，每个节点都有一个ACL用于约束这些操作。

      ZK也有临时节点的概念，这些节点只有创建他们的session存活的时候才存在。当session结束，这些节点就会被删除。

更新与监听(watches)

      ZK支持监听，客户端可以在znode上设置一个监听(watch)，当znode变更监听(watch)将会被触发并被移除。当一个监听(watch)被触发，相应的客户端将收到znode变更的通知。此外当客户端和一个ZK服务器的连接断开，客户端将收到一个本地通知。

ZK给予的保证

ZK非常快而且简单，所以很适用与复杂系统的基础组件。ZK提供如下保证：

• 顺序一致性：一个客户端的多个update操作，将会按照他们的发出顺序进行。
• 原子性：update操作要么成功要么失败，没有中间状态。
• 单系统镜像：无论客户端连接到集群中的哪台服务器，其查看到的内容都是一样的。
• 可靠性：只要update操作成功，结果将被持久化。
• 时效性：客户端对系统的视图保证在一定时间内是最新的。

简洁的API

ZK的另一个设计原则，提供非常简单的编程接口，只有这些操作：

• create 在目录树的某个位置上创建一个node
• delete 删除一个node
• exists 判断某个目录的node是否存在
• get data 从一个node读取数据
• set data 向一个node写数据
• get children 读取一个node的子节点列表
• sync 等待数据被传播

ZK的实现

      replicated database：是一个内存数据库，维护了所有的数据树。更新记录会存储到磁盘上，可恢复；对磁盘的序列化写入是在应用于内存数据库之前。

      每个ZK server为客户端提供服务，读请求服务是通过每个server的本地database副本提供的。写请求是通过一个一致性协议来处理的。

      作为一致性协议的一部分，所有客户端的写请求都被转发到一台服务器server，称之为leader。其他的服务器成为follower，接收leader传送的消息提案并达成一致。消息传递层关注失败时leader的替换，以及leader对followers的同步。

      ZK使用一个自定义的原子性信息协议ZAB(zookeeper atomic broadcast)。由于消息传递层的原子性，ZK可以保证本地的副本不会出现分歧。当leader接收到一个写请求，它会计算出该写入生效的系统状态，并通过事务来处理整个过程。

性能

      ZK设计的目标之一就是高性能，特别是读远多于写的应用，毕竟写操作会涉及所有server之间的状态同步(读远超写是协同服务的一个典型特征)。 

可靠性

                                     七台服务器，30%的读操作数据

      上图可以体现出：1. followers失败了可以快速恢复，即使出现失败ZK也能维持一个较高的吞吐量；2. leader选举算法使得系统能快速恢复(ZK选出一个新的leader耗时少于200ms)，避免吞吐量的大幅度下降；3. 当follower恢复并开始处理请求，ZK又能提升吞吐量。