了解zookeeper
Posted duan2
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了了解zookeeper相关的知识,希望对你有一定的参考价值。
ZooKeeper操作和维护多个小型的数据节点,这些节点被称为znode,采用类似于文件系统的层级树状结构进行管理。图2-1描述了一个znode树的结构,根节点包含4个个节点,其中三个子节点拥有下一级节点,叶子节点存储了数据信息。
针对一个znode,没有数据常常表达了重要的信息。如,在主-从模式的例子中,主节点的znode没有数据,表示当前还没有选举出主节点。⽽
图2-1中涉及的一些其他znode节点在主-从模式的配置中非常有用:
1.1.1 API概述
znode节点可能含有数据,也可能没有。如果一个znode节点包含任何数据,那么数据存储为字节数组(byte array)。字节数组的具体格式特定于每个应用的实现,ZooKeeper并不直接提供解析的支持。我们可以使用Protocol Buffers、Thrift、Avro或MessagePack等序列化(Serialization)包来放便地处理保存于znode节点的数据格式,不过有些时候,以UTF-8或
ASCII编码的字符串已经够用了
ZooKeeper的API暴露了以下⽅法:
- create/path data
创建一个名为/path的znode节点,并包含数据data。
- delete/path
删除名为/path的znode。
- exists/path
检查是否存在名为/path的节点。
- setData/path data
设置名为/path的znode的数据为data。
- getData/path
返回名为/path节点的数据信息。
- getChildren/path
返回所有/path节点的所有的节点列表。
需要注意的是,ZooKeeper并不允许局部写的或读取znode节点的数据。当设置一个znode节点的数据或读取时,znode节点的内容会被整个替换或全部读取进来。
1.1.2 znode的不同类型
当新建znode时,还需要指定该节点的类型(mode),不同的类型决定了znode节点的行为方式。
持久节点和临时节点
znode节点可以是持久(persistent)节点,还可以是临时(ephemeral)节点。持久的znode,如/path,只能通过调用delete来进行删除。临时的znode与之相反,当创建该节点的客户端崩溃或关闭了与ZooKeeper的连接时,这个节点就会被删除。
持久znode是一种非常有用的znode,可以通过持久类型的znode为应用保存这些数据,即使znode的创建者不再属于应用系统时,数据也可以保存下来而不丢失。例如,在主-从模式例中,需要保存从节点的任务分配情况,即使分配任务的主节点已经崩溃了。
临时znode传达了应用某些方面的信息,仅当创建者的会话有效时这些信息必须有效保存。例如,在主从模式的例子中,当主节点创建的znode为临时节点时,该节点的存在意味着现在有一个主节点,且主节点状态处于正常运行中。如果主znode消失后,该znode节点仍然存在,那么系统将无法监测到主节点崩溃。这样就可以阻止系统继续进行,因此这个znode需要和主节点一起消失。我们也在从节点中使用临时的znode,如果一个从节点失效,那么会话将会过期,之后znode/workers也将自动消失。
一个临时znode,在以下两种情况下将会被删除:
1.当创建该znode的客户端的会话因超时或主动关闭而中止时。
2.当某个客户端(不一定是创建者)主动删除该节点时。
因为临时的znode在其创建者的会话过期时被删除,所以我们现在不允
许临时节点拥有子节点。
有序节点
一个znode还可以设置为有序(sequential)节点。一个有序znode节点被分配唯一个单调递增的整数。当创建有序节点时,一个序号会被追加到路径之后。例如,如果一个客户端创建了一个有序znode节点,其路径为/tasks/task-,那么ZooKeeper将会分配一个序号,如1,并将这个数字追加到路径之后,最后该znode节点为/tasks/task-1。有序znode通过提供了创建具有唯一名称的znode的简单方式。同时也通过这种方式可以直观地查看znode的创建顺序。
总之,znode一共有4种类型:持久的(persistent)、临时的(ephemeral)、持久有序的(persistent_sequential)和临时有序的(ephemeral_sequential)。
1.1.3 监视与通知
ZooKeeper通常以远程服务的方式被访问,如果每次访问znode时,客户端都需要获得节点中的内容,这样的代价就非常大。因为这样会导致更高的延迟,而且ZooKeeper需要做更多的操作。考虑图2-2中的例子,第一次调用getChildren/tasks返回了相同的值,一个空的集合,其实是没有必要的。
这是一个常见的轮询问题。为了替换客户端的轮询,我们选择了基于通知(notification)的机制:客户端向ZooKeeper注册需要接收通知的znode,通过对znode设置监视点(watch)来接收通知。监视点是一个单次触发的操作,意即监视点会触发一个通知。为了接收多个通知,客户端必须在每次通知后设置一个新的监视点。在图2-3阐述的情况下,当节点/tasks发生变化时,客户端会收到一个通知,并从ZooKeeper读取一个新值。
当使用通知机制时,还有一些需要知道的事情。因为通知机制是单次触发的操作,所以在客户端接收一个znode变更通知并设置新的监视点时,znode节点也许发生了新的变化(不要担心,你不会错过状态的变化)。
通知机制的一个重要保障是,对同一个znode的操作,先向客户端传送通知,然后再对该节点进行变更。如果客户端对一个znode设置了监视点,而该znode发生了两个连续更新。第一次更新后,客户端在观察第2次变化前就接收到了通知,然后读取znode中的数据。我们认为主要特性在于通知机制阻止了客户端所观察的更新顺序。虽然ZooKeeper的状态变化传播给某些客户端时更慢,但我们保障客户端以全局的顺序来观察ZooKeeper的状态。
1.1.4版本
每一个znode都有一个版本号,它随着每次数据变化而递增。两个API操作可以有条件地执行:setData和delete。这两个调用以版本号作为转入参数,只有当转入参数的版本号与服务器上的版本号一致时调用才会成功。当多个ZooKeeper客户端对同一个znode进行操作时,版本的使用就会显得尤为重要。例如,假设客户端c 1 对znode/config写入了一些配置信息,如果另一个客户端c 2 同时更新了这个znode,此时c 1 的版本号已经过期,c 1 调用setData一定不会成功。使用版本机制有效避免了以上情况。在这个例子中,c 1 在写入数据时使用的版本号法匹配,使得操作失败,图2-4描述了这个情况。
以上是关于了解zookeeper的主要内容,如果未能解决你的问题,请参考以下文章