zookeeper相关文档

zk的命令行操作

连接zk 　/bin/zkCli.sh -server 127.0.0.1:4180

 

 

zk的数据模型（The ZooKeeper Data Model）

zk是结构化的（hierarchal）,类似分布式文件系统。

1. .结点路径以“/”来分隔，全部是绝对路径，而且只能使用unicode字符

• 不能有空格（\u0000）
• 各种符号不能用
• .和..不能用
• “zookeeper”为保留字段

2.Watches(观察者)

　　客户端可以在某个znode上增加watchs,当znode发生变化时，会发送一个通知给watches,并且清除掉这些watches。后面再讨论watches的用法。

3.Data Access　数据存储

　（１）每个znode既可以看作是目录名称，同时也可以看作是文件，所以能够存储数据。

　（２）znode的数据读写都是原子操作；

　（３）znode都可以有权限控制。即Access Control List (ACL)

　（４）zookeeper并不适合存大数据，zk会做sanity　check，确保节点数据不会大于１Ｍ，一般情况下，应该远小于１Ｍ，只在Ｋ级别

４.临时节点（Ephemeral Nodes）

　（１）节点存活与创建该节点的session相关，session结束节点就被删除；

　（２）不能有子节点。

5.顺序节点（Sequence Nodes），使用惟一命名

　（１）单调递增（monotonically increasing）

　（２）最大不能超过2147483647，以这种方式命名<path>0000000001；如果超过2147483647，则返回<apth>-2147483647;

6.Time in ZooKeeper

    Zxid 每个操作都会有惟一的ID标识，zxid(ZooKeeper Transaction Id).这标识这一操作在zk上的总顺序，如果两个操作zxid1<zxid2，说明zxid1对应的操作先发生。

    Version numbers 所有操作都会使用版本号递增，zk有多个版本号，后面会分开讨论；

    Ticks 

    When using multi-server ZooKeeper, servers use ticks to define timing of events such as status uploads, session timeouts, connection timeouts between peers, etc. The tick time is only indirectly exposed through the minimum session   timeout (2 times the tick time); if a client requests a session timeout less than the minimum session timeout, the server will tell the client that the session timeout is actually the minimum session timeout.

 

    Real time zk不使用绝对时间，只使用时间时间戳，所以不存在时钟问题。

7.zk structure  数据节构

    czxid 创建节点的操作ID

 

    mzxid 最后修改数据的操作ID

 

    ctime 从创建点开始的毫秒数

 

    mtime 从最近数据修改点开始的毫秒数

 

    dataversion 当前节点数据修改次数的版本号

 

    cversion 子节点变更的版本号

 

    aversion ACL变更的版本号

 

    ephemeralOwner  如果是临时节点，这个值为sessionId of the owner of this znode.否则为0

 

    dataLength 数据长度

 

    numChildren  子节点数

 

8.Session 

2.在client session创建时，如果无法连接到集群的某一台服务时（partitioned，非timeout）,会尝试在服务列表（ list of servers）中找一个重连，连接成功进入刚connected状态，不成功则进入expired（timeout了）。如果timeout,此时不建议new 一个新的zookeeper Session对象来进行重连，而是让zk自已重连（ The ZK client library will handle reconnect for you）；客户端库已经有了这种机制，来避免羊群效应（herd effect）。

3.只有在session到期时才需要重建session,而且是强制的。

  （1）session过期是由服务端管理的。

  （2）客户端在建立连接时使用timeout来标识过期时间,服务端以此控制是否过期；

  （3）如果服务端在过去一个timeout时间内未收到client的心跳，就会使session过期；

   (4) 一旦session过期，server clsuter会删除所有属性该session的全部临时节点，并通知所在这些节点上的watcher(当然不包括当前的session的watcher,因为它收不到),当前session会一直处于disconnected状态，直到TCP连接重新建立，而此时，当前session上的watcher会收到一个session expired的通知；

like this:

Example state transitions for an expired session as seen by the expired session's watcher:

 

   'connected' : session is established and client is communicating with cluster (client/server communication is operating properly)

 

   .... client is partitioned from the cluster

 

   'disconnected' : client has lost connectivity with the cluster

 

   .... time elapses, after 'timeout' period the cluster expires the session, nothing is seen by client as it is disconnected from cluster

 

   .... time elapses, the client regains network level connectivity with the cluster

 

   'expired' : eventually the client reconnects to the cluster, it is then notified of the expiration

4.创建session的另一个参数：default Watcher

 (1)客户端的任何状态改变都会通知到default watcher,包括连接断开、session过期等。

 (2)default watcher可以看作连接默认为是未连接状态的，所有的状态改变都是客户端库来通知defalut watcher的（ any state changes events are sent to the watcher by the client lib，所以可以收到断开连接、过期的通知）；

（3）对于新连接来说，dafault watcher收到的第一个事件，一般都是连接成功事件。 the first event sent to the watcher is typically the session connection event.

    

  5.session是由client通过发送PING requests来进行”保活“的。这个是双向判定（verify），既可以判断session是否still alive,也可以判断当前连接的ZooKeeper server is still active；ping的时间间隔要合理，才能更好的发现死链。

 

        6.以下两种情况会抛出异常：

          （1）无效session上执行操作；

          （2）当有异步操作正在执行时断开连接；

 

        7.SessionMovedException 一个不常见的异常，一般情况下不客户端不会捕获到这个异常。

          （1）发生条件：client 与server A已经建立了连接，在某次发送请求时，由于网络原因，A没有及时收到，些时client判断A列掉了，于是向client B发起重连，而且连接成功。而此时 ，A又收到了client的请求，这时A 判断 client session已经被移除了，所以抛出SessionMovedException；

          （2）但此种情况client是收不到这个异常的，因为client到A的连接已经被丢弃了，使用的是client到B的连接；

          （3）极端情况：当两个client使用同一个sessionId和password进行session 重建时（reeastablish），第一个会成功，第二个失败。这样将导致两个client会一直反复的重建session(causing the pair to attempt to re-establish its connection/session indefinitely).

 

 

 

9.ZooKeeper Watches

  (1)One-time trigger 一次触发

 （2）Sent to the client

      <1>表示（implies）watcher client 收到通知一定是在change client收到成功修改的返回值之后。比如：clientA在watcher节点X，clientB在修改X的data，server修改完成后（还未返回给B修改成功），此时notify A已经on the way了，但是并不会立即到达A，而是先要等B收到返回值后，才会到达A；

      <2>通知A的动作是异步的；

      <3>ZooKeeper provides an ordering guarantee: a client will never see a change for which it has set a watch until it first sees the watch event.

      <4>The key point is that everything seen by the different clients will have a consistent order.任何客户端看到的事件顺序都是一致的。

 

 

  （3）Watcher的种类

      <1> 通过getData()和exists()设置data watches.

      <2> 通过getChildren设置child watches

      <3> setData()触发当前节点的data

      <4> create()触发当前节点的data,父节点的child

      <5> delete()触发当前节点的data\child,父节点的child

  (4)watcher由与client相连接的server来管理，如果client重新连接一台server,将会重新注册这些watches;

     When a client connects to a new server, the watch will be triggered for any session events.

     watcher丢失的场景：如果exist()在某个节点，当session断开期间，该节点被创建或者被删除时，watcher是收不到通知的。

 

  （5）zookeeper对watcher的顺序保证：

      <1> Watches are ordered with respect to other events, other watches, and asynchronous replies. The ZooKeeper client libraries ensures that everything is dispatched in order.

 

      <2> 当client watche的某个节点数据变化时，一定是选收到通知，才能获得该节点的数据变化；

   

      <3>watch events的顺序一定是与zk看到的update顺序一致；

   （6）问题

     <1>由于watches是一次性的，所以必须重复设置，但是获取通知－再次重复设置成功之间的数据变化就无法发现了。甚至这期间会有多次变化，这种情况需要另外想办法来处理。

10.java Binding

(1)

      (2)创建ZooKeeper对象时，会启动两个线程：IO thread 和 Event thread

           session重连、心跳、同步方法的执行和返回都是在IO thread上完成

           异步方法的执行和返加、watche event都在 event thread上完成