当我写完Zookeeper leader选举后，准备看看Zookeeper的存储和处理客户端请求的时候发现，如果能看看Zookeeper的API是不是在理解后面的过程更好些呢。
Zookeeper的client是通过Zookeeper类提供的。前面曾经说过，Zookeeper给使用者提供的是一个类似操作系统的文件结构，只不过这个结构是分布式的。可以理解为一个分布式的文件系统。我们可以通过Zookeeper来访问这个分布式的文件系统。
Zookeeper的client api给我们提供以下这些API：
1. create
在给定的path上创建节点，这个path就像文件系统的路径，比如/myapp/data/1，在创建节点的时候还可以指定节点的类型：是永久节点，永久顺序节点，临时节点，临时顺序节点。这个节点类型是非常强大的。永久节点一经创建就永久保留了，就像我们在文件系统上创建一个普通文件，这个文件的生命周期跟创建它的应用没有任何关系。而临时节点呢，当创建这个临时节点的应用与zookeeper之间的会话过期之后就会被zookeeper自动删除了。这个特性是实现很多功能的关键。比如我们做集群感知，我们的应用启动的时候将自己的ip地址作为临时节点创建在某个节点下面。当我们的应用因为某些原因，比如网络断掉或者宕机，它与zookeeper的会话就会过期了，过期后这个临时节点就删除了。这样我们就可以通过这个特性来感知到我们的服务的集群有哪些机器是活者的。那么顺序节点又是什么呢。一般，如果我们在指定的path上创建节点，如果这个节点已经被创建了，则会抛出一个NodeExistsException的异常。如果我们在指定的路径上创建顺序节点，则Zookeeper会自动的在我们给定的path上加上一个顺序编号。这个特性就是实现分布式锁的关键。假设我们有几个节点共享一个资源，我们这几个节点都想争用这个资源，那我们就都向某个路径创建临时顺序节点。然后顺序最小的那个就获得锁，然后如果某个节点释放了锁，那顺序第二小的那个就获得锁，以此类推，这样一个分布式的公平锁就实现了。
除此之外，每个节点上还可以保存一些数据。
2. delete 删除给定节点。删除节点的时候还可以给定一个version，只有路径和version都匹配的时候节点才会被删除。有了这个version在分布式环境种我们就可以用乐观锁的方式来确保一致性。比如我们先读取一下节点，获得了节点的version，然后删除，如果删除成功了则说明在这之间没有人操作过这个节点，否则就是并发冲突了。
3. exists 这个节点会返回一个Stat对象，如果给定的path不存在的话则返回null。这个方法有一个关键参数，可以提供一个Watcher对象。Wathcer是Zookeeper强大功能的源泉。Watcher就是一个事件处理器，一个回调。比如这个exists方法，调用后，如果别人对这个path上的节点进行操作，比如创建，删除或设置数据，这个Wather都会接收到对应的通知。
4. setData/getData 设置或获取节点的数据，getData也可以设置Watcher
5. getChildren 获取子节点，可以设置Watcher
6. sync zookeeper是一个集群，创建节点的时候只要半数以上的节点确认就认为是创建成功了，但是如果读取的时候正好读取到一个落后的节点上，那就有可能读取到旧的数据，这个时候可以执行一个sync操作，这个操作可以确保读取到最新的数据。
zookeeper的client api基本上介绍完了。zookeeper强大的功能都是通过这些API来实现的，zookeeper通过一个简单的文件系统数据模型对外提供服务。通过临时节点，Watcher等手段我们可以实现一些在分布式环境种很难做到的事情。