ZooKeeper - Overview

为什么80%的码农都做不了架构师？>>>   

• 前提：Google 三论文

  • GFS   ——> HDFS（产品）
  • BigTable    ——> HBase（产品）
  • MapReduce ——> HadoopMapReduce（产品）
  • paxos 算法
  • PS ： Google 三论文是分布式系统发展的推动力，为分布式系统发展做出了很大的贡献和影响
  • （百度是中国最大号称科技公司的广告公司）

• ZooKeeper 是什么 : 

  • zookeeper 是一个分布式的，高性能的，开源的分布式系统的协调服务，是 Hadoop 和 HBase 的重要组件。它是一个为分布式应用提供一致性服务的软件。

• ZooKeeper 能做什么，应用场景

  • 命名服务
  • 配置维护
  • 集群管理
  • 分布式消息同步和协调机制
  • 负载均衡
  • HA （高可用）
  • 分布式锁
  • ps ： Zoopkeeper提供了一套很好的分布式集群管理的机制，就是它这种基于层次型的目录树的数据结构，并对树中的节点进行有效管理，从而可以设计出多种多样的分布式的数据管理模型，作为分布式系统的沟通调度桥梁。

• ZooKeeper 核心理念

  • 一致 —— 分布式环境下的一致性
  • 有头 —— 永远都有一个 Leader
  • 数据树 —— znode （节点名称 + 节点数据） 

• ZooKeeper 官网 

  • https://zookeeper.apache.org/

• zoo.cfg 详解

  • 路径 ： zookeeper_home/conf/zoo.cfg
  • tickTime ： 心跳时间间隔，单位是毫秒
    • ps : session 的超时时间是 tickTime  的 2 倍；
  • initLimit :  leader & follwer 初始连接时能容忍的最大心跳数，用来限定集群中 follwer 连接到 leader 的时间限制。
  • syncLimit : leader & follwer 同步通信时限，假如响应超过syncLimit * tickTime，Leader认为Follwer死掉，从服务器列表中删除Follwer。在运行过程中，Leader负责与ZK集群中所有机器进行通信，例如通过一些心跳检测机制，来检测机器的存活状态。
    如果L发出心跳包在syncLimit之后，还没有从F那收到响应，那么就认为这个F已经不在线了。
  • dataDir：数据文件目录+数据持久化路径，保存内存数据库快照信息的位置，如果没有其他说明，更新的事务日志也保存到数据库。
  • clientPort ： 客户端连接端口。

• zookeeper 命令行 crud 操作

  • 通过 zkCli 脚本启动 zookeeper 客户端。
  • 命令 help 查看命令提示帮助信息。
  • 命令 ls  {path} 查看指定路径下节点 ， 根路径为 / , 例如执行命令 ： ls /  ，会得到 [ zookeeper]  , zookeeper 就是根节点。（每个 znode 默认存储 1MB 数据。）
  • 命令 create 节点名称 节点数据 创建一个节点指定名称和节点数据。
    • create -s  /path data acl  : 创建有序节点
    • create -e /path data acl :  创建临时节点
  • 命令 get path , set path data , 获取节点数据和设置节点数据。
  • 命令 delete path ，删除节点，如果没有该节点下没有子节点的话 ， rmr path 递归删除节点。

• znode​​​​​​

  • Data model and the hierarchical namespace
    • ZooKeeper提供的名称空间与标准文件系统类似。 名称是以斜杠（/）分隔的路径元素序列。 ZooKeeper的名称空间中的每个节点都由路径标识。
  • ZooKeeper's Hierarchical Namespace
    • 

• znode 的 stat 结构

  • Znode维护了一个stat结构，这个stat包含数据变化的版本号、访问控制列表变化、还有时间戳。版本号和时间戳一起，可让Zookeeper验证缓存和协调更新。每次znode的数据发生了变化，版本号就增加。
  • czxid : 每次修改ZooKeeper状态都会收到一个zxid形式的时间戳，也就是ZooKeeper事务ID。事务ID是ZooKeeper中所有修改总的次序。
  • ctime :   znode 被创建的毫秒数从1970年开始 （因为根节点 / 的创建日期是 Thu Jan 01 08:00:00 CST 1970）
  • mzxid :   znode 最后更新的zxid
  • mtime :  znode 最后修改的毫秒数从1970年开始（创建，修改子节点的时候这个值不会变化）
  • pzxid :  znode 最后更新的子节点zxid
  • cversion :  znode 子节点版本变化号，znode 子节点修改次数
  • dataVersion : znode 数据变化版本号
  • aclVersion :  znode 访问控制列表的变化版本号
  • ephemeralOwner :  如果是临时节点，这个值是 znode 拥有者的 session id,如果不是临时节点这个值是 0
  • dataLength :  znode 中保存数据的长度（单位字节）
  • numChildren : znode 子节点数

• znode 模式

  • EPHEMERAL_SEQUENTIAL （临时顺序编号节点） ： 在客户端断开连接后，znode将被删除，其名称将被附加一个单调递增的数字。
  • EPHEMERAL  （临时节点） ： 在客户端断开连接后，znode将被删除。
  • PERSISTENT_SEQUENTIAL  （持久化顺序编号节点）  :  客户端的断开连接后，znode不会被自动删除，其名称将会以单调递增的数字进行追加。
  • PERSISTENT  （持久化节点） : 在客户端断开连接后，znode不会被自动删除。

转载于:https://my.oschina.net/j4love/blog/891042