分布式协调服务主要是将多机协调的职责从分布式应用中独立出来，以减少系统的耦合性和增加扩展性。
zookeeper采用分布式中经典的主从架构：master->slave，通常以动态的存储分布式应用程序中关键的元数据。
作为分布式协调服务，zookeeper主要担任协调者的角色，可以提供如leader选举、负载均衡、服务发现等服务。
整体架构：
zookeeper采用层级化的内存命名空间，结构类似与文件系统的目录结构，其中每个目录节点称为ZNode，每个
ZNode具有data、type、version、children、ACL等属性。
其中data:实际的数据；type：znode类型、version:更新版本，children：子节点、ACL（Access Control List）：权限管理
的一个配置List，定义谁可以对该ZNode进行访问、修改、删除等操作。同时ZNode的数据访问具有原子性，即保证数据的读取、
操作并发时的原子性。
ZNode类型：
Persistent（持久化节点）、Ephemeral（临时节点，伴随session的生命周期）、sequence（唯一命名，文件名默认追加唯一的自增数字，该类型不会单独存在）
根据三种节点类型，衍生出ZNode四种类型：Persistent、Ephemeral、Persistent_sequence、Ephemeral_sequence
Watcher监听器：
发布/通知机制，当ZNode发生变化，client可收到通知，而watcher有一个重要的特征:triggered once即一旦触发，watcher就会被删除，
之后需要客户端重新注册watcher，一般客户端通过注册watcher监听znode的变化，以变快速作出响应。
Seesion:
客户端通过seesion与zookeeper之间建立通信通道，现实环境中zookeeper一般是以集群的模式搭建的，客户端只需要随机的
选择一个服务器建立session即可。
session具有时序性、容错性等特点，如时序性即当客户端发送消息，zookeeper会按照消息当时序进行记录。容错性方面，zookeeper以集
群当形式搭建，zookeeper可保证各个服务器的一致性。当客户端连接的服务器宕机，客户端可以自动连接到其他服务器上。
草稿待续。。。