zookeeper学习(五)

Watch的注意事项：

1.Watches通知是一次性的，必须重复注册.
2.同一个ZK客户端，反复对同一个ZK节点（znode）注册相同的watcher，是无效的，最终只会有一个生效。
3.发生CONNECTIONLOSS之后，只要在session_timeout之内再次连接上（即不发生SESSIONEXPIRED），那么这个连接注册的watches依然在。
4.客户端会话失效之后，所有这个会话中创建的Watcher都会被移除。
5.节点数据的版本变化会触发NodeDataChanged，注意，这里特意说明了是版本变化。存在这样的情况，只要成功执行了setData()方法，无论内容是否和之前一致，都会触发NodeDataChanged事件。
6.对某个节点注册了watcher，但是节点被删除了，那么注册在这个节点上的watcher都会被移除。

再说说几点个人认为比较重要的：

Client与ZooKeeper之间的通信，需要创建一个Session，这个Session会有一个超时时间。因为ZooKeeper集群会把Client的Session信息持久化，所以在Session没超时之前，Client与ZooKeeper Server的连接可以在各个ZooKeeper Server之间透明地移动。

在ZooKeeper集群中，读可以从任意一个ZooKeeper Server读，这一点是保证ZooKeeper比较好的读性能的关键；写的请求会先Forwarder到Leader，然后由Leader来通过ZooKeeper中的原子广播协议，将请求广播给所有的Follower，Leader收到一半以上的写成功的Ack后，就认为该写成功了，就会将该写进行持久化，并告诉客户端写成功了。（有点像Paxos的ZAB协议）

对于每个更新操作，ZK都会在确保事务日志已经落盘后，才会返回客户端响应。因此事务日志的输出性能在很大程度上影响ZK的整体吞吐性能。强烈建议是给事务日志的输出分配一个单独的磁盘。

zookeeper客户端对server的操作都是不可回退的，意思是说，zk的客户端每次和server进行通信的时候，会记住server上最新的zxid。如果某个时刻，客户端和server断开了连接，那么等到下次重新连接到集群中的机器上时，会检查当前连接上的那个server是否和client有相同的zxid，或者已经是更新的zxid了。一旦客户端发现server的zxid比自己小，那么客户端会断开和这个server的连接，并且重新连接集群中的其它server~

1. zxid是检验的标准

2. 这里是客户端主动断开连接，尝试连接其它server的

ephemeral节点是临时性的, 如果创建该节点的session结束了, 该节点就会被自动删除. ephemeral节点不能拥有子节点. 虽然ephemeral节点与创建它的session绑定, 但只要该该节点没有被删除, 其他session就可以读写该节点中关联的数据. 使用-e参数指定创建ephemeral节点.

如果想对ZK的简单原理有兴趣，可以参见这篇博客：

http://www.wuzesheng.com/?p=2609#more-2609

最后说一下ACL，ACL就是(Access Control)即控制访问znode的权限的。我查了一些资料，分享一下：

建议看原博客，向原博客作者致敬。

***************************************ACL***********************************

以下转自；http://www.wuzesheng.com/?p=2438

传统的文件系统中，ACL分为两个维度，一个是属组，一个是权限，子目录/文件默认继承父目录的ACL。而在Zookeeper中，node的ACL是没有继承关系的，是独立控制的。Zookeeper的ACL，可以从三个维度来理解：一是scheme; 二是user; 三是permission，通常表示为scheme:id:permissions, 下面从这三个方面分别来介绍：

（1）scheme: scheme对应于采用哪种方案来进行权限管理，zookeeper实现了一个pluggable的ACL方案，可以通过扩展scheme，来扩展ACL的机制。zookeeper-3.4.4缺省支持下面几种scheme:

world: 它下面只有一个id, 叫anyone, world:anyone代表任何人，zookeeper中对所有人有权限的结点就是属于world:anyone的

auth: 它不需要id, 只要是通过authentication的user都有权限（zookeeper支持通过kerberos来进行authencation, 也支持username/password形式的authentication)

digest: 它对应的id为username:BASE64(SHA1(password))，它需要先通过username:password形式的authentication

ip: 它对应的id为客户机的IP地址，设置的时候可以设置一个ip段，比如ip:192.168.1.0/16, 表示匹配前16个bit的IP段

super: 在这种scheme情况下，对应的id拥有超级权限，可以做任何事情(cdrwa)

另外，zookeeper-3.4.4的代码中还提供了对sasl的支持，不过缺省是没有开启的，需要配置才能启用，具体怎么配置在下文中介绍。

sasl: sasl的对应的id，是一个通过sasl authentication用户的id，zookeeper-3.4.4中的sasl authentication是通过kerberos来实现的，也就是说用户只有通过了kerberos认证，才能访问它有权限的node.

（2）id: id与scheme是紧密相关的，具体的情况在上面介绍scheme的过程都已介绍，这里不再赘述。

（3）permission: zookeeper目前支持下面一些权限：

CREATE(c): 创建权限，可以在在当前node下创建child node

DELETE(d): 删除权限，可以删除当前的node

READ(r): 读权限，可以获取当前node的数据，可以list当前node所有的child nodes

WRITE(w): 写权限，可以向当前node写数据

ADMIN(a): 管理权限，可以设置当前node的permission

如前所述，在zookeeper中提供了一种pluggable的ACL机制。具体来说就是每种scheme对应于一种ACL机制，可以通过扩展scheme来扩展ACL的机制。在具体的实现中，每种scheme对应一种AuthenticationProvider。每种AuthenticationProvider实现了当前机制下authentication的检查，通过了authentication的检查，然后再进行统一的permission检查，如此便实现了ACL。所有的AuthenticationProvider都注册在ProviderRegistry中，新扩展的AuthenticationProvider可以通过配置注册到ProviderRegistry中去。下面是实施检查的具体实现：

void checkACL(ZooKeeperServer zks, List<acl> acl, int perm,
    List<id> ids) throws KeeperException.NoAuthException {
  if (skipACL) {
    return;
  }
  if (acl == null || acl.size() == 0) {
    return;
  }
  for (Id authId : ids) {
    if (authId.getScheme().equals("super")) {
      return;
    }
  }
  for (ACL a : acl) {
    Id id = a.getId();
    if ((a.getPerms() & perm) != 0) {
      if (id.getScheme().equals("world")
          && id.getId().equals("anyone")) {
        return;
      }   
      AuthenticationProvider ap = ProviderRegistry.getProvider(id
          .getScheme());
      if (ap != null) {
        for (Id authId : ids) {
          if (authId.getScheme().equals(id.getScheme())
              && ap.matches(authId.getId(), id.getId())) {
            return;
          }   
        }   
      }   
    }   
  }
  throw new KeeperException.NoAuthException();
}

猜你喜欢