热爱生命,敬畏自然

zookeeper基础

2019.08.17

zoo.cfg配置文件

  • tickTime:用于计算的时间单元。比如session超时:N*tickTime

  • initLImit:用于集群,允许从节点连接并同步到master节点的初始化连接时间,以tickTime的倍数来表示

  • syncLimit:用于集群,master主节点与从节点之间发送消息,请求和应答时间的长度。(心跳机制)

  • dataDir:数据存放位置,必须配置。

  • dataLogDir:日志目录,如果不配置会和dataDir公用。

  • clientPort:连接服务器的端口,默认2181

基本概念

  • zk的数据模型也可以理解为Linux/Unix的文件目录:/usr/local/..
  • 每一个节点都称之为znode,它可以有子节点,也可以有数据。
  • 每个节点分为临时节点和永久节点,临时节点在客户端断开后消失。
  • 每个zk节点都有各自的版本号,可以通过命令行来显示节点信息。
  • 每当节点数据发生变化,那么该节点的版本号会累加(乐观锁)。
  • 删除/修改过时??节点,版本号不匹配则会报错。
  • 每个zk节点存储的数据不宜过大,几K即可。
  • 节点可以设置权限acl,可以通过权限来限制用户的访问。

zk作用体现

  1. master节点选举,主节点挂了以后,从节点就会接手工作,并且保证这个节点是唯一的,这也是所谓首脑模式,从而保证我们的集群是高可用的。
  2. 统一配置文件管理,即只需要部署一台服务器,就可以把相同的配置文件同步更新到其他所有服务器,此操作在云计算中用的特别多(假设修改了redis统一配置)
  3. 发布与订阅。类似消息队列MQ(amq,rmq...),dubbo发布者把数据存在znode上,订阅至会读取这个数据。
  4. 提供分布式锁,分布式环境中不同进程之间争夺资源,类似于多线程中的锁。
  5. 集群管理,集群中保证数据的强一致性。

zk特性——watcher机制

  1. 针对每个节点的操作,都会有一个监督者-->watcher。
  2. 当监控的某个对象(znode)发生了变化,就会触发watcher事件。
  3. zk中的watcher是一次性的,触发后立即销毁。
  4. 父节点,子节点增删改都能够触发其watcher。
  5. 针对不同类型的操作,触发的watcher事件也不同:1)(子)节点创建事件。2)(子)节点删除事件。3)(子)节点数据变化事件。

ACL的构成

  1. zk的ACL通过[scheme : id : permissions]来构成权限列表

scheme:代表采用的某种权限机制

id:代表允许访问的用户

permissions:权限组合字符串

scheme

  1. world:world下只有一个id,即只有一个用户,也就是anyone,那么组合的写法就是world:anyone:[permissions]
  2. auth:代表认证登录,需要注册用户有权限就可以,形式为auth:user:password:[permissions]
  3. digest:需要对密码加密才能访问,组合形式为digest:username:BASE64(SHA!(password)):[permissions]

简而言之,auth与digest的区别就是,前者明文,后者密文

setAcl /path auth:username:password:cdrwa

setAcl /path auth:username:BASE64(SHA!(password)):cdrwa

是等价的,在通过

addauth digest username:password后都能操作指定节点的权限。

permissions权限字符串缩写 crdwa

c:创建子节点

r:获取节点/子节点

d:删除子节点

w:设置节点数据

a:设置权限

world:anyone:cdrwa

auth:user:pwd:cdrwa

digest:user:BASE64(SHA1(pwd)):cdrwa

addauth digest user:pwd