Zookeeper的架构

Zookeeper的服务器端运行两种模式：独立模式（standalone）和仲裁模式（quorum）。
独立模式只是一个单独的服务器，Zk的状态无法进行复制。
仲裁模式下，Zk拥有一组服务器，称之为Zk集合，它们之间可以进行状态复制。

znode的版本

每个znode都有一个版本号，随着数据的变化而进行自增。比如执行set和delete两次操作，这两次调用以版本号作为转入参数，只有当传入的版本号与服务器上的版本号一致时才会调用成功。比如客户端c1对znode/config写入了一些配置信息，如果另外一个c2同时更新了这个znode，此时c1的版本号已经过期，c1调用set就会失败。

Zookeeper的节点类型

层级树状结构

在Zookeeper中，维护了一个小型的数据节点，这些节点称为znode，采用类似于文件系统的层级树状结构进行管理。
根节点包含4个子节点，其中三个子节点拥有下一级节点，叶子节点存储了数据信息。

• /workers下面的每个子节点保存了一个可用的从节点信息。
• /tasks下面的每个znode子节点表示了已经创建，并等待从节点执行的任务信息。
• /assign下面的每个znode子节点保存了分配到某个从节点的一个任务信息，当主节点为从节点分配了一个任务信息，就会在/assign下增加一个子节点。

znode的不同类型

持久节点
持久的znode只能通过delete来删除。
持久类型的znode可以为应用保存一些数据，保证数据不丢失。

临时节点
当创建该节点的客户端与Zookeeper的连接断开时，这个节点就会被删除。
临时节点主要传递了应用层面的一些信息。在主从模式中，当主节点创建了一个临时节点时，这个临时节点的存在表示主节点状态正常。从节点中使用临时znode也可以检测从节点是否有效。
临时节点存在以下两种情况会被删除：

• 创建该znode的客户端会话超时或主动关闭。
• 某个客户端主动删除该节点。

有序节点
一个znode可以被设置为有序节点。有序节点会被分配一个唯一的单调递增的整数。
例如创建/tasks/task-的时候，Zookeeper将会分配一个唯一的序列号追加到路径之后，最终名称为/tasks/task-1

总结
znode总共有四种类型

• 持久的（persistent）
• 临时的（ephemeral）
• 持久有序（persistent sequential）
• 临时有序（ephemeral sequential）

Zookeeper监视与通知

如果客户端每次访问znode节点的时候，客户端都要获取节点的所有内容，这会导致很高的延迟，代价很大。所以Zookeeper选择了基于通知的机制。首先，客户端告知Zookeeper自己要通过哪一个znode来接收通知，也就是在znode上设置一个监视点；当节点发生变化时，客户端会受到这个通知，并从Zookeeper上获取到最新的数据。其次，通知是一种单次触发的操作，客户端每次接收到通知后，必须再次设置一个新的监视点。
如果客户端在接收到通知，并设置下一个新的监视点之前，节点数据发生了变化呢？
客户端在每次设置新的通知的时候，都需要先从节点读取数据，这样就不会错过所有的变更。

通知的类型

通知的类型取决于设置监视点的类型，如监控znode的数据变化、监控znode子节点的变化、监控znode的创建和删除。

Zookeeper的仲裁

当Zk存在多个副本的时候，Zk会复制集群中所有服务器的数据树，如果让客户端等待服务器复制完所有数据后再继续，显然会存在较高的延迟。所以在Zk中可以设定法人数量。例如，我们一共有5个Zk服务器，将法定人数设置为3。这样，只要任何3个服务器保存了数据，客户端就可以继续，而其他两个服务器最终也将会捕获到数据，并进行保存。

法定人数的设置不能太大或太小，一般设置为服务器数量的多数，并且服务器数量一般为奇数个（不是必须的，但偶数个会使系统更加脆弱）。例如总共5台Zk服务器，则可以将法定人数数量设置为3。

Zk的会话

在进行操作Zookeeper前，客户端需要与服务端建立会话。当一个会话终止时，这个会话期间创建的所有临时节点都将会消失。
会话提供了顺序保障，同一个会话中的请求会以FIFO的顺序执行。如果客户端拥有多个并发的会话，那么FIFO的顺序在多个会话之间未必能够保持。

会话的生命周期

会话的生命周期是指会话从创建到结束的时期。
会话的相关状态主要有：CONNECTING、CONNECTED、CLOSED、NOT_CONNECTED