介绍

特性：

1.不适合存储大量数据；(zk的key是树形结构存储，不适合存储大量的key；而且zk保证的是每个节点的数据绝对一致性，也就是说zk的存储数据能力只是一台节点的能力，而不是所有节点的总和);2.不适合高并发写的场景，适合高并发读。 (写数据是基于半数以上的投piao机制，写性能比较差);3.可以实现相对轻量级的分布式锁，分布式队列等，但并不适合高并发的场景(原因参考1，2).  高并发场景需要使用redis和mq.

应用场景

集群搭建

很简单。看官网。

应用案例

实现自动更新配置

将jdbc的配置信息写入zk, 在app中实时监控zk节点，可以实现自动更新配置

实现集群监控

利用zk的临时节点来实现。集群节点启动时写入一条临时znode, 如果节点挂掉，临时节点自动被删除。 通过实时监控根znode的节点变更情况可以实现实时监控集群。

实现分布式锁

利用zk的临时节点来实现。一个线程访问节点，在该节点下create一个临时节点。相当于加了一把锁。 别的线程访问节点，如果发现下面有临时节点就知道节点被锁。 线程访问完毕删除临时节点。

分布式下的定时任务

分布式下每台机器的代码是一样的。定时任务只需要一台机器执行即可。实现的方案有很多。比如数据库加锁(前提是只有一台数据库)，获取判断ip等(也不够灵活。如果定时执行任务的机器挂了任务就没法执行了)。比较灵活的方式是使用zk的分布式锁。

分布式计数器

api使用

1. 原始的zk API 一定不要使用。因为写起来太繁琐！！！。。。。。。watcher(节点监控)只是一次性的。监控一次就失效需要重新启动监控； 节点的创建/删除不能递归，如果有多重节点，必须一层一层的递归创建/删除；最最坑的就是没有实现节点操作和节点监控的解耦。原生api在创建节点等操作的时候传入watcher去监控，代码又繁琐而且耦合度很高。2. zkClient 库也不要使用，因为比较老了。3. 最好使用Curator框架。目前已经是apache顶级项目。功能非常强大。