大数据之zookeeper

zookeeper数据模型

1.分层命名空间。

2.每个命名空间的节点都叫做“znode”。

3.每个znode被路径区分（如：/app1）。

4.znode节点类型– 永久节点和临时节点。

5.临时节点不能有子节点。

6.每个znode节点有数据，也可以选择

有子节点。

7.znode不能被重命名。

8.可以给znode增加或者删除watchers。

• 每个节点（znode）中存储的是同步相关的数据（这是ZooKeeper设计的初衷，数据量很小，大概B到KB量级），例如状态信息、配置内容、位置信息等。

• 一个znode维护了一个状态结构，该结构包括：版本号、ACL变更、时间戳。每次znode数据发生变化，版本号都会递增，这样客户端的读请求可以基于版本号来检索状态相关数据。 

• 每个znode都有一个ACL，用来限制是否可以访问该znode。 

• 在一个命名空间中，对znode上存储的数据执行读和写请求操作都是原子的。 

• 客户端可以在一个znode上设置一个监视器（Watch），如果该znode数据发生变更，ZooKeeper会通知客户端，从而触发监视器中实现的逻辑的执行。

• 每个客户端与ZooKeeper连接，便建立了一次会话（Session），会话过程中，可能发生CONNECTING、CONNECTED和CLOSED三种状态。 

• ZooKeeper支持临时节点（Ephemeral Nodes）的概念，它是与ZooKeeper中的会话（Session）相关的，如果连接断开，则该节点被删除。  l若非操作人员删除，永久节点会永久保存，所以永久节点可以用来保存元数据，而临时节点则可用来进行leader选举及锁服务等。

Zookeeper关键特性

• l最终一致性：无论哪个server，对外展示的均是同一个视图。  

• 实时性：保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。  

• 可靠性：一条消息被一个server接收，它将被所有server接受。  

• 等待无关性：慢的或者失效的client不会干预快速的client的请求，使得每个client都能有效的等待。  

• 原子性：更新只能成功或者失败，没有中间状态。  l顺序一致性：客户端所发送的更新会按照它们被发送的顺序进行应用。

ACL（访问控制列表）

• ACL可以控制访问ZooKeeper的节点，只能应用于特定的znode上，而不能应用于该znode的所有子节点上。设置ACL命令为 setAcl /znode scheme:id:perm。  

• Scheme为认证方式， ZooKeeper内置了4种方式：  

  1.world 一个单独的ID，表示任何人都可以访问。

   2.auth 不使用ID，只有认证的用户可以访问。

  3.digest 使用username:password生成MD5哈希值作为认证ID。  

  4.IP 使用客户端主机IP地址来进行认证。  

• Id：用来认证的字段，用来判断认证信息是否合法，不同的scheme的认证方式不同。  

• Perm：即permission，通过Acl认证的用户对该节点可拥有的操作权限。

• 在对节点进行操作时，只有通过节点ACL认证的用户才能访问该节点并对其进行操作。可以使getAcl命令来查询一个节点的Acl信息。  

• Zookeeper 中的目录节点权限(znode 权限)不具有传递性，父目录节点的权限不能传递给子目录节点。  

• 当前最为常用的ACL认证方式为sasl方式（一种依赖于kerberos的认证方式，在非安全环境中不能使用。），是ZooKeeper服务端通过记录登录用户的认证信息作为scheme来设置节点的ACL的一种方式。  

• perm 有 ALL、READ、WRITE、CREATE、DELETE、ADMIN 几种
  

•     例如：setAcl /znode sasl:admin@HADOOP.COM:cdrwa