Zookeeper的Session生命期(Lifetime)是从创建到结束的这段时间。Session的结束可能是被优雅地关闭，也可能是因超时而被关闭。在讲Session的行为之前，我们需要先考虑一下Session可能出现的状态，以及改变这些状态的事件。(这篇博客是Flavio Junqueria和Benjamin Reed的Zookeeper书的第二章中States and the Lifetime of a Session翻译)
Session的主要状态从名字上很容易理解其含义：CONNECTING, CONNECTED和NOT_CONNECTED。状态转移是由客户端和服务器之间发生的各种事件决定的。
图1：Session状态和转移
Session从NOT_CONNECTED状态开始，并随着Zookeeper客户端初始化，转移到CONNECTING状态（在图1中的箭头1）。 正常情况下，客户端会与Zookeeper服务器连接成功，并且转移到CONNECTED状态（箭头2）。当客户端失去了与ZooKeeper服务器的连接或者不能听到服务器，它会转移回CONNECTING（箭头3），并且尝试寻找另一个ZooKeeper服务器。如果它能找到另一个服务器或者重新连接到之前的服务器，并确认了这个Session仍然有效，它会转移回CONNECTED状态。否则，它会定义这个Session失效，并转移到CLOSED（箭头4）。应用可以显示关闭Session。（箭头4和5）
当网络断开时, 客户端在CONNECTING状态等待
如果客户端因为超时和服务器断开连接，它会保持在CONNECTING状态。如果这个断开是因为客户端和Zookeepe集群的网络中断，它将保持在CONNECTING状态直到它显示地关闭Session，或者网络中断恢复后客户端从Zookeeper服务器听到了Session超时消息。我们设计这样的行为是因为只有Zookeeper集群负责定义Session失效，而不是客户端。客户端不能定义Session失效，，直到听到Zookeeper Session超时消息。然而，客户端可以选择主动关闭这个Session。
在创建Session时，需要设置Session Timeout这个重要参数。这是Zookeeper服务允许一个Session在定义它失效之前的时间。如果服务在时间t内不能看到与一个Session关联的消息，它将定义这个Session失效。如果客户端在1/3 t时间内没有听到任何从服务器过来的消息，它将发送一个心跳消息给服务器。在(2/3)t时间， Zookeeper客户端开始寻找另一个Zookeeper服务器，并且它有另外的(1/3)t的时间寻找。
客户端将连接哪一个服务器
在Quorum模式，一个客户端拥有多个服务器可以连接。然而在Standalone模式，它必须尝试重新有效地连接到那个唯一的服务器。在Quorum模式，应该会传一个服务器列表到客户端，客户端从中选择一个连接。
当尝试连接另一个服务器时，很重要的一点是这个服务器的ZooKeeper状态至少要和客户端已经观察到的最近ZooKeeper状态是一样新的。客户端不能连接到一个这样的服务器。它没有看到客户端可能已经看到的更新。Zookeeper通过在服务中排序更新操作来决定新鲜程度(Freshness)。每一个对Zookeeper布局状态的改动操作相对于所有其它执行的更新操作都是全序的，所以如果一个客户端已经在位置i观察到一个更新，它不能连接一个仅看到i’ < i的服务器。在ZooKeeper的实现中，系统分配给每个更新操作一个事务ID来建立这个顺序。
图2解释了事务ID（zxids）在重连中的使用。客户端因为超时和s1断开连接后，它尝试连接s2，但是s2已经落后了，并不能反应客户端已知的更新。而s3已经看到和客户端一样看到的更新，所以它被安全连接。
图2：客户端重连的例子
转载请附上原博客地址：
却只能这样。只有对爱的人，我们才会斤斤计较，锱铢必较。
