1、数据结构
首先对zookeeper下一个定义：zookeeper是一种分布式协调中间件。Zookeeper的命名空间和文件系统类似，两者的主要区别在于，文件系统只有最后的叶子节点才会存储数据，而zookeeper树中的每一个节点都能存储数据。Zookeeper树中的节点被称为Znode，需要注意的是Znode中的数据是存储在内存中的，因而节点中存储数据的大小是有限的（不超过1M），往往只用于存储一些配置信息或是状态信息。和文件系统类似，zookeeper创建节点也必须按照层级创建，以“/”为根节点，每个节点可由唯一的路径表出，同时每一层级下节点的名称必须是唯一的。其结构如图1-1所示。
图1-1 zookeeper namespace 结构
1.1 Znode类型
持久化节点
该类型节点的数据会持久化到磁盘。
临时节点
该类型节点生命周期和创建节点的客户端的生命周期保持一致，当客户端下线时，会自动删除创建的节点。
有序节点
该类型节点在创建时会在节点后增加一个递增的序列，该序列在同级父目录下是唯一的。持久化节点和临时节点也可设置为有序节点。
容器节点
该类型节点下的最后一个子节点被删除时，容器节点本身也会自动删除。
TTL节点
针对持久化节点或持久化有序节点，可设置一个存活时间，如果在存活时间内该节点没有任何修改也没有任何子节点，则达到存活时间后会被自动删除。
2、zookeeper用途
2.1 分布式锁
在分布式的情况下存在多个服务节点访问共享资源的情况，为了防止在这种多进程并发访问时出现的脏读和丢失修改问题，就需要引入分布式锁。分布式锁的关键在于确保同一时刻只有一个进程能够访问到共享资源，即排他性。Zookeeper的临时节点和同级目录下节点的唯一性能够满足分布式锁的要求。
1）加锁
在需要加锁时，所有客户端可以在zookeeper server 的/exclusive_locks节点下创建一个/resource1_lock 临时节点，zookeeper同级目录下节点的唯一性可确保在同一时间只有一个客户端能够创建成功。创建成功即获得了排他锁。没有创建成功的客户端则继续监听/resource1_lock的状态，当/resource1_lock节点被删除时再次进行创建操作。（这里的节点名不是特指，只是举个例子，实际节点名自己决定，但需确保对一个共享资源创建的节点名称必须一样。）
2）解锁
解锁操作分两种情况，一种是当获得锁的客户端完成操作后主动删除/resource1_lock节点，二是当客户端因异常与服务器断开连接时，zookeeper会因为临时节点的特性自动删除/resource1_lock节点。
2.2 服务注册与发现
在微服务架构中，不同的服务有不同的服务提供者，且出于高可用，服务提供者集群部署，这就要求服务调用者能够动态的感知服务提供者的所有节点的地址信息和节点的变动。服务调用者在获取所有的服务地址后再根据某种负载均衡的算法去决定调用哪个地址的服务。如果直接将服务提供者的URL地址维护在服务调用方显然不大现实，因为如果这样的话每次服务地址变化时都需要去更改服务调用方的配置。因此往往由第三方软件来管理服务提供者的地址信息并推送给调用方，这个第三方软件即注册中心。现在使用比较广泛的RPC框架Apache Dubbo，便是使用zookeeper作为官方的注册中心（也有用nacos或者euraka的）。
Dubbo 会先在zookeeper中创建一个持久化节点/dubbo，所有的dubbo服务以此为根节点。Dubbo服务注册的结构如图2-1所示：
图2-1 zookeeper dubbo服务树节点
Dubbo服务注册时会现在/dubbo根节点下创建对应服务的持久化节点，当服务运行时会在/providers 下创建服务地址的临时节点。当服务停止运行时，则对应的临时节点删除。消费者通过监听对应服务下的/providers节点来获取服务地址信息以及感知地址变化。
可以发现其他如配置管理其实也相当于一种服务的注册与发现。
2.3 master选举
利用zookeeper临时节点和同一目录下只能不能有同名节点的特征，可以很方便的实现集群节点中master节点选举的功能。可以所有节点都在zookeeper服务器上的某一目录下创建一个/master_election节点，谁先创建成功谁就是master节点,其他节点监听创建的/master_election节点。当master节点下线时，/master_election被删除，其他节点重新触发选举操作。
