Zookeeper体系结构

上面我们已经讨论了zookeeper在应用程序中的一些操作，以下我们须要理解一下服务端的工作的原理。client是怎样通过一个client的类库与服务端进行通信的，然后服务端又是怎样回应client的。

以下这张图显示了client和服务端的关系，每一个client都须要导入到client的类库中。然后才干够与zookeeper的节点进行交互

Zookeeper能够运行在两种模式中各自是独立模式和复制模式，独立模式就是同意在一台主机上。zookeeper的状态并不能被复制；对于集群模式，我们能够保证服务端的状态一致。而且同一时候一起收到来自client的请求。

Zookeeper的集群模式

在集群模式中。zookeeper须要复制他们的数据信息来保证全部的服务端信息一致性。那么假设每一个client都须要等全部的信息一致的话。时间将会很的长。在一个公共的管理中，我们能够採取以下办法，比如有5台zookeeperserver。可是能够有三个集群的话，那么client仅仅须要在3个集群信息保持一致的话，就能够进行以下的操作，后面的2台zookeeperserver终于会赶上和存储数据。

重要的是怎样选择一个适当的大小的群体，最后必须保证，不管延迟和系统崩溃,不论什么更新请求，服务都能够运行下去。

在一个有5个节点的集合体中，每一个Follower节点的数据都是Leader节点数据的副本，也就是说我们的每一个节点的数据视图都是一样的，这样就能够有五个节点提供ZooKeeper服务。而且集合体中随意2台机器出现问题，都能够保证服务继续，由于剩下的3台机器超过了半数。

回话

在client与zookeeper交互之前，client必须与服务端建立一个回话。回话是必须的，不论什么client的操作都必须在回话中完毕，一旦回话结束，暂时节点也将会消失。

会话保证了顺序的运行,这意味着请求在一个会话中运行FIFO(先进先出)。通常情况下,一个客户仅仅有一个会话打开,所以它的请求都是先进先出顺序运行。假设一个客户有多个并发会话。先进先出顺序不一定是保存在会话。

连续会话同样的客户,即使他们不重叠,也不一定保持先进先出顺序。

这是可能发生在这样的情况下:

1.   client建立一个会话,使连续两个异步调用创建/task和/worker

2.   第一个回话过期了

3.   client创建了另外一个回话，异步的调用创建了/assign

在这个调用序列,它是可能的,仅仅有创建了/task和/assign,它保留了第一次回话中先进先出的顺序,但违反了跨回话。