Zookeeper入门基础知识

Zookeeper

1、Zookeeper概述

Zookeeper是一个开源的分布式协调服务框架，主要用来解决分布式集群中应用系统中的一致性问题和数据管理问题

2、Zookeeper的特点

• Zookeeper本质上是一个分布式文件系统，适合存放小文件，也可以理解为一个数据库，简言之其核心是一个精简的文件系统
• 高可用性
• 松耦合的交互方式
• 富表现性（分布式队列、选举机制等）

3、Zookeeper的应用场景

3.1、数据发布/订阅

需要发布者将数据发布到Zookeeper的节点上，供订阅者进行数据订 阅，进而达到动态获取数据的目的，实现配置信息的集中式管理和数据的动态更新

发布/订阅一般有两种设计模式：推模式和拉模式，服务端主动将数据更新发送给所有订阅的 客户端称为推模式；客户端主动请求获取最新数据称为拉模式

Zookeeper采用了推拉相结合的模式，客户端向服务端注册自己需要关注的节点，一旦该节点 数据发生变更，那么服务端就会向相应的客户端推送Watcher事件通知，客户端接收到此通知 后，主动到服务端获取最新的数据

3.2、命名服务

Zookeeper可以实现一套分布式全局唯一ID的分配机制

3.3、分布式协调/通知

• 心跳检测

  不同机器间需要检测到彼此是否在正常运行，可以使用Zookeeper实现机 器间的心跳检测，基于其临时节点特性（临时节点的生存周期是客户端会话，客户端若当即 后，其临时节点自然不再存在），可以让不同机器都在Zookeeper的一个指定节点下创建临时 子节点，不同的机器之间可以根据这个临时子节点来判断对应的客户端机器是否存活。通过 Zookeeper可以大大减少系统耦合

• 工作进度汇报

  通常任务被分发到不同机器后，需要实时地将自己的任务执行进度汇 报给分发系统，可以在Zookeeper上选择一个节点，每个任务客户端都在这个节点下面创建临 时子节点，这样不仅可以判断机器是否存活，同时各个机器可以将自己的任务执行进度写到 该临时节点中去，以便中心系统能够实时获取任务的执行进度

• 系统调度

  Zookeeper能够实现如下系统调度模式：分布式系统由控制台和一些客户 端系统两部分构成，控制台的职责就是需要将一些指令信息发送给所有的客户端，以控制他 们进行相应的业务逻辑，后台管理人员在控制台上做一些操作，实际上就是修改Zookeeper上 某些节点的数据，Zookeeper可以把数据变更以时间通知的形式发送给订阅客户端

3.4、分布式锁

​ 分布式锁用于控制分布式系统之间同步访问共享资源的一种方式，可以保证不同系统访 问一个或一组资源时的一致性，主要分为排它锁和共享锁

• 排他锁（写锁/独占锁）

  当某个事务获取对象的排他锁，只允许该事务对这个对象进行读取或写入，其他事务不允许对该对象进行任何其他操作，直到该事务释放排他锁

  ① 获取锁，在需要获取排它锁时，所有客户端通过调用接口，在/exclusive_lock节点下创建 临时子节点/exclusive_lock/lock。Zookeeper可以保证只有一个客户端能够创建成功，没有成 功的客户端需要注册/exclusive_lock节点监听。
  ② 释放锁，当获取锁的客户端宕机或者正常完成业务逻辑都会导致临时节点的删除，此 时，所有在/exclusive_lock节点上注册监听的客户端都会收到通知，可以重新发起分布式锁获 取。

• 共享锁（读锁）

  若事务T1对数据对象O1加上共享锁，那么当前事务只能对O1进行读取操 作，其他事务也只能对这个数据对象加共享锁，直到该数据对象上的所有共享锁都被释放。 在需要获取共享锁时，所有客户端都会到/shared_lock下面创建一个临时顺序节点

3.5、分布式队列

​ 有一些时候，多个团队需要共同完成一个任务，比如，A团队将Hadoop集群计算的结果交 给B团队继续计算，B完成了自己任务再交给C团队继续做。这就有点像业务系统的工作流一 样，一环一环地传下 去.
分布式环境下，我们同样需要一个类似单进程队列的组件，用来实现跨进程、跨主机、跨网 络的数据共享和数据传递，这就是我们的分布式队列。

4、Zookeeper架构介绍

• Leader
  • 集群工作核心，内部各个服务器的调度者
  • Leader负责进行投票选举（对写入操作进行投票）
  • 处理事务性（写入操作）操作
  • 参与集群投票
• Follower
  • Follower用于接收客户端需求，并向客户端返回结果
  • 处理客户端非事务（读操作）请求
  • 转发事务请求给leader
  • 参与集群投票
• Observer
  • Observer用于接收客户端需求，并向客户端返回结果
  • 处理客户端非事务（读操作）请求
  • 转发事务请求给leader
  • 不参与集群投票

5、选举投票机制

关键词/概念词

脑裂
当服务器的leader由于网络连接，导致超时处理信息，此时follow将寻找leader的信息广播到其他follow，Follow开始选举投票，由于Zookeeper集群的自发投票选举leader，此时旧leader重新连接，新旧leader节点的数据不一致
超半数选举
在投票选举时，默认赞成票超过集群服务器数半数以上
容灾机制
容灾机制，即在服务器集群宕机数未超过半数，尚能进行投票操作，例如集群中5台服务器，最多容忍2台服务器宕机，如果集群服务器数为6台，最多容忍2台（若宕机3台，剩余三台投票数未能过半，视为服务集群瘫痪）
协议内容

• paxos（paoxs算法这边就不详细拓展）
  前提没有拜占庭将军问题
  即是paoxs 在可信的计算环境中才能成立，这个环境是不会被入侵锁破坏的
• ZAB
  • 作用在可用状态有Lader时
    • 在推举lader 时，节点可能处于不同的状态，有的停止服务，有的不停止服务
    • lader挂了之后，重新推举lader
      a)前置条件 每个追随者自己会有myid 以及 zxid
      b)经验最丰富的Zxid
      c)myid
      d)*. 过半通过的数据才是真数据，你见到的可用的Zxid
      e)推举过程:
      1. 相同端口，造成两两通信
      2. 只要任何人投票，都会触发哪个准lader 发起自己的投票
         逻辑：先比较Zxid，如果Zxid 相同，再比较myid
  • zookeeper 有两种运行状态
    • 1. 可用状态
    • 2. 不可用状态(不可用状态恢复到可用状态应该越快越好)

6、Zookeeper的数据模型

树形层次结构

• Znode特点

  • 兼具**文件和目录**两种特点

  • 存储数据有大小限制（1MB以内）

  • 通过路径引用，路径必须是绝对路径

  • 数据访问具有原子性，要么读到所有数据，要么读操作失败

• Znode的组成部分

  • state

    描述当前Znode的状态、版本、权限等信息

  • data

    当前Znode所存储的数据

  • children

    该Znode下的子节点

• Znode的分类

  • PERSISTENT：永久节点
  • EPHEMERAL：临时节点
    • 临时节点会绑定一个客户端会话，但其可见性是对所有用户的
  • PERSISTENT_SEQUENTIAL：永久节点、序列化
  • EPHEMERAL_SEQUENTIAL：临时节点、序列化

7、Zookeeper的shell客户端命令

• 登陆Zookeeper客户端命令

  your_host_ip：zookeeper部署服务器ip地址

  2181:zookeeper默认端口号

  bin/zkCli.sh -server your_host_ip:2181
  

• Zookeeper操作命令

  • create [-s][-e] path data acl

    创建Znode -s指定顺序节点 -e指定临时节点

  • ls path [watch]

    列出Path下所有的子Znode

  • get path [watch]

    获取Path对应的Znode的数据和属性

  • ls2 path [watch]

    查看Path下所有子Znode以及子 Znode的属性

  • set path data [version]

    更新节点 version 数据版本

  • delete path [version]

    删除节点, 如果有子Znode则无法删除 version 数据版本

  • rmr path

    删除节点, 如果有子Znode则递归删除 version 数据版本

  • setquota -n|-b val path

    修改Znode配额 -n设置子节点最大个数 -b设置节点数据最大长度

  • history

    列出历史记录

8、Znode节点属性

• dataVersion

  数据版本号，每次对节点进行 set 操作，dataVersion 的值都会增加 1（即使设 置的是相同的数据），可有效避免了数据更新时出现的先后顺序问题

• cversion

  子节点的版本号。当 znode 的子节点有变化时，cversion 的值就会增加 1。

• aclVersion

  ACL 的版本号

• cZxid

  Znode 创建的事务 id

• mZxid

  Znode 被修改的事务 id，即每次对 znode 的修改都会更新 mZxid

  • 对于 zk 来说，每次的变化都会产生一个唯一的事务 id，zxid（ZooKeeper Transaction Id）。通过 zxid，可以确定更新操作的先后顺序
  • 小于 zxid2，说明 zxid1 操作先于 zxid2 发生，zxid 对于整个 zk 都是唯一的，

• ctime

  节点创建时的时间戳

• mtime

  节点最新一次更新发生时的时间戳

• ephemeralOwner

  :如果该节点为临时节点, ephemeralOwner 值表示与该节点绑定的 session id. 如果不 是,ephemeralOwner 值为 0

9、Zookeeper的watch机制

• 通知类似于数据库中的触发器, 对某个Znode设置 Watcher , 当Znode发生变化的时候, WatchManager 会调用对应的 Watcher
• 当Znode发生删除, 修改, 创建, 子节点修改的时候, 对应的 Watcher 会得到通知

9.1、Watcher 的特点

• 一次性触发 一个 Watcher 只会被触发一次, 如果需要继续监听, 则需要再次添加 Watcher
• 事件封装: Watcher 得到的事件是被封装过的, 包括三个内容 keeperState, eventType, path