ZooKeeper系统模型之会话重连。

        当客户端和服务端之间的网络连接断开时，ZooKeeper客户端会自动进行反复的重连，直到最终成功连接上ZooKeeper集群中的一台机器。在这种情况下，再次连接上服务端的客户端有可能会处于以下两种状态之一。

• CONNECTED：如果在会话超时时间内重新连接上了ZooKeeper集群中任意一台机器，那么被视为成功。
• EXPIRED：如果是在会话超时时间以外重新连接上，那么服务端其实已经对该会话进行了会话清理操作，因此再次连接上的会话将被视为非法会话。

        在ZooKeeper中，客户端与服务端之间维持的是一个长连接，在sessionTimeout时间内，服务端会不断地检测该客户端是否还处于正常连接——服务端会将客户端的每次操作视为一次有效地心跳检测来反复的进行会话激活。因此，在正常情况下，客户端会话是一直有效地。然而，当客户端与服务端之间的连接断开后，用户在客户端可能主要会看到两类异常：CONNECTION_LOSS（连接断开）和SESSION_EXPIRED（会话过期）。那么该如何正确处理CONNECTION_LOSS和SESSION_EXPIRED呢？

连接断开：CONNECTION_LOSS

        有时会因为网络闪断导致客户端与服务器断开连接，或是因为客户端当前连接的服务器出现问题导致连接断开，我们统称这类问题为“客户端与服务器连接断开”现象，即CONNECTION_LOSS。在这种情况下，ZooKeeper客户端会自动从地址列表中重新逐个选取新的地址并尝试进行重新连接，直到最终成功连接上服务器。

        举个例子，假设某应用在使用ZooKeeper客户端进行setData操作的时候，正好出现了CONNECTION_LOSS现象，那么客户端会立即接收到事件None-Disconnected通知，同时会抛出异常：org.apache.zookeeper.KeeperException$ConnectionLossException。在这种情况下，我们的应用需要做的事情就是捕获住Connection LossException，然后等待ZooKeeper的客户端自动完成重连。一旦客户端成功连接上一台ZooKeeper机器后，那么客户端就会收到事件None-SyncConnected通知，之后就可以重试刚刚出错的setData操作。

会话失效：SESSION_EXPIRED

        SESSION_EXPIRED是指会话过期，通常发生在CONNECTION_LOSS期间。客户端和服务器连接断开之后，由于重连期间耗时过长，超过了会话超时时间（sessionTimeout）限制后还没有成功连接上服务器，那么服务器认为这个会话已经结束了，就会开始进行会话清理。但是另一方面，该客户端本身不知道会话已经失效，并且其客户端状态还是DISCONNECTED。之后，如果客户端重新连接了服务器，那么很不幸，服务器会告诉客户端该会话已经失效（SESSION_EXPIRED）。在这种情况下，用户就需要实例化一个ZooKeeper对象，并且看应用的复杂情况，重新恢复临时数据。

会话转移：SESSION_MOVED

        会话转移是指客户端会话从一台服务器机器转移到了另一台服务器机器上。正如上文中提到，假设客户端和服务器S1之间的连接断开后，如果通过尝试重连后，成功连接上了新的服务器S2并且延续了有效会话，那么就可以说会话从S1转移到了S2上。

        会话转移现象其实在ZooKeeper中一直存在，但是在3.2.0版本之前，会话转移的概念并没有被明确地提出来。在3.2.0版本之后，ZooKeeper明确提出了会话转移的概念，同时封装了SessionMovedException异常。之后，在处理客户端请求的时候，会首先检查会话的所有者（Owner）：如果客户端请求的会话Owner不是当前服务器的话，那么就会直接抛出SessionMovedException异常。当然，由于客户端已经和这个服务器断开了连接，因此无法收到这个异常的响应。只有多个客户端使用相同的sessionId/sessionPasswd创建会话时，才会收到这样的异常。因为一旦有一个客户端会话创建成功，那么ZooKeeper服务器就会认为该sessionId对应的那个会话已经发生了转移，于是等到第二个客户端连接上服务器后，就被认为是“会话转移”的情况了。