Zookeeper体系结构

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

下面这张图显示了客户端和服务端的关系，每一个客户端都需要导入到客户端的类库中，然后才可以与zookeeper的节点进行交互

Zookeeper可以运行在两种模式中分别是独立模式和复制模式，独立模式就是允许在一台主机上，zookeeper的状态并不能被复制；对于集群模式，我们可以保证服务端的状态一致，并且同时一起收到来自客户端的请求。

Zookeeper的集群模式

在集群模式中，zookeeper需要复制他们的数据信息来保证所有的服务端信息一致性，那么如果每个客户端都需要等所有的信息一致的话，时间将会非常的长。在一个公共的管理中，我们可以采取以下办法，例如有5台zookeeper服务器，但是可以有三个集群的话，那么客户端只需要在3个集群信息保持一致的话，就可以进行以下的操作，后面的2台zookeeper服务器最终会赶上和存储数据。

重要的是如何选择一个适当的大小的群体，最后必须保证，无论延迟和系统崩溃,任何更新请求，服务都可以执行下去。

在一个有5个节点的集合体中，每个Follower节点的数据都是Leader节点数据的副本，也就是说我们的每个节点的数据视图都是一样的，这样就可以有五个节点提供ZooKeeper服务。并且集合体中任意2台机器出现故障，都可以保证服务继续，因为剩下的3台机器超过了半数。

回话

在客户端与zookeeper交互之前，客户端必须与服务端建立一个回话。回话是必须的，任何客户端的操作都必须在回话中完成，一旦回话结束，临时节点也将会消失。

会话保证了顺序的执行,这意味着请求在一个会话中执行FIFO(先进先出)。通常情况下,一个客户只有一个会话打开,所以它的请求都是先进先出顺序执行。如果一个客户有多个并发会话，先进先出顺序不一定是保存在会话。连续会话相同的客户,即使他们不重叠,也不一定保持先进先出顺序。这是可能发生在这种情况下:

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

2.   第一个回话过期了

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

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