The ZooKeeper server runs in two modes: standalone and quorum. Standalone mode is pretty much what its term describes: there is a single server, and ZooKeeper state cannot be replicated. In quorum mode, there is a set of ZooKeeper servers , which we call a ZooKeeper ensemble, which can replicate state before and serve client requests at the same time. From this perspective, we use the term "ZooKeeper ensemble" to refer to a multiple server facility, which can consist of a single server in standalone mode or multiple servers in quorum mode.
1.1.1 ZooKeeper Quorum
In quorum mode, ZooKeeper replicates the data tree of all servers in the cluster. But if you had a client wait for each server to finish saving the data before continuing, the latency problem would be unacceptable . In public administration, a quorum is the minimum number . In ZooKeeper, it refers to the minimum number of servers . This number is also the minimum number of servers that need to save . For example, we have a total of 5 ZooKeeper servers , but the quorum is 3, so that as long as any 3 servers have data saved, the client can continue, and the other 2 servers will eventually capture the data, and save data.
To understand what this actually means, let's first go through an example to see how things can go wrong if the quorum is too small. Suppose there are 5 servers and set a quorum of 2, now that servers s 1 and s 2 confirm that they need to replicate the znode/z created by a request, the service returns to the client that the znode creation is complete. Now suppose that servers s 1 and s 2 are partitioned from other servers and clients for a long time before , the state of the whole service is still normal, because based on our assumption the quorum is set as 2, and now there are 3 servers, but these 3 servers will not be able to discover the new znode/z. Therefore, the request to create node/z is non-persistent.
By using the majority scheme, we can tolerate the crash of f servers, where f is less than half the number of servers in the set. For example, if there are 5 servers, a maximum of f=2 crashes can be tolerated. In a set, the number of servers does not have to be odd, but using an even number makes the system more fragile. Assuming 4 servers are used in the set, the majority rule corresponds to 3 servers. However, this system can only tolerate 1 server crash, because two server crashes would cause the system to lose its majority state. So with 4 servers, we can only tolerate one server crash, and the quorum is now larger, which means we need more confirmation operations per request. Bottom line is we need to fight for an odd number of servers
1.1.2 Session
Before performing any request to the ZooKeeper ensemble, a client must first establish a session . The concept of sessions is very important and critical to the operation of ZooKeeper. All operations submitted by a client to ZooKeeper are associated with a session. When a session is terminated for some reason , the ephemeral nodes created during that session will disappear.
When a client creates a ZooKeeper handle with a specific language suite, it establishes a session through the service. The client initially connects to one of the servers in the collection or to an individual server. The client connects and communicates with the server through the TCP protocol, but when the session cannot continue to communicate with the currently connected server, the session may be transferred to another server . The ZooKeeper client library transparently transfers a session to a different server
1.1.3 Getting started with ZooKeeper
Before getting started, you need to download the ZooKeeper distribution. ZooKeeper is hosted at http://zookeeper.apache.org. Through the download link, you will download a compressed TAR file with a name similar to zookeepe-3.4.5.tar.gz. On Linux, Mac OS X, or any other UNIX-like system, the distribution can be unpacked with the following command:
tar -xvzf zookeeper-3.4.5.tar.gz
1.1.4 The first ZooKeeper session
First we run ZooKeeper in standalone mode and create a session. To do this, use the zkServer and zkCli tools in bin/ of the ZooKeeper distribution. Experienced administrators often use these two tools for debugging and management, and are also very suitable for beginners to familiarize themselves with and understand ZooKeeper
假设你已经下载并解压了ZooKeeper发行包，进入shell，变更目录cd）到项目根目录下，重命名配置文件：
mv conf/zoo_sample.cfg conf/zoo.cfg
最好把data目录移出/tmp目录，防止zookeeper填满了根分区。可以在zoo.cfg文件中修改这个目录的位置
dataDir=/user/me/zookeeper
启动服务器
bin/zkServer.sh start
这个服务器命令使得ZooKeeper服务器在后台中运行。如果在前台中运行以便查看服务器的输出，可以通过以下命令运行
bin/zkServer.sh start-foreground
这个选项提供了大量详细信息的输出，以便允许查看服务器发生了什么
启动客户端
在另一个shell中进入项目根目录，运行一下命令：
bin/zkCli.sh
为了更加了解ZooKeeper，让我们列出根（root）下的所有znode，然后创建一个znode。首先我们要确认此刻znode树为空，除了节点/zookeeper之
外，该节点内标记了ZooKeeper服务所需的元数据树。
ls /
创建节点
create /workers ""
当创建/workers节点后，我们指定了一个空字符串（""），说明我们此刻不希望在这个znode中保存数据。然而，该接口中的这个参数可以使我们保存任何字符串到ZooKeeper的节点中。比如，可以替换""为"workers"。
[zk: localhost:2181(CONNECTED) 3] delete /workers
[zk: localhost:2181(CONNECTED) 4] ls /
[zookeeper]
[zk: localhost:2181(CONNECTED) 5] quit
Quitting...
2012-12-06 12:28:18,200 [myid:] - INFO [main-EventThread:ClientCnxn$
EventThread@509] - EventThread shut down
2012-12-06 12:28:18,200 [myid:] - INFO [main:ZooKeeper@684] - Session:
0x13b6fe376cd0000 closed
观察到znode/workers已经被删除，并且会话现在也关闭。为了完成最
后的清理，退出ZooKeeper服务器
# bin/zkServer.sh stop
JMX enabled by default
Using config: ../conf/zoo.cfg
Stopping zookeeper ... STOPPED
1.1.5会话的状态和声明周期
会话的生命周期（lifetime）是指会话从创建到结束的时期，无论会话正常关闭还是因超时导导致过期。为了讨论在会话中发生了什么，我们需要考虑会话可能的状态，以及可能导致会话状态改变的事件
一个会话的主要可能状态⼤多是简单明了的：CONNECTING、CONNECTED、CLOSED和NOT_CONNECTED。状态的转换依赖于发⽣在客户端与服务之间的各种事件（见图2-6）
一个会话从NOT_CONNECTED状态开始，当ZooKeeper客户端初始化后转换到CONNECTING状态（图2-6中的箭头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实现中，系统根据每一个更新建立的顺序来分配给事务标识符。 图2-7描述了在重连情况下事务标识符（zkid）的使用。当客户端因超时与s 1 断开连接后，客户端开始尝试连接s 2 ，但s 2 延迟于客户端所知的变化。然而，s 3 对这个变化的情况与客户端保持一致，所以s 3 可以安全连接。
