官网上已经给出了zk的几种典型应用场景，原话是这么说的：

It exposes a simple set of primitives that distributed applications can build upon to implement higher level services for synchronization, configuration maintenance, and groups and naming. 

它提供了一组简单的原语，让分布式应用可以实现更高层次的服务，比如同步、配置维护、命名服务等等。除了官方提到的这些用途之外，它还可以实现分布式锁、分布式协调通知、集群选主等功能。这里把几个重要的功能列出来，一起学习一下。

分布式锁

当多个进程需要同时访问一个共享资源的时候，为保证一致性或者是减少资源使用压力，可以只允许获取锁的进程访问。锁分为共享锁和排它锁两类。

排它锁

同一个时间只允许一个进程访问共享资源，锁释放后，其他等待进程能够得到通知。

1.调用zk的create方法，创建一个临时节点/lock，多个进程只会有一个创建成功。创建成功的进程获取锁，执行后续逻辑。

2.未创建成功的进程对该锁创建监听，获取锁的进程宕机或者正常结束后，一旦锁释放，马上进入抢锁动作。

当然，有些场景只需要一个进程抢到锁就行，比如redis里某个缓存值失效了，只应该有一个进程去查询数据写入缓存，避免发生击穿，这个时候就需要排它锁。

共享锁

对一个共享资源做读写操作，读写必须按照获取锁的顺序进行，避免写覆盖和读取脏数据。通过zk的临时序列节点实现。

/
├── /host1-R-000000001
├── /host2-R-000000002
├── /host3-W-000000003
├── /host4-R-000000004
├── /host5-R-000000005
├── /host6-R-000000006
└── /host7-W-000000007

多个事务读写时，按照上面的方式创建共享锁，R表示读，W表示写。

读请求在比自己序号小的最后一个写节点上注册监听，锁释放后可以读。

写请求在比自己序号小的最后一个节点上注册监听，锁释放后可以写。

命名服务

把服务名称、地址等信息放在zk节点中，需要的时候去取。比如，微服务的注册中心可以用zk实现，但是zk是cp模型，可能会短暂地停止服务，注册中心使用euraka这样的ap模型更好。

配置中心

依然是基于watcher来实现。发布者把数据发布到 ZooKeeper 的一个或一系列的节点上，供订阅者进行数据订阅，达到动态获取数据的目的。

前面说过，zk存储数据是kb级的数量级。那么配置中心中存储的数据具备这么几个特征：每条配置信息数据量小、配置会动态更新、多个服务共享同一配置信息。

实现步骤如下：

1.使用set命令把配置信息写入持久化znode中

2.应用启动时，读取znode里的配置信息，并增加watcher

3.使用set命令更新配置时，应用回调函数读取新的配置信息并更新参数

集群选主

大数据里很多技术在实现高可用的时候，都是通过zk来实现节点主备的。

实现步骤如下：

1.多个节点在zk创建同一个临时znode，谁创建成功了，谁就是主节点（active）

2.没创建成功的是备节点（standby），在znode上注册watcher

3.主节点宕机时，临时znode消失，zk通过watcher事件通知备节点抢主

其他

除了上述最核心的用法外，zk还可以通过简单的代码实现很多功能，等待着聪明的你去发现。