ZooKeeper:04---基础语法（节点：znode）

一、节点概述

• ZooKeeper操作和维护⼀个⼩型的数据节点，这些节点被称为znode，采⽤类似于⽂件系统的层级树状结构进⾏管理

案例说明

• 此案例来自于一个“主从模式”的演示案例，可参阅：https://blog.csdn.net/qq_41453285/article/details/107147603
• 下图描述了⼀个znode树的结构，根节点包含4个⼦节点，其中三个⼦节点拥有下⼀级节点，叶⼦节点存储了数据信息：
  • /master节点：作为主节点
  • /workers节点：作为⽗节点，其下每个znode⼦节点保存了系统中⼀个可用从节点信息。如上所示，其当前只有⼀个从节点/worker/worker-1（foot.com:2181）
  • /tasks节点：作为⽗节点，其下每个znode⼦节点保存了所有已经创建并等待从节点执⾏的任务的信息，主-从模式的应用的客户端在/tasks下添加 ⼀个znode⼦节点，用来表示⼀个新任务，并等待任务状态的znode节点
  • /assign节点：作为⽗节点，其下每个znode⼦节点保存了分配到某个从节点的⼀个任务信息，当主节点为某个从节点分配了⼀个任务，就会在/assign下增加⼀个⼦节点

二、节点相关基础API

• 详情请参阅：https://blog.csdn.net/qq_41453285/article/details/107145487
• create：创建节点时可以指定数据
• get：可以获取节点的数据
• set：设置/更新路径上的数据
• stat：显示一个节点的统计/元数据
• 等

节点相关参数

• 第一行：是子节点列表
• cZxid、mZxid、pZxid：
• ctime、mtime：
• cversion、dataVersion、aclVersion：节点版本号，详情参阅：https://blog.csdn.net/qq_41453285/article/details/107146392
• ephemeralOwner：
• dataLength：当前节点数据的长度
• numChildren：子节点的数量

三、节点数据

节点数据

• znode节点可以包含数据，也可以不包含数据
• 在使用create命令创建节点时我们可以指定节点数据，也可以不指定数据

数据的格式

• 如果⼀个znode节点包含数据，那么数据存储为字节数组（byte array）
• 字节数组的具体格式特定于每个应⽤的实现，ZooKeeper并不直接提供解析的⽀持。我们可以使⽤如 Protocol Buffers、Thrift、Avro或MessagePack等序列化（Serialization）包来⽅便地处理保存于znode节点的数据格式，不过有些时候，以UTF-8或 ASCII编码的字符串已经够⽤了

数据不允许局部写入/读取

• ZooKeeper不允许局部写入或局部读取znode节点的数据。当设置或读取一个znode节点的数据时，必须全局替换或者全部读取

四、节点的类型

• 当新建znode时，还需要指定该节点的类型（mode），不同的类型决定了znode节点的⾏为⽅式
• znode的节点类型组合在一起有4种情况：
  • 持久的（persistent）：create创建节点时，不指定任何参数即为创建持久性节点
  • 临时的 （ephemeral）：create创建节点时，指定-e选项
  • 持久有序的（persistent_sequential）：create创建节点时，指定-s选项
  • 临时有序的 （ephemeral_sequential）：create创建节点时，指定-s -e选项

①持久节点

• znode节点可以是持久（persistent）节点
• 持久的znode，如/path，只能通过调⽤delete来进⾏删除
• 持久znode是⼀种⾮常有⽤的znode，可以通过持久类型的znode为应⽤保存⼀些数据，即使znode的创建者不再属于应⽤系统时，数据也可以保存下来⽽不丢失。例如，在主-从模式例⼦中，需要保存从节点的任务分配情况，即使分配任务的主节点已经崩溃了

②临时节点

• znode节点可以是临时（ephemeral） 节点
• 临时的znode与持久节点相反，当创建该节点的客户端崩溃或关闭了与ZooKeeper的连接时，这个节点就会被删除
• 临时znode传达了应⽤某些⽅⾯的信息，仅当创建者的会话有效时这些信息必须有效保存。例如，在主从模式的例⼦中，当主节点创建的znode为临时节点时，该节点的存在意味着现在有⼀个主节点，且主节点状态处于正常运⾏中。如果主znode消失后，该znode节点仍然存在，那么系统将⽆法监测到主节点崩溃。这样就可以阻⽌系统继续进⾏，因此这个znode需要和主节点⼀起消失。我们也在从节点中使⽤临时的znode，如果⼀个从节点失效，那么会话将会过期，之后znode/workers也将⾃动消失
• ⼀个临时znode，在以下两种情况下将会被删除：
  • 1.当创建该znode的客户端的会话因超时或主动关闭⽽中⽌时
  • 2.当某个客户端（不⼀定是创建者）主动删除该节点时
• 因为临时的znode在其创建者的会话过期时被删除，所以我们现在不允许临时节点拥有⼦节点。在社区讨论中，已经讨论过关于允许临时znode拥 有⼦节点的问题，其想法是使其⼦节点也均为临时节点。这个功能也许会 出现在未来的发布版本中，但现在还是不可⽤的

③有序节点

• ⼀个znode还可以设置为有序（sequential）节点
• ⼀个有序znode节点被分配唯⼀个单调递增的整数。当创建有序节点时，⼀个序号会被追加到路径之后
• 例如，如果⼀个客户端创建了⼀个有序znode节点，其路径为/tasks/task-，那么ZooKeeper将会分配⼀个序号，如1，并将这个数字追加到路径之后，最后该znode节点为/tasks/task-1
• 有序znode通过提供了创建具有唯⼀名称的znode的简单⽅式。同时也通过这种⽅式可以直观地查看znode的创建顺序

五、实现⼀个原语：通过ZooKeeper实现锁

• 关于ZooKeeper的功能，⼀个简单的例⼦就是通过锁来实现临界区域。 我们知道有很多形式的锁（如：读/写锁、全局锁），通过ZooKeeper来实 现锁也有多种⽅式。这⾥讨论⼀个简单的⽅式来说明应⽤中如何使⽤ ZooKeeper，我们不再考虑其他形式的锁

通过临时节点实现

• 死锁：
  • 假设有⼀个应⽤由n个进程组成，这些进程尝试获取⼀个锁。再次强调，ZooKeeper并未直接暴露原语，因此我们使⽤ZooKeeper的接⼜来管理 znode，以此来实现锁
  • 为了获得⼀个锁，每个进程p尝试创建znode，名 为/lock。如果进程p成功创建了znode，就表⽰它获得了锁并可以继续执⾏ 其临界区域的代码
  • 不过⼀个潜在的问题是进程p可能崩溃，导致这个锁永远⽆法释放。在这种情况下，没有任何其他进程可以再次获得这个锁，整个系统可能因死锁⽽失灵
• 为了避免这种情况，我们不得不在创建这个节点时指定/lock为临时节点：
  • 其他进程因znode存在⽽创建/lock失败。因此，进程监听/lock的变化， 并在检测到/lock删除时再次尝试创建节点来获得锁
  • 当收到/lock删除的通知时，如果进程p还需要继续获取锁，它就继续尝试创建/lock的步骤，如果 其他进程已经创建了，就继续监听节点