zookeeper的基础知识

转自：http://blog.jobbole.com/110388/

介绍    

    ZooKeeper是一个开源的分布式协调服务，由雅虎创建，是Google Chubby的开源实现。分布式应用程序可以基于ZooKeeper实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能，zookeeper也可以说是Hadoop的分布式协调服务。

    在写分布式的主要困难在于出现“部分失败”。在一条消息在网络中的两个节点之间传输，如果出现网络错误，发送者无法知道接受者是否已经收到这条消息。接受者可能在出现网络错误之前就已经收到这条消息，也可能没有收到，又或者接受者的进程已经死掉。发送者能够获得真实情况的唯一途径就是重新连接接受者，并向它发出询问，这种情况就是部分失败。

    由于部分失败是分布式系统固有的特征，因此，zookeeper的使用并不能避免出现部分失败，当然它也不会隐藏部分失败，zookeepr可以提供一组工具，使你在构建分布式应用时能够对部分失败进行正确处理。

相关的概念

   集群角色：

      在ZooKeeper中，有三种角色：

• Leader  
• Follow
• Observer

      一个ZooKeeper集群同一时刻只会有一个Leader，其他都是Follower或Observer。 ZooKeeper默认只有Leader和Follower两种角色，没有Observer角色。为了使用Observer模式，在任何想变成Observer的节点的配置文件中加入：peerType=observer；并在所有server的配置文件中，配置成observer模式的server的那行配置追加:observer，例如                              server.1:localhost:2888:3888:observer

ZooKeeper集群的所有机器通过一个Leader选举过程来选定一台被称为『Leader』的机器，Leader服务器为客户端提供读和写服务。Follower和Observer都能提供读服务，不能提供写服务。两者唯一的区别在于，Observer机器不参与Leader选举过程，也不参与写操作的『过半写成功』策略，因此Observer可以在不影响写性能的情况下提升集群的读性能。

 

         会话（Session）：

    Session是指客户端会话，在讲解客户端会话之前，我们先来了解下客户端连接。在ZooKeeper中，一个客户端连接是指客户端和ZooKeeper服务器之间的TCP长连接。ZooKeeper对外的服务端口默认是2181，客户端启动时，首先会与服务器建立一个TCP连接，从第一次连接建立开始，客户端会话的生命周期也开始了，通过这个连接，客户端能够通过心跳检测和服务器保持有效的会话，也能够向ZooKeeper服务器发送请求并接受响应，同时还能通过该连接接收来自服务器的Watch事件通知。Session的SessionTimeout值用来设置一个客户端会话的超时时间。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在SessionTimeout规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效。

 

 数据节点（ZNode）：

     在谈到分布式的时候，一般『节点』指的是组成集群的每一台机器。而ZooKeeper中的数据节点是指数据模型中的数据单元，称为ZNode。ZooKeeper将所有数据存储在内存中，数据模型是一棵树（ZNode Tree），由斜杠（/）进行分割的路径，就是一个ZNode，如/hbase/master,其中hbase和master都是ZNode。每个ZNode上都会保存自己的数据内容，同时会保存一系列属性信息。

 

     注：
     这里的ZNode可以理解成既是Unix里的文件，又是Unix里的目录。因为每个ZNode不仅本身可以写数据（相当于Unix里的文件），还可以有下一级文件或目录（相当于Unix里的目录）。

     在ZooKeeper中，ZNode可以分为持久节点和临时节点两类。

      持久节点

                                    所谓持久节点是指一旦这个ZNode被创建了，除非主动进行ZNode的移除操作，否则这个ZNode将一直保存在ZooKeeper上。

 

        临时节点       

临时节点的生命周期跟客户端会话绑定，一旦客户端会话失效，那么这个客户端创建的所有临时节点都会被移除。

另外，ZooKeeper还允许用户为每个节点添加一个特殊的属性：SEQUENTIAL。一旦节点被标记上这个属性，那么在这个节点被创建的时候，ZooKeeper就会自动在其节点后面追加上一个整型数字，这个整型数字是一个由父节点维护的自增数字。

 

            版本：

 ZooKeeper的每个ZNode上都会存储数据，对应于每个ZNode，ZooKeeper都会为其维护一个叫作Stat的数据结构，Stat中记录了这个ZNode的三个数据版本，分别是version（当前ZNode的版本）、cversion（当前ZNode子节点的版本）和aversion（当前ZNode的ACL版本）。

      

           状态信息：

• 每个ZNode除了存储数据内容之外，还存储了ZNode本身的一些状态信息。用 get 命令可以同时获得某个ZNode的内容和状态信息。如下：

  [zk: localhost:2181(CONNECTED) 0] get /yarn-leader-election

  cZxid = 0x10000000d    //Created ZXID,表示该ZNode被创建时的事务ID
  ctime = Mon Feb 18 20:41:20 CST 2019 //Created Time,表示该ZNode被创建的时间
  mZxid = 0x10000000d    //Modified ZXID，表示该ZNode最后一次被更新时的事务ID
  mtime = Mon Feb 18 20:41:20 CST 2019 //Modified Time，表示该节点最后一次被更新的时间
  pZxid = 0x10000000e    //表示该节点的子节点列表最后一次被修改时的事务ID。注意，只有子节点列表变更了才会变更pZxid，子节点内容变更不会影响pZxid。
  cversion = 1           //子节点的版本号
  dataVersion = 0        //数据节点的版本号
  aclVersion = 0         //ACL版本号
  ephemeralOwner = 0x0   //创建该节点的会话的seddionID。如果该节点是持久节点，那么这个属性值为0。
  dataLength = 0         //数据内容的长度
  numChildren = 1        //子节点的个数

  在ZooKeeper中，version属性是用来实现乐观锁机制中的『写入校验』的（保证分布式数据原子性操作）。

• 事务操作：在ZooKeeper中，能改变ZooKeeper服务器状态的操作称为事务操作。一般包括数据节点创建与删除、数据内容更新和客户端会话创建与失效等操作。对应每一个事务请求，ZooKeeper都会为其分配一个全局唯一的事务ID，用ZXID表示，通常是一个64位的数字。每一个ZXID对应一次更新操作，从这些ZXID中可以间接地识别出ZooKeeper处理这些事务操作请求的全局顺序。

       

            Watcher：

   Watcher（事件监听器），是ZooKeeper中一个很重要的特性。ZooKeeper允许用户在指定节点上注册一些Watcher，并且在一些特定事件触发的时候，ZooKeeper服务端会将事件通知到感兴趣的客户端上去。该机制是ZooKeeper实现分布式协调服务的重要特性。

 

 

             ACL：

            ZooKeeper采用ACL（Access Control Lists）策略来进行权限控制。ZooKeeper定义了如下5种权限。

• • • • • CREATE: 创建子节点的权限。

• • READ: 获取节点数据和子节点列表的权限。

  • WRITE：更新节点数据的权限。

  • DELETE: 删除子节点的权限。

  • ADMIN: 设置节点ACL的权限。

             注意：CREATE 和 DELETE 都是针对子节点的权限控制。