ZooKeeper架构学习（一）

ZooKeeper学习（一）

一、简单介绍(SimpleIntro)

Zookeeper是hadoop的一个开源子项目，Zookeeper作为一个分布式的服务框架，主要用来解决分布式集群中应用系统的一致性问题，它能提供基于类似于文件系统的目录节点树方式的数据存储，但是 Zookeeper 并不是用来专门存储数据的，它的作用主要是用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理。

ZooKeeper主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。

ZooKeeper会维护一个具有层次关系的数据结构，它非常似于一个标准的文件系统。

二、设计目标(DesignGoals)

1.简单:Zookeeper让分布式进程通过共享的一个类似于文件系统的namespace进行交互， namespace包括数据注册者，也可以成为znodes。与典型文件不太类似的地方就是，文件系统是存储在磁盘上，zookeeper数据是存在内存中，以实现zookeeper的高吞吐量和低延迟。

2.集群：zookeeper自己也是分布式。Zookeeper在内存中维护了server的状态，同时把事务log和内存数据库快照持久化到磁盘。只要多数server正常，zookeeper服务就是可用的。

3.客户端通过TCP长连接跟服务端通信，发送请求、得到响应、得到监控事件、发送心跳。

系统模型如下：

三、数据模型和节点结构(Datamodel and the hierarchial namespace)

Namespace(Znode)采用一种类似于一个标准文件系统的数据结构。Name在一个顺序的路径下，每个节点被(/)分隔。

Zookeeper这种数据结构有如下这些特点：

1.每个子目录项如 NameService 都被称作为 znode，这个 znode 是被它所在的路径唯一标识，如 Server1 这个 znode 的标识为 /NameService/Server1

2.znode可以有子节点目录，并且每个 znode 可以存储数据，注意 EPHEMERAL 类型的目录节点不能有子节点目录

3.znode是有版本的，每个 znode 中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据

4.znode可以是临时节点，一旦创建这个 znode 的客户端与服务器失去联系，这个 znode 也将自动删除，Zookeeper 的客户端和服务器通信采用长连接方式，每个客户端和服务器通过心跳来保持连接，这个连接状态称为 session，如果 znode 是临时节点，这个 session 失效，znode 也就删除了

5.znode的目录名可以自动编号，如 App1 已经存在，再创建的话，将会自动命名为 App2

6.znode可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是 Zookeeper 的核心特性，Zookeeper 的很多功能都是基于这个特性实现的，后面在典型的应用场景中会有实例介绍

四、原则

1.顺序一致性：来自客户端的更新顺序的发送到服务端。

2.最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。

5.原子性：更新只能成功或者失败，没有中间状态。

2.可靠性：具有简单、健壮、良好的性能，如果消息被到一台服务器接受，那么它将被所有的服务器接受。

3.实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口

4.等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。

6.顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。

五、Api简单(Simple Api)

一个简单交互指令集也是zookeeper设计目的之一。下面一些常用的指令

create

创建一个节点

delete

删除一个节点

exits

判断一个节点是否存在

get data

读取一个节点的数据

set data

往一个节点写数据

get children

读取一个节点下的所有子节点

六、实现原理(Implementation)

这ReplicatedDatabase 是一个内存数据库，包含了整个数据。“修改操作”写进磁盘，以备恢复。“写操作”在写入内存数据库之前，先写进磁盘。

所有来自客户端的写操作都提交到Leader server上。其他server，称作follower，从leader同步信息。

Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和Leader的状态同步以后，恢复模式就结束了。状态同步保证了Leader和Server具有相同的系统状态。

为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。

每个Server在工作过程中有三种状态：

LOOKING：当前Server不知道leader是谁，正在搜寻

LEADING：当前Server即为选举出来的leader

FOLLOWING：leader已经选举出来，当前Server与之同步