A box of chocolate

一、前言 在学习了Zookeeper相关的理论知识后，下面接着学习对Zookeeper的相关操作。 二、Zookeeper部署 Zookeeper的部署相对来说还是比较简单，读者可以在网上找到相应的教程，点这里，笔者不再累赘。 Zookeeper有三种运行形式：集群模式、单机模式、伪集群模式。 以下实验都是在单机模式下进行。 三、服务端 　　bin目录下常用的脚本解释 zkCleanup　　清理Zookeeper历史数据，包括食物日志文件和快照数据文件 zkCli　　　　  Zookeeper的一个简易客户端 zkEnv　　　　设置Zookeeper的环境变量 zkServer　　   Zookeeper服务器的启动、停止、和重启脚本 3.1 运行服务 进入bin目录，使用zkServer.sh start启动服务 使用jps命令查看，存在QuorumPeerMain进程，表示Zookeeper已经启动 3.2 停止服务 在bin目录下，使用zkServer.sh stop停止服务 使用jps命令查看，QuorumPeerMain进程已不存在，表示Zookeeper已经关闭...

一、前言 上一篇博客我们通过命令行来操作Zookeper的客户端和服务端并进行相应的操作，这篇主要介绍如何通过API（JAVA）来操作Zookeeper。 二、开发环境配置 首先打开Zookeeper服务端（上一篇博客有具体的方法），方便客户端连接。 配置开发环境环境可以有两种方式：① 直接下载相关的依赖Jar包，然后在IDE中添加依赖 ② 建立maven项目，使用maven进行依赖管理。 ① 手动添加依赖至IDE 步骤一：点击这里下载对应版本的Jar包，包括（jar、javadoc.jar、sources.jar），笔者对应下载的Zookeeper3.4.6版本。 步骤二：打开IDE（笔者使用eclispe），新建名为zookeeper_examples_none_maven的java项目。由于需要单独添加依赖，为了方便管理，笔者在项目下新建了jar文件夹，用于存放本项目的jar包（将步骤一下载的3个jar包存放至此文件夹下）。 步骤三：在eclipse中添加依赖 步骤四：新建包、Java类进行测试 Zookeeper_Constructor_Usage_Simple.java package com.hust.grid.leesf.examples; import java.io.IOException; import java.util.concurrent.CountDownLatch; import org.apache.zookeeper.WatchedEvent; import org.apache.zookeeper.Watcher;...

一、前言 上一篇博客已经介绍了如何使用Zookeeper提供的原生态Java API进行操作，本篇博文主要讲解如何通过开源客户端来进行操作。 二、ZkClient ZkClient是在Zookeeper原声API接口之上进行了包装，是一个更易用的Zookeeper客户端，其内部还实现了诸如Session超时重连、Watcher反复注册等功能。 2.1 添加依赖 在pom.xml文件中添加如下内容即可。 <dependency> <groupId>com.101tec</groupId> <artifactId>zkclient</artifactId> <version>0.2</version> </dependency> 2.2 创建会话 使用ZkClient可以轻松的创建会话，连接到服务端。 package com.hust.grid.leesf.zkclient.examples; import java.io.IOException; import org.I0Itec.zkclient.ZkClient; public class Create_Session_Sample...

一、前言 在上一篇博客已经介绍了Zookeeper开源客户端的简单实用，本篇讲解Zookeeper的应用场景。 二、典型应用场景 Zookeeper是一个高可用的分布式数据管理和协调框架，并且能够很好的保证分布式环境中数据的一致性。在越来越多的分布式系统（Hadoop、HBase、Kafka）中，Zookeeper都作为核心组件使用。 2.1 数据发布/订阅 数据发布/订阅系统，即配置中心。需要发布者将数据发布到Zookeeper的节点上，供订阅者进行数据订阅，进而达到动态获取数据的目的，实现配置信息的集中式管理和数据的动态更新。发布/订阅一般有两种设计模式：推模式和拉模式，服务端主动将数据更新发送给所有订阅的客户端称为推模式；客户端主动请求获取最新数据称为拉模式，Zookeeper采用了推拉相结合的模式，客户端向服务端注册自己需要关注的节点，一旦该节点数据发生变更，那么服务端就会向相应的客户端推送Watcher事件通知，客户端接收到此通知后，主动到服务端获取最新的数据。 若将配置信息存放到Zookeeper上进行集中管理，在通常情况下，应用在启动时会主动到Zookeeper服务端上进行一次配置信息的获取，同时，在指定节点上注册一个Watcher监听，这样在配置信息发生变更，服务端都会实时通知所有订阅的客户端，从而达到实时获取最新配置的目的。 2.2 负载均衡 负载均衡是一种相当常见的计算机网络技术，用来对多个计算机、网络连接、CPU、磁盘驱动或其他资源进行分配负载，以达到优化资源使用、最大化吞吐率、最小化响应时间和避免过载的目的。 使用Zookeeper实现动态DNS服务 · 域名配置，首先在Zookeeper上创建一个节点来进行域名配置，如DDNS/app1/server.app1.company1.com。 · 域名解析，应用首先从域名节点中获取IP地址和端口的配置，进行自行解析。同时，应用程序还会在域名节点上注册一个数据变更Watcher监听，以便及时收到域名变更的通知。 · 域名变更，若发生IP或端口号变更，此时需要进行域名变更操作，此时，只需要对指定的域名节点进行更新操作，Zookeeper就会向订阅的客户端发送这个事件通知，客户端之后就再次进行域名配置的获取。 2.3 命名服务 命名服务是分步实现系统中较为常见的一类场景，分布式系统中，被命名的实体通常可以是集群中的机器、提供的服务地址或远程对象等，通过命名服务，客户端可以根据指定名字来获取资源的实体、服务地址和提供者的信息。Zookeeper也可帮助应用系统通过资源引用的方式来实现对资源的定位和使用，广义上的命名服务的资源定位都不是真正意义上的实体资源，在分布式环境中，上层应用仅仅需要一个全局唯一的名字。Zookeeper可以实现一套分布式全局唯一ID的分配机制。 通过调用Zookeeper节点创建的API接口就可以创建一个顺序节点，并且在API返回值中会返回这个节点的完整名字，利用此特性，可以生成全局ID，其步骤如下 1. 客户端根据任务类型，在指定类型的任务下通过调用接口创建一个顺序节点，如”job-“。 2....

一、前言 上一篇博文讲解了Zookeeper的典型应用场景，在大数据时代，各种分布式系统层出不穷，其中，有很多系统都直接或间接使用了Zookeeper，用来解决诸如配置管理、分布式通知/协调、集群管理和Master选举等一系列分布式问题。 二、 Hadoop Hadoop的核心是HDFS（Hadoop Distributed File System）和MapReduce，分别提供了对海量数据的存储和计算能力，后来，Hadoop又引入了全新MapReduce框架YARN（Yet Another Resource Negotiator）。在Hadoop中，Zookeeper主要用于实现HA（High Availability），这部分逻辑主要集中在Hadoop Common的HA模块中，HDFS的NameNode与YARN的ResourceManager都是基于此HA模块来实现自己的HA功能，YARN又使用了Zookeeper来存储应用的运行状态。 YARN YARN是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。其可以支持MapReduce模型，同时也支持Tez、Spark、Storm、Impala、Open MPI等。 YARN主要由ResourceManager（RM）、NodeManager（NM）、ApplicationManager（AM）、Container四部分构成。其中，ResourceManager为全局资源管理器，负责整个系统的资源管理和分配。由YARN体系架构可以看到ResourceManager的单点问题，ResourceManager的工作状况直接决定了整个YARN架构是否可以正常运转。 ResourceManager HA 为了解决ResourceManager的单点问题，YARN设计了一套Active/Standby模式的ResourceManager HA架构。 由上图可知，在运行期间，会有多个ResourceManager并存，并且其中只有一个ResourceManager处于Active状态，另外一些（允许一个或者多个）则处于Standby状态，当Active节点无法正常工作时，其余处于Standby状态的节点则会通过竞争选举产生新的Active节点。 主备切换...

一、前言 前面已经讲解了Zookeeper的一些应用场景，但是并没有深入到Zookeeper内部进行分析，本篇将讲解其系统模型。 二、系统模型 2.1 数据模型 Zookeeper的数据节点称为ZNode，ZNode是Zookeeper中数据的最小单元，每个ZNode都可以保存数据，同时还可以挂载子节点，因此构成了一个层次化的命名空间，称为树。 在Zookeeper中，事务是指能够改变Zookeeper服务器状态的操作，一般包括节点创建与删除，数据节点内容更新和客户端会话创建与失效，对于每个事务请求，Zookeeper都会为其分配一个全局唯一的事务ID，用ZXID表示，通常是64位的数字，每个ZXID对应一次更新操作，从这些ZXID中可以间接地识别出Zookeeper处理这些更新操作请求的全局顺序。 2.2 节点特性 在Zookeeper中，每个数据节点都是由生命周期的，类型不同则会不同的生命周期，节点类型可以分为持久节点（PERSISTENT）、临时节点（EPHEMERAL）、顺序节点（SEQUENTIAL）三大类，可以通过组合生成如下四种类型节点 1. 持久节点（PERSISTENT）。节点创建后便一直存在于Zookeeper服务器上，直到有删除操作来主动清楚该节点。 2. 持久顺序节点（PERSISTENT_SEQUENTIAL）。相比持久节点，其新增了顺序特性，每个父节点都会为它的第一级子节点维护一份顺序，用于记录每个子节点创建的先后顺序。在创建节点时，会自动添加一个数字后缀，作为新的节点名，该数字后缀的上限是整形的最大值。 3. 临时节点（EPEMERAL）。临时节点的生命周期与客户端会话绑定，客户端失效，节点会被自动清理。同时，Zookeeper规定不能基于临时节点来创建子节点，即临时节点只能作为叶子节点。 4. 临时顺序节点（EPEMERAL_SEQUENTIAL）。在临时节点的基础添加了顺序特性。 每个节点除了存储数据外，还存储了节点本身的一些状态信息，可通过get命令获取。 2.3 版本–保证分布式数据原子性操作 每个数据节点都具有三种类型的版本信息，对数据节点的任何更新操作都会引起版本号的变化。 version– 当前数据节点数据内容的版本号 cversion– 当前数据子节点的版本号 aversion– 当前数据节点ACL变更版本号 上述各版本号都是表示修改次数，如version为1表示对数据节点的内容变更了一次。即使前后两次变更并没有改变数据内容，version的值仍然会改变。version可以用于写入验证，类似于CAS。...

一、前言 前面介绍了Zookeeper的系统模型，下面进一步学习Zookeeper的底层序列化机制，Zookeeper的客户端与服务端之间会进行一系列的网络通信来实现数据传输，Zookeeper使用Jute组件来完成数据的序列化和反序列化操作。 二、Jute Jute是Zookeeper底层序列化组件，其用于Zookeeper进行网络数据传输和本地磁盘数据存储的序列化和反序列化工作。 2.1 Jute序列化 MockReHeader实体类 package com.hust.grid.leesf.jute.examples; import org.apache.jute.InputArchive; import org.apache.jute.OutputArchive; import org.apache.jute.Record; public class MockReHeader implements Record { private long sessionId; private...

一、前言 前篇博客分析了Zookeeper的序列化和通信协议，接着继续学习客户端，客户端是开发人员使用Zookeeper最主要的途径，很有必要弄懂客户端是如何与服务端通信的。 二、客户端 2.1 客户端组成 Zookeeper客户端主要由如下核心部件构成。 1. Zookeeper实例，客户端入口。 2. ClientWatchManager， 客户端Watcher管理器。 3. HostProvider，客户端地址列表管理器。 4. ClientCnxn，客户端核心线程，内部包含了SendThread和EventThread两个线程，SendThread为I/O线程，主要负责Zookeeper客户端和服务器之间的网络I/O通信；EventThread为事件线程，主要负责对服务端事件进行处理。 　　Zookeeper客户端初始化与启动环节，就是Zookeeper对象的实例化过程。客户端在初始化和启动过程中大体可以分为如下3个步骤 1. 设置默认Watcher 2. 设置Zookeeper服务器地址列表 3. 创建ClientCnxn。 若在Zookeeper构造方法中传入Watcher对象时，那么Zookeeper就会将该Watcher对象保存在ZKWatcherManager的defaultWatcher中，并作为整个客户端会话期间的默认Watcher。 2.2 会话的创建 下图表示了客户端与服务端会话建立的整个过程，包括初始化阶段（第一阶段）、会话创建阶段（第二阶段）、响应处理阶段（第三阶段）三个阶段。 2.3 服务器地址列表 在实例化Zookeeper时，用户传入Zookeeper服务器地址列表，如192.168.0.1:2181,192.168.0.2:2181,192.168.0.3:2181，此时，Zookeeper客户端在连接服务器的过程中，是如何从这个服务器列表中选择服务器的呢？Zookeeper收到服务器地址列表后，会解析出chrootPath和保存服务器地址列表。...

一、前言 前面分析了Zookeeper客户端的细节，接着继续学习Zookeeper中的一个非常重要的概念：会话。 二、会话 客户端与服务端之间任何交互操作都与会话息息相关，如临时节点的生命周期、客户端请求的顺序执行、Watcher通知机制等。Zookeeper的连接与会话就是客户端通过实例化Zookeeper对象来实现客户端与服务端创建并保持TCP连接的过程. 2.1 会话状态 在Zookeeper客户端与服务端成功完成连接创建后，就创建了一个会话，Zookeeper会话在整个运行期间的生命周期中，会在不同的会话状态中之间进行切换，这些状态可以分为CONNECTING、CONNECTED、RECONNECTING、RECONNECTED、CLOSE等。 一旦客户端开始创建Zookeeper对象，那么客户端状态就会变成CONNECTING状态，同时客户端开始尝试连接服务端，连接成功后，客户端状态变为CONNECTED，通常情况下，由于断网或其他原因，客户端与服务端之间会出现断开情况，一旦碰到这种情况，Zookeeper客户端会自动进行重连服务，同时客户端状态再次变成CONNCTING，直到重新连上服务端后，状态又变为CONNECTED，在通常情况下，客户端的状态总是介于CONNECTING和CONNECTED之间。但是，如果出现诸如会话超时、权限检查或是客户端主动退出程序等情况，客户端的状态就会直接变更为CLOSE状态。 2.2 会话创建 Session是Zookeeper中的会话实体，代表了一个客户端会话，其包含了如下四个属性 1. sessionID。会话ID，唯一标识一个会话，每次客户端创建新的会话时，Zookeeper都会为其分配一个全局唯一的sessionID。 2. TimeOut。会话超时时间，客户端在构造Zookeeper实例时，会配置sessionTimeout参数用于指定会话的超时时间，Zookeeper客户端向服务端发送这个超时时间后，服务端会根据自己的超时时间限制最终确定会话的超时时间。 3. TickTime。下次会话超时时间点，为了便于Zookeeper对会话实行”分桶策略”管理，同时为了高效低耗地实现会话的超时检查与清理，Zookeeper会为每个会话标记一个下次会话超时时间点，其值大致等于当前时间加上TimeOut。 4. isClosing。标记一个会话是否已经被关闭，当服务端检测到会话已经超时失效时，会将该会话的isClosing标记为”已关闭”，这样就能确保不再处理来自该会话的心情求了。 Zookeeper为了保证请求会话的全局唯一性，在SessionTracker初始化时，调用initializeNextSession方法生成一个sessionID，之后在Zookeeper运行过程中，会在该sessionID的基础上为每个会话进行分配，初始化算法如下 public static long initializeNextSession(long id) { long nextSid =...

一、前言 前面已经了解了Zookeeper会话相关知识点，接着来学习Zookeeper服务端相关细节。 二、服务端 服务端整体架构如下 Zookeeper服务器的启动，大致可以分为以下五个步骤 1. 配置文件解析。 2. 初始化数据管理器。 3. 初始化网络I/O管理器。 4. 数据恢复。 5. 对外服务。 2.1 单机版服务器启动 单机版服务器的启动其流程图如下 上图的过程可以分为预启动和初始化过程。 1. 预启动 1. 统一由QuorumPeerMain作为启动类。无论单机或集群，在zkServer.cmd和zkServer.sh中都配置了QuorumPeerMain作为启动入口类。 2. 解析配置文件zoo.cfg。zoo.cfg配置运行时的基本参数，如tickTime、dataDir、clientPort等参数。...