zookeeper的基本原理和部署

一、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的数据模型

Zookeeper 会维护一个具有层次关系的数据结构，它非常类似于一个标准的文件系统，如图所示：

zookeeper的数据结构具有如下特点：

1. 每个子目录项如 NameService 都被称作为 znode，这个 znode 是被它所在的路径唯一标识，如 Server1 这个 znode 的标识为 /NameService/Server1。如果创建与一个已经存在的路径标示相同标示的节点，则会报错。
2. znode 可以有子节点目录，并且每个 znode 可以存储数据，存储的数据需要小于1M。
3. znode 是有版本的，每个 znode 中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据
4. znode 可以是临时节点，一旦创建这个 znode 的客户端与服务器失去联系，这个 znode 也将自动删除，Zookeeper 的客户端和服务器通信采用长连接方式，每个客户端和服务器通过心跳来保持连接，这个连接状态称为 session，如果 znode 是临时节点，这个 session 失效，znode 也就删除了
5. znode 的目录名可以自动编号，如 App1 已经存在，再创建的话，将会自动命名为 App2
6. znode 可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是 Zookeeper 的核心特性，Zookeeper 的很多功能都是基于这个特性实现的。
7. 一个znode存在子节点，那么对这个znode删除操作会不成功，及每次删除只能删除叶子节点。

三、如何保证zookeeper集群每台机器上的数据的一致性

zookeeper的数据同步主要是通过leader机制来实现的。zookeeper的集群中会选举出来一个服务作为leader，leader的只要功能是对其他服务器上面的数据进行恢复和同步。

如果客户端发过来一个读请求，那么与这个请求连接的那台服务器可以对读请求进行处理，然后返回数据，应为有leader机制保证了数据的一致性，因此不比担心读到的数据回不正确。

如果客户端发过来一个写请求，那么与这个请求连接的那台服务器不会直接对写请求进行处理，而是先判断当前服务是否是leader，如果不是leader服务，该服务器会把这个写请求转发给leader服务，由leader服务先对这个请求进行处理，进行数据的写操作，完成后再跟其他的服务器进行数据同步，来保证数据的一致性。因此当客户端下载在发送读请求的时候，就算连的不是leader服务，读到的数据也是上个写请求修改过后的数据。

四、zookeeper的部署以及客户端代码的编写

1. 单机模式：单机安装非常简单，只要获取到 Zookeeper 的压缩包并解压到某个目录如：/home/zookeeper-3.2.2 下，Zookeeper 的启动脚本在 bin 目录下，Linux 下的启动脚本是 zkServer.sh。在你执行启动脚本之前，还有几个基本的配置项需要配置一下，Zookeeper 的配置文件在 conf 目录下，这个目录下有 zoo_sample.cfg 和 log4j.properties，你需要做的就是将 zoo_sample.cfg 改名为 zoo.cfg，因为 Zookeeper 在启动时会找这个文件作为默认配置文件。下面详细介绍一下，这个配置文件中各个配置项的意义。

tickTime=2000 
 dataDir=../devtools/zookeeper-3.2.2/build 
 clientPort=2181

• tickTime：这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个 tickTime 时间就会发送一个心跳

• dataDir：顾名思义就是 Zookeeper 保存数据的目录，默认情况下，Zookeeper 将写数据的日志文件也保存在这个目录里。
• clientPort：这个端口就是客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。

当这些配置项配置好后，你现在就可以启动 Zookeeper 了，启动后要检查 Zookeeper 是否已经在服务，可以通过 netstat – ano 命令查看是否有你配置的 clientPort 端口号在监听服务。

2. 集群模式：Zookeeper 的集群模式的安装和配置也不是很复杂，所要做的就是增加几个配置项。集群模式除了上面的三个配置项还要增加下面几个配置项：

initLimit=5 
 syncLimit=2 
 server.1=192.168.211.1:2888:3888 
 server.2=192.168.211.2:2888:3888

• initLimit：这个配置项是用来配置 Zookeeper 接受客户端（这里所说的客户端不是用户连接 Zookeeper 服务器的客户端，而是 Zookeeper 服务器集群中连接到 Leader 的 Follower 服务器）初始化连接时最长能忍受多少个心跳时间间隔数。当已经超过 10 个心跳的时间（也就是 tickTime）长度后 Zookeeper 服务器还没有收到客户端的返回信息，那么表明这个客户端连接失败。总的时间长度就是 5*2000=10 秒

• syncLimit：这个配置项标识 Leader 与 Follower 之间发送消息，请求和应答时间长度，最长不能超过多少个 tickTime 的时间长度，总的时间长度就是 2*2000=4 秒
• server.A=B：C：D：其中 A 是一个数字，表示这个是第几号服务器；B 是这个服务器的 ip 地址；C 表示的是这个服务器与集群中的 Leader 服务器交换信息的端口；D 表示的是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader，而这个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配置方式，由于 B 都是一样，所以不同的 Zookeeper 实例通信端口号不能一样，所以要给它们分配不同的端口号。

除了修改 zoo.cfg 配置文件，集群模式下还要配置一个文件 myid，这个文件在 dataDir 目录下，这个文件里面就有一个数据就是 A 的值，Zookeeper 启动时会读取这个文件，拿到里面的数据与 zoo.cfg 里面的配置信息比较从而判断到底是那个 server。

详细可参考：Zookeeper集群环境安装过程详解