ZooKeeper的名字空间节点(有关znode的一切)

    上一篇有人跟我说比较深奥和抽象,确实,我写这个不是按照循序渐进的写法写的,而是先写那本OREILLY书最不清楚的部分,然后再写次不清楚的……到最后会覆盖zk的绝大多数特性,这时候会再给出一个阅读次序的建议。
    这篇来说说有关znode的一切,比较容易理解,也很容易通过zkCli.sh来实验。



分层名字空间


    上图是ZooKeeper的分层名字空间的示意图,可见这种结构很像典型的文件系统结构:以/分割各元素的一种路径,ZooKeeper名字空间的每个节点都是以这样一个路径来标识的。这样的节点统一称为znode。


Znode

    然而,ZooKeeper的名字空间和文件系统仍有着显著的差别。文件系统典型地有目录和文件,目录可包含其他目录或文件,文件则实际存储数据。而znode既可以有其他子znode,又可以存放数据(严格说是必须存放数据,真没有的话得给个“”),因此znode可以看做是目录和文件的合体。znode被用来存储Byte级或KB级的数据,如状态信息、配置信息、位置信息等,因此znode可存放数据量的最大值默认被设为1MB,请注意,该值不仅计算数据的Byte数,所有子节点的名字也要折算成Byte数计入,因此znode的子节点数也不是无限的。改大这个参数可以存储更多数据或包含更多子znode,但我非常不建议这样做,因为这与ZooKeeper的设计目的相悖,只有数据足够小,才能保证ZooKeeper的高读取性能。如果要存储大量数据,有的是其他解决方案。
    除了数据外,znode还管理了其他一些元数据,存储在stat对象中:
  • 版本号:znode的数据每次更新时,该版本号递增。当客户端请求该znode时,数据和版本号会一起发回。另外,当znode重建时版本号会被重置,这似乎很自然,但很多时候这是巨坑的来源,比如:客户端执行了’set /test “testdata” 1’,即指定版本1写/test节点,之后该znode被删除重建,数据默认置为“”,版本号还是1,此时客户端请求时虽然该版本号仍然存在,但已经是错误的数据了。
  • ACL:即Access Control List,用来限定哪些账号可以操作该znode。ZooKeeper内置了4种ACL模式,第1种是any,即不鉴权;第2种是super,即不受任何ACL约束的管理员模式;第3种是digest,使用用户名和密码进行认证;第4种是SASL,通常使用Kerberos协议来认证,但Kerberos也是个大坑,并且对性能也有一定影响。
  • 时间戳:其实就是zxid,存储该znode创建或修改时的时间戳,用于缓存验证或协调更新等。

    理解了这些就可以做点操作了,所有zkCli.sh的命令如下,主要掌握ls,get,set,create,delete几个就够玩了(应该明白为何zkCli下没有cd这样的命令):
ZooKeeper -server host:port cmd args 
        connect host:port 
        get path [watch] 
        ls path [watch] 
        set path data [version] 
        rmr path 
        delquota [-n|-b] path 
        quit  
        printwatches on|off 
        create [-s] [-e] path data acl 
        stat path [watch] 
        close  
        ls2 path [watch] 
        history  
        listquota path 
        setAcl path acl 
        getAcl path 
        sync path 
        redo cmdno 
        addauth scheme auth 
        delete path [version] 
        setquota -n|-b val path 


Znode的四种类型

    持久节点/临时节点:持久节点只能用delete来删除,通常用来保存应用的持久化数据,比如主从模式下的任务分派情况,这种数据不应该由于主节点的崩溃而丢失。临时节点则顾名思义,除了客户端主动删除该节点时会消失外,创建该znode的客户端断开连接时该节点也会消失,因此它常用来检测会话的有效性,例如主从模式下的主节点注册一个znode,当该主节点崩溃或断开时,该znode会立即消失,于是应用可以检测到该故障并重新选举主节点,这种用法极为常见比如kafka。另外,临时节点不允许有子节点。
    有序节点:znode还可以被设置为有序节点,当这样的节点被创建时,一个会自动递增的序号会加到路径之后,比如客户端创建一个有序znode并指定路径为/tasks/task,则第一个创建的节点是/tasks/task-0000000001,该节点消亡后再创建这样的节点会产生/tasks/task-0000000002,以此类推。有序znode提供了创建具有唯一命名的znode的方式。
    这两种类型互相结合后就会产生znode的四种类型:持久的,临时的,持久有序的,临时有序的。


监视和通知

    我们知道,访问ZooKeeper的基本方式是使用API,很多场景我们需要访问一个znode,如果使用轮询的方式,不仅不能实时知晓变更(取决于轮询间隔),更恶劣的是会大大增加ZooKeeper的负载。比较好的方式是,对该znode设置一个监视(watch),当某些事件发生时触发一个通知(notification)。注意监视点是一次性的,如果通知被触发后还需要继续监视该znode,则需要设置一个新的watch。
    ZooKeeper异步通知设置watch的客户端。但是ZooKeeper能够保证在znode的变更生效之后才会异步地通知客户端,然后客户端才能够看到znode的数据变更。由于网络延迟,多个客户端可能会在不同的时间看到znode数据的变更,但是看到变更的顺序是保证有序的。
    Znode可以设置两类watch,一个是Data Watches(该znode的数据变更导致触发watch事件),另一个是Child Watches(该znode的孩子节点发生变更导致触发watch事件)。API和watch间的关系如下表:
Java API
Data Watches
Child Watches
getData
设置

exists
设置

setData
触发

create
触发

getChildren

设置
create某znode的子节点

触发
delete
触发
触发
如删除的znode有父节点,其父节点上也触发

    当某个znode的变化可触发监视点时,ZooKeeeper会触发其上可触发的所有监视点,这在某些情况下可能会产生问题,如1000个客户端都在监视某znode的Data时,当该znode的数据发生变化,会触发1000个通知,这会造成性能的波动,比如同一时刻的提交操作可能延迟。解决这一问题,OREILLY书上给出了一个利用有序节点的办法(这块书上写的不错,但翻译依旧很烂,现实中很常用所以整理下):例如n个客户端都抢一把锁。第一种方法是抢到的客户端创建/lock节点,其余客户端便监视该节点的删除事件,当占用锁的客户端完成操作断开时,/lock节点删除,其他客户端获得通知,这种方法就有性能问题。另一种方法是,所有客户端均创建有序节点/lock/lock-xxx,其中xxx为序号,xxx最小的客户端获得锁,其余客户端监视前一个节点,例如有/lock/lock-001,/lock/lock-002,/lock/lock-003三个节点时,001的客户端获得锁,002的客户端监视001的znode,003的客户端监视002的znode,当001的锁释放时,002即获得锁,以此类推,这种方式下每个znode上监视的客户端只有一个,尽管总watches数是一样的,却不会造成性能的波动。
    监视点也是有存储开销的,一个监视点对应服务端的一个Watcher对象,大约消耗300字节内存,因此管理大量的监视点也有不小的开销,运维人员应该注意连接数和产生的监视点数,以免造成OOM。
    另外,如果客户端与ZooKeeper断开连接,客户端就无法触发watches,除非再次与ZooKeeper建立连接。


    关于znode暂时能想到的就这些,如有遗漏会在后续的章节中进行补充。



©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页