Zookeeper

ZOOKEEPER 的基本数据类型： 

 

 基于树的数据结构组成： 节点znode;

  对于不同树的节点，znode的引用方式是路径引用；类似于文件引用；

  /动物/小狗

  /汽车/路虎/发送机

单个节点：

 

• data：Znode 存储的数据信息。
• ACL：记录 Znode 的访问权限，即哪些人或哪些 IP 可以访问本节点。
• stat：包含 Znode 的各种元数据，比如事务 ID、版本号、时间戳、大小等等。
• child：当前节点的子节点引用

  这里需要注意一点，Zookeeper 是为读多写少的场景所设计。Znode 并不是用来存储大规模业务数据，而是用于存储少量的状态和配置信息，每个节点的数据最大不能超过 1MB。

Zookeeper 的基本操作

创建节点

create

删除节点

delete

判断节点是否存在

exists

获得一个节点的数据

getData

设置一个节点的数据

setData

获取节点下的所有子节点

getChildren

这其中，exists，getData，getChildren 属于读操作。Zookeeper 客户端在请求读操作的时候，可以选择是否设置 Watch

 

 

 

Zookeeper 的事件通知

我们可以把 Watch 理解成是注册在特定 Znode 上的触发器。当这个 Znode 发生改变，也就是调用了 create，delete，setData 方法的时候，将会触发 Znode 上注册的对应事件，请求 Watch 的客户端会接收到异步通知。

具体交互过程如下：

• 客户端调用 getData 方法，watch 参数是 true。服务端接到请求，返回节点数据，并且在对应的哈希表里插入被 Watch 的 Znode 路径，以及 Watcher 列表。

 

当被 Watch 的 Znode 已删除，服务端会查找哈希表，找到该 Znode 对应的所有 Watcher，异步通知客户端，并且删除哈希表中对应的 Key-Value。

 

spring cloud 中eureka注册中心和zookeeper数据结构的对比： 

、

Eureka的注册中心的维护是一个双向map存储；

Zookeeper则是树形结构存储；

 

Zookeeper 有变更只向注册此节点的watcher反馈--所以说zk还要维护一个watcher-table

 

Eureka 向所有的fetch的客户端反馈；

 

 

Zookeeper 的一致性

Zookeeper 身为分布式系统协调服务，如果自身挂了如何处理呢？为了防止单机挂掉的情况，Zookeeper 维护了一个集群。如下图：

 

进行了读写分离：　

主从节点 : 只有大哥才能进行写操作哦

　特殊的是：　小弟在接受到写入数据请求之后，必须先要告诉大哥；去写数据，然后再去　同步到其他从节点；－－需要Zookeeper　Atomic　BroadCast　（ZAB）协议；利用这个协议来完成数据同步的效果；

　读：　读的话从任意节点都可以进行读取；

 

zxid： 

　ZXID是一个64位的数字，低32代表一个单调递增的计数器，高32位代表Leader周期。

ZXID变化

• 当有新的Leader产生时，Leader周期epoch加1，计数器从0开始；
• 每处理一个事务请求，计数器加1；

 

 

什么是 ZAB

Zookeeper Atomic Broadcast，有效解决了 Zookeeper 集群崩溃恢复，以及主从同步数据的问题。

 

ZAB 的崩溃恢复

假如 Zookeeper 当前的主节点挂掉了，集群会进行崩溃恢复。ZAB 的崩溃恢复分成三个阶段：

Leader election

选举阶段，此时集群中的节点处于 Looking 状态。它们会各自向其他节点发起投票，投票当中包含自己的服务器 ID 和最新事务 ID（ZXID）

 

接下来，节点会用自身的 ZXID 和从其他节点接收到的 ZXID 做比较，如果发现别人家的 ZXID 比自己大，也就是数据比自己新，那么就重新发起投票，投票给目前已知最大的 ZXID 所属节点。

 

 

每次投票后，服务器都会统计投票数量，判断是否有某个节点得到半数以上的投票。如果存在这样的节点，该节点将会成为准 Leader，状态变为 Leading。其他节点的状态变为 Following。

 

 

选出的Leader开始等待其他服务器Follower的连接

Follower连接Leader将最大的zxid发送给Leader

Leader根据Follwer的zxid来确定同步点，，完成同步后通知Follower已经成为update（现时）状态

Follower收到update消息后，就可以接受Client的请求服务了。

也就是下面的两个阶段：

Discovery

发现阶段，用于在从节点中发现最新的 ZXID 和事务日志。或许有人会问：既然 Leader 被选为主节点，已经是集群里数据最新的了，为什么还要从节点中寻找最新事务呢？

这是为了防止某些意外情况，比如因网络原因在上一阶段产生多个 Leader 的情况。

所以这一阶段，Leader 集思广益，接收所有 Follower 发来各自的最新 epoch 值。Leader 从中选出最大的 epoch，基于此值加 1，生成新的 epoch 分发给各个 Follower。

各个 Follower 收到全新的 epoch 后，返回 ACK 给 Leader，带上各自最大的 ZXID 和历史事务日志。Leader 选出最大的 ZXID，并更新自身历史日志。

Synchronization

同步阶段，把 Leader 刚才收集得到的最新历史事务日志，同步给集群中所有的 Follower。只有当半数 Follower 同步成功，这个准 Leader 才能成为正式的 Leader。

自此，故障恢复正式完成。
 

 

ZAB 的数据写入，保证了各节点数据同步的一致性；

Broadcast

ZAB 的数据写入涉及到 Broadcast 阶段，简单来说，就是 Zookeeper 常规情况下更新数据的时候，由 Leader 广播到所有的 Follower。其过程如下：

• 客户端发出写入数据请求给任意 Follower。
• Follower 把写入数据请求转发给 Leader。
• Leader 采用二阶段提交方式，先发送 Propose 广播给 Follower。
• Follower 接到 Propose 消息，写入日志成功后，返回 ACK 消息给 Leader。
• Leader 接到半数以上ACK消息，返回成功给客户端，并且广播 Commit 请求给 Follower

 

  zookeeper采用了递增的事务Id来标识，所有的proposal都在被提出的时候加上了zxid，zxid实际上是一个64位的数字，高32位是epoch用来标识leader是否发生改变，如果有新的leader产生出来，epoch会自增，低32位用来递增计数。当新产生proposal的时候，会依据数据库的两阶段过程，首先会向其他的server发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始执行;

ZAB 协议既不是强一致性，也不是弱一致性，而是处于两者之间的单调一致性（顺序一致性）。它依靠事务 ID 和版本号，保证了数据的更新和读取是有序的

 

 

 

 

 

 

 

 

 

Zookeeper 的应用场景

分布式锁

这是雅虎研究员设计 Zookeeper 的初衷。利用 Zookeeper 的临时顺序节点，可以轻松实现分布式锁。

服务注册和发现

利用 Znode 和 Watcher，可以实现分布式服务的注册和发现。最著名的应用就是阿里的分布式 RPC 框架 Dubbo。

共享配置和状态信息

zk的配置管理
  程序分布式的部署在不同的机器上，将程序的配置信息放在zk的znode下，当有配置发生改变时，也就是znode发生变化时，可以通过改变zk中某个目录节点的内容，利用water通知给各个客户端 从而更改配置。

Redis 的分布式解决方案 Codis，就利用了 Zookeeper 来存放数据路由表和 codis-proxy 节点的元信息。同时 codis-config 发起的命令都会通过 ZooKeeper 同步到各个存活的 codis-proxy。

此外，Kafka、HBase、Hadoop，也都依靠Zookeeper同步节点信息，实现高可用。

分布式通知和协调

对于系统调度来说：操作人员发送通知实际是通过控制台改变某个节点的状态，然后zk将这些变化发送给注册了这个节点的watcher的所有客户端。
对于执行情况汇报：每个工作进程都在某个目录下创建一个临时节点。并携带工作的进度数据，这样汇总的进程可以监控目录子节点的变化获得工作进度的实时的全局情况。

 

Znode 节点的四种类型：

1. 持久化节点；默认的节点类型；创建节点的客户端与zk断开后，该节点任然存在；持久化到当底的硬盘的；
2. 持久节点顺序节点；

  所谓的顺序节点，就是按照阶段的创建的事件顺序对节点进行编号；

1. 临时节点：
2. 临时顺序节点；

ZOOKEEPER锁：

 

 

 

不需要设置超时机制： 因为临时节点会维护一个心跳，如果连接点宕机就会自动释放；

 

 

利用Docker-compose 创建zookeeper集群：

version: '3.1'

services:

  zoo1:

    image: zookeeper:3.4.13

    restart: always

    hostname: zoo1

    ports:

      - 2181:2181

    environment:

      ZOO_MY_ID: 1

      ZOO_SERVERS: server.1=zoo1:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888 #在局域网中可以用主机名来寻找

 

  zoo2:

    image: zookeeper:3.4.13

    restart: always

    hostname: zoo2

    ports:

      - 2182:2181

    environment:

      ZOO_MY_ID: 2

      ZOO_SERVERS: server.1=zoo1:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888

 

  zoo3:

    image: zookeeper:3.4.13

    restart: always

    hostname: zoo3

    ports:

      - 2183:2181

    environment:

      ZOO_MY_ID: 3

      ZOO_SERVERS: server.1=zoo1:2888:3888 server.2=zoo2:2888:3888 server.3=zoo3:2888:3888

 

 

单机版：

 

version: '3.1'

services:

  zoo1:

    image: zookeeper:3.4.13

    restart: always

    hostname: zoo1

 

 

 

 

    ports:

      - 2181:2181

    environment:

      ZOO_MY_ID: 1

      ZOO_SERVERS: server.1=zoo1:2888:3888

version: '3.1'

services:

  zoo1:

    image: zookeeper:3.4.13

    restart: always

    hostname: zoo1

    ports:

      - 2181:2181

    environment:

      ZOO_MY_ID: 1

      ZOO_SERVERS: server.1=zoo1:2888:3888