zookeeper应用陷阱

并非任何分布式应用都适合使用ZooKeeper来构建协调服务，我们根据ZooKeeper提供的文档，给出哪些情况下使用会出现问题，又是如何应对这种问题的。总结如下：
 

丢失ZNode上的变更通知
客户端连接到ZooKeeper Server以后，会维护一个TCP连接。在CONNECTED状态下，客户端设置了某个ZNode的Watch监听器，可以收到来自该节点变更的通知（后续会触发一定的逻辑执行流程）。但是，如果由于网络异常，客户端断开了与ZooKeeper Server的连接，在断开的过程中，是无法收到ZooKeeper在ZNode上发送的节点数据变更通知的。
所以，如果使用ZooKeeper的Watch，必须要寻找保持CONNECTED的Watch，才能保证不会丢失该Watch监控的ZNode上的数据变更通知。
 
 
无效ZooKeeper集群节点列表
与ZooKeeper集群交互时，一般情况下客户端会持有一个ZooKeeper集群节点的列表，或者列表的子集，那么会存在如下两种情况：
一种情况是，如果客户端持有的列表或者列表子集，其中节点都处于Active状态，能够提供协调服务，那么客户端访问ZooKeeper集群没有任何问题。
另一种情况，客户端持有ZooKeeper集群节点列表或列表子集，如果列表中的某些节点因为故障退出了集群，如果客户端再次连接这一类失效的节点，就无法获取服务。
所以，我们在应用中使用ZooKeeper集群时，一定要明确这一点，或者跳过无效的节点，或者重新寻找有效的节点继续业务处理，或者检查ZooKeeper集群，使整个集群恢复正常。

 
配置导致的性能问题
如果设置Java堆内存（Heap）不合理，会导致ZooKeeper内存不足，会在内存与文件系统之间进行数据交换，导致ZooKeeper的性能极大地下降，从而可能会影响应用程序。
为了避免Swapping问题的出现，主要考虑设置足够的Java堆内存，同时减少被操作系统和Cache使用的内存，尽量避免在内存与文件系统之间发生数据交换，或者可以将交换限制在一定的范围之内。
 

事务日志存储设备性能
ZooKeeper会同步事务到存储设备，如果存储设备不是专用的，而是和其他I/O密集型应用共享同一磁盘，会导致ZooKeeper的效率。因为客户端请求ZNode数据变更而发生的事务，ZooKeeper会在响应之前将事务日志写入存储设备，如果存储设备是专用的，那么整个服务以至外部应用都会获得极大地性能提升。


ZNode存储大量数据导致性能问题
ZooKeeper的设计初衷是，每个ZNode只存放少量的同步数据，如果存储了大量数据，导致ZooKeeper每次节点发生变更时需要将事务写入存储设备，同时还要在集群内部复制传播，这将导致不可避免的延迟和性能问题。
所以，如果需要与大量的数据相关，可以将大量数据存储在其他设备中，而只是在ZooKeeper中存储一个简单的映射，如指针、引用等等。