ZooKeeper是一种分布式协调服务，主要用于分布式环境中协调和管理服务.可以让开发人员专注于核心应用程序逻辑，而不必担心应用程序的分布式特性。
ZooKeeper的应用场景:
① 分布式协调组件
在分布式系统中，需要有ZooKeeper作为分布式协调组件，来协调分布式系统中的状态。
② 分布式锁
ZooKeeper在实现分布式锁上面，可以做到强一致性。
③ 无状态化的实现
可以将一些具有无状态的信息存储到ZooKeeper中，分布式服务直接去ZooKeeper中
获取相关信息。
ZooKeeper中数据的存储结构
ZooKeeper中的数据是保存在节点(znode )上的，多个znode之间够成一棵树形的目录结构。
树是由节点所组成，ZooKeeper的数据存储也同样是基于节点，这种节点就做Znode；但是，不同于树的节点，Znode的引用方式是路径引用，类似于文件路径: /a/b；这种的层级结构，让每一个Znode节点拥有唯一的路径，就像命名空间一样，对不同信息做出清晰的隔离。Znode包含: data(数据), acl(权限), stat(元数据), child(子节点) .
Znode类型
持久节点 （create [节点] [存储的值（可选）]）
创建出的节点，在会话结束后依然存在。保存数据。
持久序号节点 （create -s [节点]）
兼具持久节点的特征。创建出的节点，根据先后顺序，会在节点之后带上一个数值，越后执行，这个数值越大。适合于分布式锁的应用场景（单调递增）。
临时节点 （create -e [节点]）
创建一个临时节点后，如果创建节点的会话结束，该节点会被自动的删除。通过这个特性，zk可以实现服务的注册与发现。临时节点通过心跳机制，告诉zk服务器自己还存活着。
临时序号节点 （create -es [节点] 或 create -e -s [节点]）
兼具临时节点+序号节点的特征总和。
容器节点 （create -c [节点]）
是在3.5.3版本新增的节点。当我们创建完容器节点后，如果该节点下没有任何子节点，那么60秒后，该容器节点就会被zk删除。
TTL节点 （create -t [毫秒数] [节点]）
可以指定节点的到期时间，到期后会被zk删除。需要通过系统配置extendedTypesEnabled=true开启。
数据持久化机制
ZooKeeper的数据是在内存中运行的 ，它提供了两种持久化机制：
① 事务日志
ZooKeeper把执行的命令以日志的形式保存在dataLogDir指定的路径中的文件里，如
果没有指定dataLogDir，则按照dataDir指定的路径。
② 数据快照
ZooKeeper会在一定的时间间隔内做一次内存数据的快照，把这段时间的内存数据保
存到快照文件中。
ZooKeeper通过上面的两种形式的持久化，在恢复时先恢复快照文件 中的数据到内存中，
再用日志文件中的数据做增量恢复，这样可以加快恢复速度。
ZooKeeper读写锁
读锁 （Read Lock）
并发的时候，多个线程都可以去执行读操作，彼此不会阻塞。加读锁成功的前提是：没有对其待访问的资源加写锁。
写锁 （Write Lock）
并发时如果多个线程都要去获得写锁，那么只有一条线程可以获得写锁，彼此会发生阻塞。
加写锁成功的前提是：没有对其待访问的资源加任和锁（无论是写锁or读锁）。
Watch机制
可以把Watch理解成是注册在指定Znode上的触发器。当被Watch的这个Znode发生了变化时，将会触发Znode上注册的对应监听事件，请求Watch的客户端会接收到异步回调通知。客户端使用了NIO通信模式监听服务的调用。
ZooKeeper的Leader选举
ZooKeeper作为非常重要的分布式协调组件，需要进行集群部署，集群中会以一主多从
的形式进行部署。为了保证数据的一致性，使用了ZAB（ZooKeeper Atomic Broadcase）
协议，这个协议解决了ZooKeeper的崩溃恢复和主从数据同步的问题。
ZAB协议定义了如下四种节点状态
Leader选举出来之后，会周期性不断的向Follower发送心跳 (ping命令，没有内容的socket)。当Leader崩溃后，Follower发现socket通道已经关闭，那么Follower就会从Following状态
进入到Looking状态，然后重新开始进行Leader的选举，在Leader选举的这个过程中，zk集群不能堆外提供服务。(CP原则)
数据同步
如果客户端连接了Leader节点，则直接将数据写入到主节点；如果客户端连接到了Follower节点,那么Follower节点会将数据转发给Leader节点，Leader节点再将数据写入到本节点中。
