Question

ZooKeeper 的客户端中，配置了一个 ensemble 服务器列表。当启动时，首先去尝试连接其中一个服务器。如果尝试连接失败，那么会继续尝试连接下一个服务器，直到连接成功或者全部尝试连接失败。

一旦连接成功，服务器就会为客户端创建一个会话（session）。session 的过期时间由创建会话的客户端应用来设定，如果在这个时间期间，服务器没有收到客户端的任何请求，那么 session 将被视为过期，并且这个 session 不能被重新创建，而创建的 ephemeral znode 将随着 session 过期被删除掉。在会话长期存在的情况下，session 的过期事件是比较少见的，但是应用程序如何处理好这个事件是很重要的。（我们将在《The Resilient ZooKeeper Application》中详细介绍）

在长时间的空闲情况下，客户端会不断的发送 ping 请求来保持 session。（ZooKeeper 的客户端开发工具的 liberay 实现了自动发送 ping 请求，所以我们不必去考虑如何维持 session）ping 请求的间隔被设置成足够短，以便能够及时发现服务器失败（由读操作的超时时长来设置），并且能够及时的在 session 过期前连接到其他服务器上。

容错连接到其他服务器上，是由 ZooKeeper 客户端自动完成的。重要的是在连接到其他服务器上后，之前的 session 以及 epemeral 节点还保持可用状态。

在容错的过程中，应用将收到与服务断开连接和连接的通知。Watch 模式的通知在断开链接时，是不会发送断开连接事件给客户端的，断开连接事件是在重新连接成功后发送给客户端的。如果在重新连接到其他节点时，应用尝试一个操作，这个操作是一定会失败的。对于这一点的处理，是一个 ZooKeeper 应用的重点。（我们将在《The Resilient ZooKeeper Application》中讲述）

时间 Time

在 ZooKeeper 中有一些时间的参数。 tick 是 ZooKeeper 的基础时间单位，用来定义 ensemble 中服务器上运行的程序的时间表。其他时间相关的配置都是以 tick 为单位的，或者以 tick 的值为最大值或者最小值。例如，session 的过期时间在 2 ticks 到 20 ticks 之间，那么你再设置时选择的 session 过期时间必须在 2 和 20 之间的一个数。

通常情况 1 tick 等于 2 秒。那么就是说 session 的过期时间的设置范围在 4 秒到 40 秒之间。在 session 过期时间的设置上有一些考虑。过期时间太短会造成加快物理失败的监测频率。在组成员关系的例子中，session 的过期时间与从组中移除失败的成员花费的时间相等。如果设置过低的 session 过期时间，那么网络延迟就有可能造成非预期的 session 过期。这种情况下，就会出现在短时间内一台机器不断的离开组，然后又从新加入组中。

如果应用需要创建比较复杂的临时状态，那么就需要较长的 session 过期时间，因为重构花费的时间比较长。有一些情况下，需要在 session 的生命周期内重启，而且要保证重启完后 session 不过期（例如，应用维护和升级的情况）。服务器会给每一个 session 一个 ID 和密码，如果在连接创建时，ZooKeeper 验证通过，那么 session 将被恢复使用（只要 session 没过期就行）。所以应用程序可以实现一个优雅的关机动作，在重启之前，将 session 的 ID 和密码存储在一个稳定的地方。重启之后，通过 ID 和密码恢复 session。

这仅仅是在一些特殊的情况下，我们需要使用这个特性来使用比较长的 session 过期时间。大多数情况下，我们还是要考虑当出现非预期的异常失败时，如何处理 session 过期，或者仅需要优雅的关闭应用，在 session 过期前不用重启应用。

通常情况也越大规模的 ensemble，就需要越长的 session 过期时间。Connetction Timeout、Read Timeout 和 Ping Periods 都由一个以服务器数量为参数的函数计算得到，当 ensemble 的规模扩大，这些值需要逐渐减小。如果为了解决经常失去连接而需要增加 timeout 的时长，建议你先监控一下 ZooKeeper 的 metrics，再去调整。

状态 States

ZooKeeper 对象在他的生命周期内会有不同的状态，我们通过 getState() 来获得当前的状态。

public States getState()

状态是一个枚举类型的数据。新构建的 ZooKeeper 对象在尝试连接 ZooKeeper 服务时的状态是 CONNECTING ，一旦与服务建立了连接那么状态就变成了 CONNECTED 。

客户端可以通过注册一个观察者对象来接收 ZooKeeper 对象状态的迁移。当通过 CONNECTED 状态后，观察者将接收到一个 WatchedEvent 事件，他的属性 KeeperState 的值是 SyncConnected 。

注意
观察者有两个职能：一是接收 ZooKeeper 的状态改变通知；二是接收 znode 的改变通知。ZooKeeper 对象构造时传递进去的 watcher 对象，默认是用来接收状态改变通知的，但是 znode 的改变通知也可能会共享使用默认的 watcher 对象，或者使用一个专用的 watcher。我们可以通过一个 Boolean 变量来指定是否使用共享默认 watcher。

ZooKeeper 实例会与服务连接断开或者重新连接，状态会在 CONNECTING 和 CONNECTED 之间转换。如果连接断开，watcher 会收到一个断开连接事件。请注意，这两个状态都是 ZooKeeper 实例自己初始化的，并且在断开连接后会自动进行重连接。

如果调用了 close() 或者 session 过期，ZooKeeper 实例会转换为第三个状态 CLOSED ，此时在接受事件的 KeeperState 属性值为 Expired 。一旦 ZooKeeper 的状态变为 CLOSED ，说明实例已经不可用（可以通过 isAlive() 来判断），并且不能再被使用。如果要重新建立连接，就需要重新构建一个 ZooKeeper 实例。