ZooKeeper踩坑点
如果说要选出应用开发者在使用ZooKeeper的过程中，最需要了解清楚的事情？那么根据我们之前的支持经验，一定是异常处理。
当所有一切（宿主机，磁盘，网络等等）都很幸运的正常工作的时候，应用与ZooKeeper可能也会运行的很好，但不幸的是，我们整天会面对各种意外，而且这遵循墨菲定律，意料之外的坏事情总是在你最担心的时候发生。
所以务必仔细了解 ZooKeeper 在一些场景下会出现的异常和错误，确保您正确的理解了这些异常和错误，以及知道您的应用如何正确的处理这些情况。
- 异常处理
ConnectionLossException 和 Disconnected 事件
简单来说，这是个可以在同一个 ZooKeeper Session 恢复的异常(Recoverable), 但是应用开发者需要负责将应用恢复到正确的状态。发生这个异常的原因有很多，例如应用机器与ZooKeeper节点之间网络闪断，ZooKeeper节点宕机，服务端Full GC时间超长，甚至你的应用进程Hang死，应用进程 Full GC 时间超长之后恢复都有可能。要理解这个异常，需要了解分布式应用中的一个典型的问题，如下图：
在一个典型的客户端请求、服务端响应中，当它们之间的长连接闪断的时候，客户端感知到这个闪断事件的时候，会处在一个比较尴尬的境地，那就是无法确定该事件发生时附近的那个请求到底处在什么状态，Server端到底收到这个请求了么？已经处理了么？因为无法确定这一点，所以当客户端重新连接上Server之后，这个请求是否应该重试（Retry）就也要打一个问号。
所以在处理连接断开事件中，应用开发者必须清楚处于闪断附近的那个请求是什么（这常常难以判断），该请求是否是幂等的，对于业务请求在Server端服务处理上对于"仅处理一次" “最多处理一次” "最少处理一次"语义要有选择和预期。
举个例子，如果应用在收到 ConnectionLossException 时，之前的请求是Create操作，那么应用的catch到这个异常，应用一个可能的恢复逻辑就是，判断之前请求创建的节点的是否已经存在了，如果存在就不要再创建了，否则就创建。
再比如，如果应用使用了exists Watch 去监听一个不存在的节点的创建的事件，那么在ConnectionLossException的期间，有可能遇到的情况是，在这个闪断期间，其它的客户端进程可能已经创建了节点，并且又已经删除了，那么对于当前应用来说，就miss了一次关心的节点的创建事件，这种miss对应用的影响是什么？是可以忍受的还是不可接受？需要应用开发者自己根据业务语义去评估和处理。
2.
SessionExpiredException 和 SessionExpired 事件
Session 超时是一个不可恢复的异常，这是指应用Catch到这个异常的时候，应用不可能在同一个Session中恢复应用状态，必须要重新建立新Session，老Session关联的临时节点也可能已经失效，拥有的锁可能已经失效。
