zookeeper提供了类似Linux文件系统一样的数据结构。每一个节点对应一个Znode节点，每一个Znode节点都可以存储1MB（默认）的数据。
- Znode:包含ACL权限控制、修改/访问时间、最后一次操作的事务Id(zxid)等等
- 所有数据存储在内存中，在内存中维护这么一颗树。
- 每次对Znode节点修改都是保证顺序和原子性的操作。写操作是原子性操作。
举个例子，在注册中心中，可以通过路径"/fsof/服务名1/providers"找到"服务1"的所有提供者。
- 生命周期：当客户端会话结束的时候，是否清理掉这个会话创建的节点。持久-不清理，临时-清理。
- 类型：每一个会话，创建单独的节点（例子：正常节点：rudytan,顺序编号节点：rudytan001,rudytan002等等）
zookeeper除了提供对Znode节点的处理能力，还提供了对节点的变更进行监听通知的能力。
- 任何session(session1,session2)都可以对自己感兴趣的znode监听。
- 当znode通过session1对节点进行了修改。
- session1,session2都会收到znode的变更事件通知。
- session建立成功事件
- 节点添加
- 节点删除
- 节点变更
- 子节点列表变化
- 依赖于临时节点
- 消费者启动的时候，会先去注册中心中全量拉取服务的注册列表。
- 当某个服务节点有变化的时候，通过监听机制做数据更新。
- zookeeper挂了，不影响消费者的服务调用
通过上面的架构图，可以发现Eureka不同于zk中的节点，Eureka中的节点每一个节点对等。是个AP系统，而不是zk的CP系统。在注册中心的应用场景下，相对于与强数据一致性，更加关心可用性。
- 依赖于临时顺序节点
- 判断当前client的顺序号是否是最小的，如果是获取到锁。
- 没有获取到锁的节点监听最小节点的删除事件（比如lock_key_001）
- 锁释放，最小节点删除，剩余节点重新开始获取锁。
- 重复步骤二到四
- 从理解的难易程度角度（从低到高） 数据库 > 缓存（Redis） > Zookeeper
- 从实现的复杂性角度（从低到高） Zookeeper >= 缓存（Redis） > 数据库
- 从性能角度（从高到低） 缓存（Redis） > Zookeeper >= 数据库
- 从可靠性角度（从高到低） Zookeeper > 缓存（Redis） > 数据库
- 依赖于临时节点
- zookeeper保证无法重复创建一个已存在的数据节点，创建成功的client为master。
- 非master，在已经创建的节点上注册节点删除事件监听。
- 当master挂掉后，其他集群节点收到节点删除事件，进行重新选举
- 重复步骤二到四
使用ZooKeeper作为「dubbo的注册中心」，使用ZooKeeper实现「分布式锁」。
ZooKeeper，它是一个开放源码的「分布式协调服务」，它是一个集群的管理者，它将简单易用的接口提供给用户。
可以基于Zookeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列「等功能」。
Zookeeper的「用途」：命名服务、配置管理、集群管理、分布式锁、队列管理
Zookeeper就是使用临时顺序节点特性实现分布式锁的。
获取锁过程 （创建临时节点，检查序号最小）
释放锁 （删除临时节点，监听通知）
Zookeeper 保证了如下分布式一致性特性：
「顺序一致性」：从同一客户端发起的事务请求，最终将会严格地按照顺序被应用到 ZooKeeper 中去。
「原子性」：所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用。
「单一视图」：无论客户端连到哪一个 ZooKeeper 服务器上，其看到的服务端数据模型都是一致的。
「可靠性：」 一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会被一直保留下来。
「实时性：」 Zookeeper 仅仅能保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。
dubbo的注册中心可以选Zookeeper，memcached，redis等。为什么选择Zookeeper，因为它的功能特性咯~
命名服务，服务提供者向Zookeeper指定节点写入url，完成服务发布。
配置管理，实际项目开发中，我们经常使用.properties或者xml需要配置很多信息，如数据库连接信息、fps地址端口等等。因为你的程序一般是分布式部署在不同的机器上（如果你是单机应用当我没说），如果把程序的这些配置信息「保存在zk的znode节点」下，当你要修改配置，即znode会发生变化时，可以通过改变zk中某个目录节点的内容，利用「watcher通知给各个客户端」，从而更改配置。
负载均衡，注册中心的承载能力有限，而Zookeeper集群配合web应用很容易达到负载均衡。
zk支持监听事件，特别适合发布/订阅的场景，dubbo的生产者和消费者就类似这场景。
数据模型简单，数据存在内存，可谓高性能