Zookeeper(二) 介绍

什么是Zookeeper

Zookeeper是一种分布式协调服务, 用于管理大型主机。在分布式环境中协调和管理服务是一个复杂的过程。Zookeeper通过其简单的架构和API解决了这个问题, Zookeeper允许开发人员专注于核心应用程序逻辑, 而不必担心应用程序的分布式特性。

Zookeeper是一个高可用的分布式管理与协调框架, 基于ZAB算法(原子消息广播协议)的实现. 该框架能够很好的保证分布式环境中数据的一致性。

安装

通过docker-compose文件安装zookeeper, docker-compose文件中配置的是zookeeper的集群方式

version: '3.1'
services:
  zoo1:
    image: zookeeper:3.4
    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
    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
    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

客户端访问

安装成功后, 可以通过zookeeper自带的zkCli.sh访问zookeeper

docker exec -it 容器id zkCli.sh

如果使用idea可以下载zookeeper的插件

• 打开idea –》 Settings -》Plugins,搜索Zoo进行下载安装

• 配置Zookeeper的连接信息
• 

特点

简单的数据结构

zookeeper就是以简单的树形结构来进行相互协调的

集群

一般zookeeper集群通常由一组机器构成, 一般3-5台机器就可以组成一个zookeeper集群。只要集群中超过半数以上的机器能够正常工作, 整个集群就能够正常对外提供服务。

顺序访问

对于来自每一个客户端的每一个请求, zookeeper都会分配一个全局唯一的递增编号, 这个编号反应了所有事务操作的先后顺序, 应用程序可以使用zookeeper的这个特性来实现更高层次的同步

高性能

zookeeper将全量数据存储在内存中, 并直接服务与所有的非事务请求, 因此尤其在读操作为主的场景下性能非常突出。在JMeter压力测试下(100%读请求场景), 其结果大约在12-13W的QPS

Zookeeper的数据模型

Zookeeper的数据模型是什么样子呢? 它很像数据结构当中的树, 也很像文件系统的目录, Zookeeper是一种标准的二叉树结构

树是由节点所组成, Zookeeper的数据存储也同样是基于节点, 这种节点叫做Znode

但是, 不同于树的节点, Znode的引用方式是路径引用, 类似于文件路径

/动物/狗

/汽车/宝马

这样的层级结构, 让每一个Znode节点拥有唯一的路径, 就像命名空间一样, 对不同信息作出清晰的隔离

Znode包含哪些元素

data: Znode中的数据信息

ACI: 记录Znode的访问权限, 即哪些人或哪些IP可以访问本节点

state: 包含Znode的各种元数据, 比如事务ID, 版本号, 时间戳, 大小等等

child: 当前节点的子节点引用

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

Zookeeper应用场景

配置管理

应用中用到的一些配置信息放到 ZK 上迚行集中管理。这类场景通常是这样：应用在启劢的时候会主劢来获取一次配置，同时，在节点上注册 一个 Watcher，这样一来，以后每次配置有更新的时候，都会实时通知到订阅的客户端，从来达到获取最新配置信息的目的

集群管理

zookeeper能够帮你维护当前集群中机器的服务状态

命名服务(Naming Service)

命名服务也是分布式系统中比较常见的一类场景。在分布式系统中，通过使用命名服务，客户端应用能够根据挃定名字来获取资源戒服务的地址， 提供者等信息。被命名的实体通常可以是集群中的机器，提供的服务地址，进程对象等等——这些我们都可以统称他们为名字（Name）。其中较 为常见的就是一些分布式服务框架中的服务地址列表。通过调用 ZK 提供的创建节点的 API，能够很容易创建一个全局唯一的 path，这个 path 就 可以作为一个名称

阿里开源的分布式服务框架 Dubbo 中使用 ZooKeeper 来作为其命名服务，维护全局的服务地址列表

Dubbo 实现中：

服务提供者在启劢的时候，向 ZK 上的挃定节点/dubbo/${serviceName}/providers 目彔下写入自己的 URL 地址，这个操作就完成了服务的 发布

服务消费者启劢的时候，订阅/dubbo/${serviceName}/providers 目彔下的提供者 URL 地址， 并向/dubbo/${serviceName} /consumers 目彔下写入自己的 URL 地址。

注意，所有向 ZK 上注册的地址都是临时节点，这样就能够保证服务提供者和消费者能够自劢感应资源的变化

分布式通知/协调

ZooKeeper 中特有 watcher 注册异步通知机制，能够很好的实现分布式环境下不同系统间的通知，实现对数据变更的实时处理。使用 方法通常是所有系统对 ZK 上同一个 znode 迚行注册，监听 znode 的变化（包括 znode 本身内容及子节点的），其中一个系统 update 了 znode， 那么另一个系统能够收到通知，并作出相应处理

另一种心跳检测机制：检测系统和被检测系统间并直接关联起来，而是通过 zk 上某个节点关联，大大减少系统耦合

分布式锁

分布式锁，这个主要得益于 ZooKeeper 为我们保证了数据的强一致性。锁服务可以分为两类，一个是保持独占，另一个是控制时序。

所谓保持独占，就是所有试图来获取这个锁的客户端，最终只有一个可以成功获得这把锁。通常的做法是把 zk 上的一个 znode 看作是一把锁，

通过 create znode 的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。

控制时序，就是所有视图来获取这个锁的客户端，最终都是会被安排执行，只是有个全局时序了。做法和上面基本类似，只是这里 /distribute_lock 已 绊 预 先 存 在 ， 客 户 端 在 它 下 面 创 建 临 时 有 序 节 点 （ 这 个 可 以 通 过 节 点 的 属 性 控 制 ： CreateMode.EPHEMERAL_SEQUENTIAL 来挃定）。Zk 的父节点（/distribute_lock）维持一份 sequence,保证子节点创建的时序性，从而也 形成了每个客户端的全局时序

分布式队列

Zookeeper的配置

zoo.cfg的配置

tickTime: 基本事件单元，以毫秒为单位。这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每隔 tickTime时间就会发送一个心跳。

dataDir：存储内存中数据库快照的位置，顾名思义就是 Zookeeper 保存数据的目录，默认情况下，Zookeeper 将写数据的日志文件也保存在这个目录里

clientPort： 这个端口就是客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。

initLimit: 这个配置项是用来配置 Zookeeper 接受客户端初始化连接时最长能忍受多少个心跳时间间隔数当已经超过 10 个心跳的时间（也就是 tickTime）长度后 Zookeeper 服务器还没有收到客户端的返回信息那么表明这个客户端连接失败。

syncLimit：这个配置项标识 Leader 与 Follower 之间发送消息，请求和应答时间长度，最长不能超过多少个 tickTime 的时间长度，总的时间长度就是 5*2000=10 秒

server.A = B:C:D :

A表示这个是第几号服务器,

B 是这个服务器的 ip 地址；

C 表示的是这个服务器与集群中的 Leader 服务器交换信息的端口；

D 表示的是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader

Zookeeper的基本操作

创建节点

create

删除节点

delete

判断节点是否存在

exists

获得一个节点的数据

getData

设置一个节点的数据

setData

获取节点下的所有子节点

getChildren

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