Zookeeper解决了分布式锁的各种机制，通过它，我们可以将重心放在业务逻辑上，而非并发控制上。
Zookeeper提供了两个功能：
分布式锁；
服务注册与发现。
Zookeeper的数据模型
Zookeeper的数据存储是基于节点的，称作Znode。Znode的引用方式非常类似于文件路径，例如：当要访问猫时，需要指定路径/动物/猫。Znode包含四个元素：
- data：数据信息，例如服务的IP地址、端口、名字；
- ACL：访问权限，即那些人或者那些IP可以访问本节点；
- stat：元数据，例如事务ID、版本号、时间戳、大小等；
- child：子节点引用。
每个Znode节点最多只能存储1MB数据。
Zookeeper的基本操作
创建节点：create
删除节点：delete
判断节点是否存在：exists
获取一个节点的数据：getData
设置一个节点的数据：setData
获取节点下的所有子节点：getChildren
其中，exists、getData、getChildren属于读操作，Zookeeper客户端在请求读操作的时候，可以选择是否设置Watch。
Zookeeper的事件通知机制
可以将Watch理解成是注册在特定Znode上的触发器，当这个Znode发生改变时，也就是调用了create、delete、setData等方法时，将会触发Znode上注册的对应的事件，请求Watch的看客户端会接收到异步通知。
举个用户服务注册与发现的例子：
当用户服务1宕机时，用户服务2将会注册到API网关，继续提供服务。原理就是：当用户通过API网关访问用户服务时，实际上只是拿到了用户服务的IP地址和端口号。而API网关中通过调用getData(/user/reg, watch)方法，监听服务的状态。若出现服务宕机，则Zookeeper服务器将会通过异步通知的方式告知API网关，用户服务1已经宕机，同时提供可供使用的其他用户服务的IP地址和端口号并记录下来，以便于下次有用户请求到来时使用。