zookeeper 客户端_zookeeper简单原理

简介

ZooKeeper 是一个开源的分布式协调服务，ZooKeeper框架最初是在“Yahoo!"上构建的，用于以简单而稳健的方式访问他们的应用程序。 后来，Apache ZooKeeper成为Hadoop，HBase和其他分布式框架使用的有组织服务的标准。ZooKeeper 将数据保存在内存中，这也就保证了高吞吐量和低延迟。

ZooKeeper 是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。

Zookeeper 一个最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心。

基本概念

1. 会话（Session）

Session 指的是 ZooKeeper 服务器与客户端会话。在 ZooKeeper 中，一个客户端连接是指客户端和服务器之间的一个 TCP 长连接。通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话。

2、Znode

在Zookeeper中“节点"分为两类，第一类同样是指构成集群的机器，我们称之为机器节点；第二类则是指数据模型中的数据单元，我们称之为数据节点一一ZNode。

Zookeeper将所有数据存储在内存中，数据模型是一棵树（Znode Tree)，由斜杠（/）的进行分割的路径，就是一个Znode，例如/foo/path1。每个上都会保存自己的数据内容，同时还会保存一系列属性信息。

3、版本

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

4、Watcher（事件监听器）

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

5、ACL（权限控制）

Zookeeper采用ACL（AccessControlLists）策略来进行权限控制，类似于 UNIX 文件系统的权限控制。Zookeeper 定义了如下5种权限。增（增加子节点权限）、删（删除子节点权限）、改（改节点权限）、查（查询节点和子节点信息）、ADMIN（设置节点的额ACL权限）。其中尤其需要注意的是，CREATE和DELETE这两种权限都是针对子节点的权限控制。

zookeeper节点特征

zookeeper是基于树形数据结构实现分布式锁，以用来解决我们分布式环境下对于共享资源的数据一致性问题。其中，zookeeper树形结构有四种节点：

• 持久节点，这是zookeeper的默认节点类型，一直存在。
• 持久顺序节点，创建的节点，zookeeper会依据时间的顺序对创建的节点进行排序。
• 临时节点，就是在zookeeper中临时创建的节点，zookeeper客户端与服务端断开或者是故障，就会删除临时节点
• 临时顺序节点，和持久顺序节点类似，只不过就是临时的。

构建 Zookeeper 集群的时候，使用的服务器最好是奇数台（Leader 选举算法采用了Zab协议。Zab核心思想是当多数 Server 写成功，则任务数据写成功。）。

ZooKeeper 特点

• 顺序一致性： 从同一客户端发起的事务请求，最终将会严格地按照顺序被应用到 ZooKeeper 中去。
• 原子性： 所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么整个集群中所有的机器都成功应用了某一个事务，要么都没有应用。
• 单一系统映像 ： 无论客户端连到哪一个 ZooKeeper 服务器上，其看到的服务端数据模型都是一致的。
• 可靠性： 一旦一次更改请求被应用，更改的结果就会被持久化，直到被下一次更改覆盖。

》》简单的数据模型（ZNode存于内存中）

》》集群架构图：

为了保证高可用，最好是以集群形态来部署 ZooKeeper，这样只要集群中大部分机器是可用的（能够容忍一定的机器故障），那么zookeeper本身仍然是可用的。客户端在使用 ZooKeeper 时，需要知道集群机器列表，通过与集群中的某一台机器建立 TCP 连接来使用服务，客户端使用这个TCP链接来发送请求、获取结果、获取监听事件以及发送心跳包。如果这个连接异常断开了，客户端可以连接到另外的机器上。

ZooKeeper 集群角色

最典型集群模式： Master/Slave 模式（主备模式）。在这种模式中，通常 Master服务器作为主服务器提供写服务，其他的 Slave 服务器从服务器通过异步复制的方式获取 Master 服务器最新的数据提供读服务。

但是，在 ZooKeeper 中没有选择传统的 Master/Slave 概念，而是引入了Leader、Follower 和 Observer 三种角色。如下图所示

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

ZAB（ZooKeeper Atomic Broadcast 原子广播） 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。 在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。

ZAB协议包括两种基本的模式，分别是 崩溃恢复和消息广播。当整个服务框架在启动过程中，或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进人恢复模式并选举产生新的Leader服务器。当选举产生了新的 Leader 服务器，同时集群中已经有过半的机器与该Leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式。其中，所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能够和Leader服务器的数据状态保持一致。

当集群中已经有过半的Follower服务器完成了和Leader服务器的状态同步，那么整个服务框架就可以进人消息广播模式了。

• 集群管理结构图

• 集群-共享锁

使用临时顺序节点实现我们的分布式锁的。

我们现在能发现获得锁的是客户端Client1，客户端Client2则监听着Client1的锁啥时候释放，而Client3就监听着Client2的锁释放。

1、当客户端Client1业务完成之后或者客户端故障，就会删除节点0001及文件，主动释放锁。

2、0001节点被删除，此时Client2就会立马监听到锁被释放，就会去获取锁。

4、最后Client3监听到0002被删除了，则自己就会去获取锁和释放锁。

投票选举：ZAB算法（少数服从多数）。

参见：

丁凯：ZAB协议选主过程详解​zhuanlan.zhihu.com

千手修罗：Zookeeper实现分布式锁详细步骤，你一定要知道​zhuanlan.zhihu.com

Zookeeper的功能以及工作原理 - 微信-大数据从业者 - 博客园​www.cnblogs.com