（一）特性

（1）临时节点

临时节点，节点的生命周期和创建该节点的客户端的生命周期保持一致，一旦该客户端的会话结束，则该客户端所创建的临时节点会被自动删除。
备注：因为这个特性所以很多的时候可以利用这个作为机器上下线的设计，客户端上线则创建了一个节点，断开连接则此时临时节点被自动删除

（2）容器节点

容器节点，当容器节点下的最后一个子节点被删除时，容器节点就会被自动删除。

（3）TTL节点

TTL节点，针对持久化节点或者持久化有序节点，我们可以设置一个存活时间，如果在存活时间之内该节点没有任何修改并且没有任何子节点，它就会被自动删除。

（4）持久化节点

持久化节点，节点的数据会持久化到磁盘

（5）有序节点

有序节点，在创建的节点后面会增加一个递增的序列，该序列在同一级父节点之下是唯一的。需要注意的是，持久化节点或者临时节点也是可以设置为有序节点的，也就是持久化有序节点或者临时有序节点。

（二）Watcher机制

ZooKeeper提供了一种针对Znode的订阅/通知机制，也就是当Znode节点状态发生变化时或者ZooKeeper客户端连接状态发生变化时，会触发事件通知。这个机制在服务注册与发现中，针对服务调用者及时感知到服务提供者的变化提供了非常好的解决方案。

在ZooKeeper提供的Java API中，提供了三种机制来针对Znode进行注册监听，分别是:
getData ()，用于获取指定节点的value信息，并且可以注册监听，当监听的节点进行创建、修改、删除操作时，会触发相应的事件通知。

getChildren(），用于获取指定节点的所有子节点，并且允许注册监听，当监听节点的子节点进行创建、修改、删除操作时,触发相应的事件通知。

exists ( )，用于判断指定节点是否存在，同样可以注册针对指定节点的监听，监听的时间类型和getData(）相同。

Watcher事件的触发都是一次性的，比如客户端通过getData ( ‘/node’, true )注册监听，如果/node节点发生数据修改，那么该客户端会收到一个修改事件通知，但是/node再次发生变化时，客户端无法收到Watcher事件，为了解决这个问题，客户端必须在收到的事件回调中再次注册事件。

（三）常见应用场景分析

（1）分布式锁

用过多线程的读者应该都知道锁，比如Synchronized或者Lock,它们主要用于解决多线程环境下共享资源访问的数据安全性问题，但是它们所处理的范围是线程级别的。在分布式架构中，多个进程对同一个共享资源的访问，也存在数据安全性问题，因此也需要使用锁的形式来解决这类问题，而解决分布式环境下多进程对于共享资源访问带来的安全性问题的方案就是使用分布式锁。锁的本质是排他性的，也就是避免在同一时刻多个进程同时访问某一个共享资源。
如果使用ZooKeeper实现分布式锁达到排他的目的，只需要用到节点的特性:临时节点，以及同级节点的唯一性。
【获得锁的过程】
在获得排他锁时，所有客户端可以去ZooKeeper服务器上/Exclusive_Locks节点下创建一个临时节点/lock。ZooKeeper基于同级节点的唯一性，会保证所有客户端中只有一个客户端能创建成功，创建成功的客户端获得了排他锁，没有获得锁的客户端就需要通过Watcher机制监听/Exclusive_Locks节点下子节点的变更事件，用于实时监听/lock节点的变化情况以做出反应。
【释放锁的过程】
在获得锁的过程中，我们定义的锁节点/lock为临时节点，那么在以下两种情况下会触发锁的释放。
获得锁的客户端因为异常断开了和服务端的连接，基于临时节点的特性，/lock节点会被自动删除。
获得锁的客户端执行完业务逻辑之后，主动删除了创建的/lock节点。
当/lock节点被删除之后，ZooKeeper服务器会通知所有监听了/Exclusive_Locks子节点变化的客户端。这些客户端收到通知后，再次发起创建/lock节点的操作来获得排他锁。

（2）Master选举

Master选举是分布式系统中非常常见的场景，在分布式架构中，为了保证服务的可用性，通常会采用集群模式，也就是当其中一个机器宕机后，集群中的其他节点会接替故障节点继续工作。这种工作模式有点类似于公司中某些重要岗位的A/B角，当A请假之后，B可以接替A继续工作。在这种场景中，就需要从集群中选举一个节点作为Master节点，剩余的节点都作为备份节点随时待命。当原有的Master节点出现故障之后，还需要从集群中的其他备份节点中选举一个节点作为Master节点继续提供服务。

ZooKeeper就可以帮助集群中的节点实现Master选举。具体而言，ZooKeeper中有两种方式来实现Master选举这一场景:

参考特性：利用临时有序节点的特性来实现，同一级节点不能重复创建一个已经存在的节点

【方式一】

同一级节点不能重复创建一个已经存在的节点，这个有点类似于分布式锁的实现场景，其实Master选举的场景也是如此。假设集群中有3个节点，需要选举出Master，那么这三个节点同时去ZooKeeper服务器上创建一个临时节点/master-election,由于节点的特性，只会有一个客户端创建成功，创建成功的客户端所在的机器就成了Master。同时，其他没有创建成功的客户端，针对该节点注册Watcher事件，用于监控当前的Master机器是否存活，一旦发现Master“挂了”，也就是/master-election节点被删除了，那么其他的客户端将会重新发起Master选举操作。

【方式二】

利用临时有序节点的特性来实现。所有参与选举的客户端在ZooKeeper服务器的/master节点下创建一个临时有序节点，编号最小的节点表示Master，后续的节点可以监听前一个节点的删除事件，用于触发重新选举，如图所示，client01、client02、client03三个节点去ZooKeeper Server的/master节点下创建临时有序节点，编号最小的节点client01表示Master节点，client02和client03会分别通过Watcher机制监听比自己编号小的一个节点，比如client03会监听client01-o000000001节点的删除事件、client02会监听client-03-0000000002节点的删除事件，一旦最小的节点被删除，那么在图这个场景中，client-03就会被选举为Master。