zookeeper系列(三)—节点详解

zookeeper系列(三)—节点详解_第1张图片

前言

大家好,牧码心今天给大家推荐一篇zookeeper系列(三)—节点详解,在实际工作中有很多应用场景,希望对你有所帮助。内容如下:

  • 背景
  • 节点类型
  • 节点属性
  • 节点监听
  • 权限机制

背景

我们在zookeeper的数据模型中介绍过zookeeper 中数据基本单元叫节点,节点之下可包含子节点,最后以树级方式程现,类型linux的文件系统结构。不同之处是znode没有目录的概念,不能执行类似cd之类的命令。znode整体结构包含如下,后面会对他们分别进行详细介绍。

  • path:唯一路径
  • childNode:子节点
  • stat:状态属性
  • type:节点类型

节点类型

根据zookeeper的节点类型,可分类如图表所示:

类型 描述
PERSISTENT 持久节点
PERSISTENT_SEQUENTIAL 持久序号节点
EPHEMERAL 临时节点(不可在拥有子节点)
EPHEMERAL_SEQUENTIAL 临时序号节点(不可在拥有子节点)
  • PERSISTENT(持久节点)
    持久化保存数据的节点,也是zookeeper默认创建的,创建方式如:

    #默认创建的就是持久节点
    [zk: hadoop01:2181(CONNECTED) 7] create /zk-data test
    Created /zk-data
    
  • PERSISTENT_SEQUENTIAL(持久序号节点)
    创建时zookeeper 会在路径上加上序号作为后缀,非常适合用于分布式锁、分布式选举等场景。创建时添加 -s 参数即可。如:

    #创建序号节点
    [zk: hadoop01:2181(CONNECTED) 9] create -s /zk-seq test
    #返回创建的实际路径
    Created /zk-seq0000000005
    
  • EPHEMERAL(临时节点)
    临时节点会在客户端会话断开后自动删除。适用于心跳,服务发现等场景。创建时添加参数-e 即可.如

    # 创建临时节点,断开会话时连接会自动删除
    [zk: hadoop01:2181(CONNECTED) 10] create -e /zk-temp test
    Created /zk-temp
    
  • EPHEMERAL_SEQUENTIAL(临时序号节点)
    与持久序号节点类似,不同之处在于EPHEMERAL_SEQUENTIAL是临时的会在会话断开后删除。创建时添加 -e -s

    # 创建临时序号节点,断开会话时连接会自动删除
    [zk: hadoop01:2181(CONNECTED) 11] create -e -s /zk-temp-seq test
    Created /zk-temp-seq0000000007
    

节点属性

  • 什么是节点属性
    zookeeper的节点属性,包括节点数据,状态,权限等信息,通过属性可分析出每个节点的作用
  • 节点属性说明
    zookeeper可以通过如下方式查看节点属性,详细说明下:
# 查看节点属性
[zk: hadoop01:2181(CONNECTED) 12] stat /zk-data

其属性说明如下:

#创建节点的事物ID
cZxid = 0x3600000004
# 创建时间
ctime = Sun Mar 29 19:43:55 CST 2020
# 修改节点的事务ID
mZxid = 0x3600000004
# 最后修改时间
mtime = Sun Mar 29 19:43:55 CST 2020
# 子节点变更的事务ID
pZxid = 0x3600000004
# 此znode的子节点进行的更改次数(不包括子节点)
cversion = 0
# 数据版本变更次数
dataVersion = 0
# 权限版本变更次数
aclVersion = 0
# 临时节点会话属性ID
ephemeralOwner = 0x0
# 数据长度
dataLength = 4
# 子节点数(不包括子子节点)
numChildren = 0

下面重点说下版本号和事务ID

  • 版本号(以数据版本号(dataVersion)来说明zk中版本号的作用)
    每一个znode都有一个dataVersion,它随着每次数据变化而自增。ZooKeeper提供的一些API例如setData和delete根据版本号有条件地执行。多个客户端对同一个znode进行操作时,版本号的使用就会显得尤为重要。例如,假设客户端C1对znode /config写入一些配置信息,如果另一个客户端C2同时更新了这个znode,此时C1的版本号已经过期,C1调用setData一定不会成功。这正是版本机制有效避免了数据更新时出现的先后顺序问题。在这个例子中,C1在写入数据时使用的版本号无法匹配,使得操作失败。下图演示版本号的作用:
    zookeeper系列(三)—节点详解_第2张图片
  • 事务ID(cZxid )
    对于zk来说,每次的变化都会产生一个唯一的事务id,zxid(ZooKeeper Transaction Id)。通过zxid,可以确定更新操作的先后顺序。例如,如果zxid1小于zxid2,说明zxid1操作先于zxid2发生。zxid对于整个zk都是唯一的,即使操作的是不同的znode。

节点监听

客户端使用时添加 -w 参数可实时监听节点与子节点的变化,并且实时收到通知。非常适用保障分布式情况下的数据一至性。其使用方式如下:

命令 描述
ls -w path 监听子节点的变化(增,删)
get -w path 监听节点数据的变化
stat -w path 监听节点属性的变化
printwatches on|off 触发监听后,是否打印监听事件(默认on)

权限设置

zookeeper采用ACL机制控制权限,ACL全称为Access Control List(访问控制列表),用于控制资源的访问权限。使用ACL来控制对其znode的防问,基于schemapermission的方式设置权限,

  • scheme:表示授权模式;
  • id:模式对应值;
  • permission:即具体的增删改权限位;

scheme:授权模式

方案 描述
world 开放模式,world表示全世界都可以访问(这是默认设置)
ip ip模式,限定客户端IP防问
auth 用户密码认证模式,只有在会话中添加了认证才可以防问
digest 与auth类似,区别在于auth用明文密码,而digest 用sha-1+base64加密后的密码。在实际使用中digest 更常见。

permission权限位

权限位 权限 描述
c CREATE 可以创建子节点
d DELETE 可以删除子节点(仅下一级节点)
r READ 可以读取节点数据及显示子节点列表
w WRITE 可以设置节点数据
a ADMIN 可以设置节点访问控制列表权限

acl 相关命令:

命令 使用方式 描述
getAcl getAcl 读取ACL权限
setAcl setAcl 设置ACL权限
addauth addauth 添加认证用户

world模式实例

  • 语法: setAcl path world:anyone:<权限位>

注:world模式中anyone是唯一的值,表示所有人

  • 查看默认节点权限:
#创建一个临时节点
[zk: hadoop01:2181(CONNECTED) 0] create -e /testAcl acl
Created /testAcl
#查看节点权限
[zk: hadoop01:2181(CONNECTED) 2] getAcl /testAcl
#返回的默认权限表示 ,所有人拥有所有权限。
'world,'anyone: cdrwa
  • 修改默认权限为 读写
#设置为rw权限 
setAcl /testAcl world:anyone:rw
# 可以正常读
get /testAcl
# 无法正常创建子节点
create -e /testAcl/t "test"
# 返回没有权限的异常
Authentication is not valid : /testAcl/t

IP模式示例:

  • 语法
 setAcl  path  ip:<ip地址|地址段>:<权限位>

auth模式示例:

  • 语法
1. setAcl path  auth:<用户名>:<密码>:<权限位>
2. addauth digest <用户名>:<密码>
  • 实例
# 创建一个testAuth的临时节点
[zk: hadoop01:2181(CONNECTED) 6] create -e /testAuth 'auth'
# 通过addauth 添加用户名和密码
[zk: hadoop01:2181(CONNECTED) 11] addauth digest hadoop:hadoop
# 设置Acl权限
[zk: hadoop01:2181(CONNECTED) 12] setAcl /testAuth auth:hadoop:hadoop:rw
# 查看节点权限的时候,密码会自动转为密文,该密文是采用user:BASE64(SHA1(password))的字符串
[zk: hadoop01:2181(CONNECTED) 14] getAcl /testAuth
'digest,'hadoop:81HcY8+GzcGdYZBJgxWhKNSB9Kw=: rw

digest 模式示例:

  • 语法
1. setAcl <path> digest :<用户名>:<密钥>:<权限位>
2. addauth digest <用户名>:<密码>

密钥 通过sha1与base64组合加密码生成,可通过以下命令生成

echo -n <用户名>:<密码> | openssl dgst -binary -sha1 | openssl base64

为节点设置digest 权限后,访问前必须执行addauth,当前会话才可以防问。

  • 设置digest 权限
#先 sha1 加密,然后base64加密
[hadoop@hadoop01 zookeeper-3.4.8]$ echo -n hadoop:hadoop | openssl dgst -binary -sha1 | openssl base64
#返回密钥
81HcY8+GzcGdYZBJgxWhKNSB9Kw=
#设置digest权限
[zk: hadoop01:2181(CONNECTED) 2] setAcl /testDigest digest:hadoop:81HcY8+GzcGdYZBJgxWhKNSB9Kw=:cdrw
  • 查看节点将显示没有权限
#查看节点
[zk: hadoop01:2181(CONNECTED) 3] get /testDigest 
#显示没有权限访问
Authentication is not valid : /testDigest
  • 给当前会话添加认证后在次查看
#给当前会话添加权限帐户
[zk: hadoop01:2181(CONNECTED) 0]  addauth digest hadoop:hadoop
#在次查看
[zk: hadoop01:2181(CONNECTED) 1]  get /testDigest
#获得返回结果
digest:hadoop:81HcY8+GzcGdYZBJgxWhKNSB9Kw=:cdrw

ACL的特殊说明:权限仅对当前节点有效,不会让子节点继承。如限制了IP防问A节点,但不妨碍该IP防问A的子节点 /A/B。

你可能感兴趣的:(zookeeper,zookeeper,znode)