分布式架构有以下几点普适性的共性需求：
-
提供集群的集中化的配置管理功能，可以不重启就让新的配置参数生效，类似与配置中心
-
简单可靠的集群节点动态发现机制，便于动态发现服务，动态扩展节点
-
简单可靠的leader选举机制
-
提供分布式锁
zookeeper的数据结构整体上可以看作一颗目录树，其中每个节点被称作ZNode，每个Znode都可以通过其路径（Path）唯一标识，如/services/helloworld。每个ZNode都可以绑定一个二进制存储数据（Data），用来存储少量数据，默认最大1MB。不建议在ZNode中存储大量的数据，因为数据多份复制，会带来宽带压力，降低性能。
ZNode有一个ACL访问权限列表，用来决定当前操作API 的用户是否有操作此节点的权限。ZNode还提供了实时通知的接口--Watch，应用可以选择任意ZNode进行监听，如果被监听的ZNode或者其Child发生变化，则应用可以实时收到通知，这样一来，很多场景和需求都能通过ZooKeeper来实现了。
此外，ZNode是有生命周期的，这取决于节点的类型，节点的类型分为以下几类：
-
持久节点： 节点创建后就一直存在，直到有删除操作来主动删除该节点
-
临时节点： 临时节点的生命周期和创建该节点的客户端会话绑定，即如果客户端会话失效（客户端宕机或下线），这个节点自动删除
-
时序节点： 创建节点是可以设置这个属性，ZooKeeper会自动为给定的节点加上一个数字后缀，作为新的节点名。数字后缀的范围是整型的最大值
-
临时性时序节点： 同时具备临时节点与时序节点的特性，主要用于分布式锁的实现
从上面的分析来看，持久节点主要用于保存持久化数据，如集群的配置信息，结合Watch特性，实现配置的实时生效。
临时节点可以实现复杂的动态服务发现和服务路由功能。通常的做法是，分布式集群不同服务器上的服务注册到同一个ZooKeeper上，并在某个指定的路径下创建各自对应的临时节点，如/serviceA/node1, /serviceA/node2，客户端则监听/service目录。当有新的节点加入集群时，ZooKeeper会把变化实时通知到所有客户端，客户端就可以及时更新自己的服务路由转发表，实现全自动透明的服务发现和服务路由功能。
时序类型的节点，在创建时，每个节点名都会被追加一个递增的序号，类似于数据库自增主键，每个ZNode都有唯一序号，而且不会冲突。以此可以实现简单的Master（Leader）选举机制。即把一组service实例都注册为临时性时序节点ZNode，每次选取Master时，选取序号最小的为Master，而当Master宕机时，相应的ZNode会消失，新的服务器列表会推送至客户端，继续选举下一任Master，这样就做到了动态选举Master。
ZooKeeper主要用于以下场景：
-
实现配置管理（配置中心）
-
服务注册中心
-
集群通信与控制子系统
作为服务注册中心时：
首先服务提供者将自身的服务信息注册到注册中心。通常注册信息包含如下内容：
-
服务的类型
-
隶属于哪个系统
-
服务的IP/端口
-
服务的请求URL
-
服务的权重
其次注册中心要将所有服务信息存储，同时负责将注册信息的更新推送到所有的消费者（通过Watch机制实现）。
最后，服务消费者只有在初始化及服务变更时会依赖注册中心，而在整个服务调用过程中与服务提供方直接通信，不依赖于任何第三方，包括注册中心。
**欢迎关注我的微信公众号：程序员顺仔
