Zookeeper系列（4）--ZK概述，数据模型，节点特性，Watcher机制、ACL及数据存储

在zookeeper系列的前三篇，介绍分布式数据一致性的相关原理及经典的分布式一致性算法，比如：2PC,3PC,Paxos算法。在本篇，我们正式开始介绍Zookeeper，Zookeeper是分布式一致性问题的工业解决方案，是常用的分布式协调框架。本篇，会介绍Zookeeper的基本概念，数据模型，节点特性，Watcher机制及ACL等机制，在后边我们会介绍Zookeeper为了保证一致性使用的算法ZAB，以及Zookeeper的应用场景。

Zookeeper基本概述

Zookeeper为分布式应用提供了高效且可靠的分布式协调服务，其实现依赖于ZAB协议，实现了一种主备模式的架构来保持数据的一致性（Zookeeper本身可保证分布式数据的一致性，从而可以提供高效可靠的协调服务）。

Zookeeper致力于提供一个高性能、高可用，且具有严格的顺序访问控制能力（主要是写操作的严格顺序性）的分布式协调服务。可用于大型的分布式系统中。 Zookeeper作为分布式协调服务提供了诸如统一命名服务，配置管理和分布式锁等分布式的基础服务。在解决分布式数据的一致性方面，Zookeeper并没有直接采用Paxos算法，而是采用了一种被称为ZAB(Zookeeper Atomic Broadcast)原子广播协议的一致性协议。ZK 是Google的Chubby（基于paxos算法的分布式锁服务）一个开源的实现。由于ZK自身的高可用性和可保持一致性，所以可以将其用于很多系统服务：分负载均衡，命名服务，分布式锁，集群管理，master选举等，都是zk提高的协调服务。

Zookeeper可以保证如下的分布式一致性要求：

顺序一致性
从同一个客户端发起的事务请求，最终将会严格按照其 发起顺序 被应用到ZooKeeper中。

原子性
所有事务请求的结果在集群中所有机器上的应用情况是一致的，也就是说要么整个集群所有集群都成功应用了某一个事务，要么都没有应用，一定不会出现集群中部分机器应用了该事务，而另外一部分没有应用的情况。

单一视图
无论客户端连接的是哪个ZooKeeper服务器，其看到的服务端数据模型都是一致的。

可靠性
一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会被一直保留下来，除非有另一个事务又对其进行了变更。

实时性
通常人们看到实时性的第一反应是，一旦一个事务被成功应用，那么客户端能够立即从服务端上读取到这个事务变更后的最新数据状态。这里需要注意的是，ZooKeeper仅仅保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。

注意：

在上边的特性中，顺序访问，对于来自客户端的每个请求，Zookeeper都会分配一个全局唯一的递增编号，编号反映了所有事务操作的先后顺序，并且在进行广播时，也是按照顺序执行的，因为TCP的连接，对于一个服务器向另一个服务器发送的信息，肯定是接收顺序肯定是和发送顺序一致的。？？

集群角色

在ZooKeeper中，有三种角色：

• Leader
• Follower
• Observer

一个ZooKeeper集群同一时刻只会有一个Leader，其他都是Follower或Observer。2181端口。

Zookeeper集群中的任何一台机器都可以响应客户端的读操作，且全量数据都存在于内存中，因此Zookeeper更适合以读操作为主的应用场景。注意，当不是leader的服务器收到客户端事务操作，他会将其转发到Leader，让Leader进行处理。

ZooKeeper集群的所有机器通过一个 Leader选举过程 来选定一台被称为 『Leader』 的机器， Leader服务器 为客户端提供 读 和 写 服务。Follower和Observer都能提供读服务，不能提供写服务。两者唯一的区别在于，Observer机器不参与Leader选举过程，也不参与写操作的『过半写成功』策略，因此Observer可以在不影响写性能的情况下提升集群的读性能。

Zookeeper集群的数量为奇数个（注意：这里并不是说偶数个就不行，而是：比如：5台和6台集群的容灾能力是一样的，所以我们可以少用一台达到相同的目的）。

基本架构：

1 每个Server在内存中存储了一份数据； 
2 Zookeeper启动时，将从实例中选举一个leader（Paxos协议）； 
3 Leader负责处理数据更新等操作（Zab协议）； 
4 一个更新操作成功，当且仅当大多数Server在内存中成功修改 

会话

Session是指客户端会话，在讲解客户端会话之前，我们先来了解下客户端连接。在ZooKeeper中，一个客户端连接是指客户端和ZooKeeper服务器之间的TCP长连接。ZooKeeper对外的服务端口默认是2181，客户端启动时，首先会与服务器建立一个TCP连接，从第一次连接建立开始，客户端会话的生命周期也开始了，通过这个连接，客户端能够通过心跳检测和服务器保持有效的会话，也能够向ZooKeeper服务器发送请求并接受响应，同时还能通过该连接接收来自服务器的Watch事件通知。Session的SessionTimeout值用来设置一个客户端会话的超时时间。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在SessionTimeout规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效。

Zookeeper数据模型

zookeeper采用层次化的目录结构，命名符合常规文件系统规范；  每个目录在zookeeper中叫做znode,并且其有一个唯一的路径标识；  Znode可以包含数据和子znode（ephemeral（临时）类型的节点不能有子znode）；  Znode中的数据可以有多个版本，比如某一个znode下存有多个数据版本，那么查询这个路径下的数据需带上版本；  客户端应用可以在znode上设置监视器（Watcher） 。

ZNode可以保存数据，同时还可以挂载子节点，因此构成了一个层次化的树形命名空间。Znode的节点路径标识方式和Unix文件系统路径非常相似，用一系列（\）进行分割。

节点特性

 ZooKeepe