我们通过前面介绍安装了单机和器群模式，也就是独立模式和仲裁模式。下面我们启动单机模式，开始第一个会话。
上面的服务器命令使得zookeeper服务器在后台中运行。如果想要在前台运行以便查看服务器的输出，可以使用命令
bin/zkServer.sh start-foregroud
这个选项提供了大量的详细信息的输出，以便允许查看服务器发生了什么：
下面从新启动一个shell，然后用客户端连接
bin/zkCli.sh
上图中标识了1到5五个日志输出，分别是：
1 客户端起送程序来建议一个会话
2 客户端尝试连接到localhsot/127.0.0.1:2181
3 客户端连接成功，服务器开始初始化这个新会话
4 会话初始化成功完成
5 服务器向客户端发送了一个SyncConnectd事件
来看一下这些输出，有很多行告诉我们各种各样的环境变量的配置以及客户端使用了什么jar包。可以花时间分析所有的日志信息，下面忽略这些，关注会话的建立。
在输出结尾，我看到会话建立的日志消息。第一处提到Initiating client connection。消息本身说明到底发生了什么，而额外的重要细节说明了客户端尝试连接到客户端发送的连接串localhost/127.0.0.1:2181中的一个服务器。这个例子中，字符串只包含了localhost，因此指明了具体连接地址。之后我们看到关于SASL的消息，我们暂时忽略这个消息，随后一个确认消息说明客户端与本地的zookeeper服务器建立了TCP连接。后面的日志信息确认了会话的建立，并告诉我们会话ID为sessionid = 0x1686069756a0000。最后客户端通过SyncConncted事件通知了应用。应用需要实现watcher对象来处理这个事件，后面将详细说明。
为了更加了解zookeeper，我们列出根（root）下的所有znode，然后创建一个znode。首先我们要确认此刻znode树为空，除了节点/zookeeper之外。该节点内标记了zookeeper服务所需要的元数据树。
我们执行了 ls / 后，看到这里只有/zookeeper节点，现在创建一个名为/workers的znode，如下：
注意，当创建/workers节点后指定一个空字符串，说明我们此刻不希望在这个znode中保存数据。当然也可以保存任何数据到zookeeper的节点中，比如空字符串换为workers。
下面删除节点，然后退出：
观察到节点/workers已经被删除，并且会话现在也关闭。为了完成最后的清理，退出了zookeeper服务器
仲裁模式会话
以上同样的操作可以在仲裁模式实验，可以自行观察日志，可以自行关闭一台，然后查看内容。仲裁模式连接可以达到可靠性。
在仲裁模式中，客户端以随机顺序连接到连接串中的服务器，这样可以用zookeeper来实现一个简单的负载均衡，不过客户端无法指定优先选择的服务器来进行连接。例如有五个服务器，三个在国外，两个在国内，为了确保本地连接，我们可以指定连接串中只包含向连接的服务器。
会话状态和生命周期
会话的生命周期（lifetime）是指会话从创建到结束的时间，无论会话正常关闭还是因超时而导致过期。为了讨论会话中发生了什么，我们需要考虑会话可能的状态，以及可能导致会话状态改变的事件。
一个会话的主要可能状态大多是简单明了的：CONNECTING、CONNECTED、CLOSED和NOT_CONNECTED。状态的转换依赖于发生在客户端与服务端的各种事件。如下图：
一个会话从NOT_CONNECTED开始，当zookeeper客户端初始化后转换到CONNECTING状态（箭头1）。正常情况下，成功与zookeeper服务器建立连接后，会话转换到CONNECTED状态（箭头2）。当客户端与zookeeper服务器断开连接或者无法收到服务器的响应时，它就会转换回CONNECTING状态（箭头3）并尝试发现其它zookeeper服务器。如果可以发现另一个服务器或者重连原来的服务器成功，服务器确认会话有效后，状态又会转换回CONNECTED状态。否则，它将声明过期，然后转换到CLOSED状态（箭头4）。应用也可以显示的关闭会话（箭头4和箭头5）。
注意：发⽣⽹络分区时等待CONNECTING，如果⼀个客户端与服务器因超时⽽断开连接，客户端仍然保持CONNECTING状态。如果因⽹络分区问题导致客户端与ZooKeeper集合被隔离⽽发⽣连接断开，那么其状态将会⼀直保持，直到显式地关闭这个会话，或者分区问题修复后，客户端能够获悉ZooKeeper服务器发送的会话已经过期。发⽣这种⾏为是因为ZooKeeper集合对声明会话超时负责，⽽不是客户端负责。直到客户端获悉ZooKeeper会话过期，否则客户端不能声明自⼰的会话过期。然⽽，客户端可以选择关闭会话。
创建⼀个会话时，你需要设置会话超时这个重要的参数，这个参数设置了ZooKeeper服务允许会话被声明为超时之前存在的时间。如果经过时间 t 之后服务接收不到这个会话的任何消息，服务就会声明会话过期。⽽在客户端侧，如果经过t/3的时间未收到任何消息，客户端将向服务器发送⼼跳消息。在经过2t/3时间后，ZooKeeper客户端开始寻找其他的服务器，⽽此时它还有t/3时间去寻找。
注意：客户端会尝试连接哪⼀个服务器？在仲裁模式下，客户端有多个服务器可以连接，⽽在独立模式下，客户端只能尝试重新连接单个服务器。在仲裁模式中，应用需要传递可用的服务器列表给客户端，告知客户端可以连接的服务器信息并选择⼀个进⾏连接。
当尝试连接到⼀个不同的服务器时，⾮常重要的是，这个服务器的ZooKeeper状态要与最后连接的服务器的ZooKeeper状态保持最新。客户端不能连接到这样的服务器：它未发现更新⽽客户端却已经发现的更新。ZooKeeper通过在服务中排序更新操作来决定状态是否最新。ZooKeeper确保每⼀个变化相对于所有其他已执⾏的更新是完全有序的。因此，如果⼀个客户端在位置 i 观察到⼀个更新，它就不能连接到只观察到 i'<i 的服务器上。在ZooKeeper实现中，系统根据每⼀个更新建⽴的顺序来分配给事务标识符。
如下图描述了在重连情况下事务标识符（zkid）的使⽤。当客户端因超时与s1断开连接后，客户端开始尝试连接s2，但s2延迟于客户端所知的变化。然⽽，s3对这个变化的情况与客户端保持⼀致，所以s3可以安全连接。
