Zookeeper -分布式协调服务器

  • 官方文档：https://zookeeper.apache.org/doc/current/index.html

Zookeeper 是什么

  • ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

  • 简单来说zookeeper=文件系统+监听通知机制。

文件系统

  • Zookeeper维护了一个类似文件系统的数据结构：
dock

  • 每一个目录都是一个znode(目录节点)，跟文件系统一样我们可以自由的增加和删除znode,且每个znode都可以存储数据。

  • znode有4种类型：

    • PERSISTENT-持久化目录节点

      • 客户端与zookeeper断开连接后，该节点依旧存在

    • PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点

      • 客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号

    • EPHEMERAL-临时目录节点

      • 客户端与zookeeper断开连接后，该节点被删除，短暂znode不可以有子节点。

    • EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点

      • 客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

监听通知机制

  • 客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端。

zookeeper 的特性

事务操作：

  • 在ZooKeeper中，能改变ZooKeeper服务器状态的操作称为事务操作。一般包括数据节点创建与删除、数据内容更新和客户端会话创建与失效等操作。对应每一个事务请求，ZooKeeper都会为其分配一个全局唯一的事务ID，用 ZXID 表示，通常是一个64位的数字。每一个 ZXID对应一次更新操作，从这些 ZXID 中可以间接地识别出 ZooKeeper 处理这些事务操作请求的 全局顺序

Watcher(事件监听)

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

Zookeeper可以做什么

分布式服务注册与订阅

  • 在分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提供方都会部署多份，达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业务逻辑，比较典型的服务注册与订阅，代表：dubbo。

分布式配置中心

  • 发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到ZK节点上，供订阅者获取数据，实现配置信息的集中式管理和动态更新。代表：百度的disconf。

命名服务

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

分布式锁

  • 分布式锁，这个主要得益于ZooKeeper为我们保证了数据的强一致性。锁服务可以分为两类，一个是保持独占，另一个是控制时序。
  • 所谓保持独占，就是所有试图来获取这个锁的客户端，最终只有一个可以成功获得这把锁。通常的做法是把zk上的一个znode看作是一把锁，通过create znode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。
  • 控制时序，就是所有视图来获取这个锁的客户端，最终都是会被安排执行，只是有个全局时序了。做法和上面基本类似，只是这里 /distribute_lock 已绊预先存在，客户端在它下面创建临时有序节点（这个可以通过节点的属性控制：CreateMode.EPHEMERAL_SEQUENTIAL来指定）。Zk的父节点（/distribute_lock）维持一份sequence,保证子节点创建的时序性，从而也形成了每个客户端的全局时序

集群管理

  • 在分布式的集群中，经常会由于各种原因，比如硬件故障，软件故障，网络问题，有些节点会进进出出。有新的节点加入进来，也有老的节点退出集群。这个时候，集群中其他机器需要感知到这种变化，然后根据这种变化做出对应的决策。比如我们是一个分布式存储系统，有一个中央控制节点负责存储的分配，当有新的存储进来的时候我们要根据现在集群目前的状态来分配存储节点。这个时候我们就需要动态感知到集群目前的状态。还有，比如一个分布式的SOA架构中，服务是一个集群提供的，当消费者访问某个服务时，就需要采用某种机制发现现在有哪些节点可以提供该服务(这也称之为服务发现，比如Alibaba开源的SOA框架Dubbo就采用了Zookeeper作为服务发现的底层机制)。还有开源的Kafka队列就采用了Zookeeper作为Cosnumer的上下线管理。

zookeeper集群

  • 集群部署图： dock

Zookeeper的角色

  • 领导者（leader），负责进行投票的发起和决议，更新系统状态
  • 学习者（learner），包括跟随者（follower）和观察者（observer）
    • follower用于接受客户端请求并想客户端返回结果，在选主过程中参与投票
    • observer可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度
  • 客户端（client），请求发起方

Zookeeper选举

  • 集群中只要有超过过半的机器是正常工作的，那么整个集群对外就是可用的

  • 也就是说如果有2个zookeeper，那么只要有1个死了zookeeper就不能用了，因为1没有过半，所以2个zookeeper的死亡容忍度为0； 同理，要是有3个zookeeper，一个死了，还剩下2个正常的，过半了，所以3个zookeeper的容忍度为1，奇数个服务器是效率最高的。

  • ZooKeeper 集群服务器扮演了两个职能。它们一方面从客户端接受连接与操作请求，另一方面对操作结果进行投票。这两个职能在 ZooKeeper集群扩展的时候彼此制约。

    • 因为Leader节点必须等待集群中过半Server响应投票，于是节点的增加使得部分计算机运行较慢，从而拖慢整个投票过程的可能性也随之提高，写操作也会随之下降。这正是我们在实际操作中看到的问题——随着 ZooKeeper 集群变大，写操作的吞吐量会下降。

    • 我们不得不得在增加Client数量的期望和我们希望保持较好吞吐性能的期望间进行权衡。要打破这一耦合关系，我们引入了不参与投票的服务器，称为Observer。 Observer可以接受客户端的连接，并将写请求转发给Leader节点。但是，Observer不参与投票过程，只是和其他服务节点一起得到投票结果。

Zookeeper的读写机制

  • Zookeeper是一个由多个server组成的集群，一个leader,多个follower,每个server保存一份数据副本，全局数据一致，分布式读写，更新请求转发，由leader实施。

  • 一个client的更新请求按其发送顺序执行，数据更新原子性，一次数据更新要么全成功，要么失败，client无论连接哪个server,数据视图都是一致的.

Zookeeper节点数据操作流程

操作流程图：dock

  • 1.Client向Follwer发出一个写的请求
  • 2.Follwer把请求发送给Leader
  • 3.Leader接收到以后开始发起投票并通知Follwer进行投票
  • 4.Follwer把投票结果发送给Leader
  • 5.Leader将结果汇总后如果需要写入，则开始写入同时把写入操作通知给Leader，然后commit;
  • 6.Follwer把请求结果返回给Client

Follower主要有四个功能：

    1. 向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；
  • 2 .接收Leader消息并进行处理；
  • 3 .接收Client的请求，如果为写请求，发送给Leader进行投票；
  • 4 .返回Client结果。

zookeeper的设计目的

  • 最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。

  • 可靠性：具有简单、健壮、良好的性能，如果消息被到一台服务器接受，那么它将被所有的服务器接受。

  • 实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。

  • 等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。

  • 原子性：更新只能成功或者失败，没有中间状态。

  • 顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。

Last Updated:
Contributors: 88395515