目录

第五章 使用Zookeeper

5.1 服务端部署与运行

5.2 客户端相关

5.2.1 客户端运行

5.2.2 客户端命令

5.3 Java客户端API

5.4 开源客户端

第六章 经典应用场景

6.1 典型应用场景及实现

6.1.1 数据发布/订阅（全局配置中心）

6.1.2 负载均衡（Load Balance）

6.1.3 命名服务

6.1.4 分布式协调/通知

6.1.5 集群管理

6.1.6 Master选举

6.1.7 分布式锁

6.1.8 分布式队列

6.2 Zk在大型分布式系统中的应用

6.2.1 Hadoop

6.2.2 HBase

6.2.3 Kafka

6.3 Zk在阿里的实践与应用

本章不是重点，粗略的介绍了下Zk的应用场景

第五章 使用Zookeeper

环境：Zk是基于Java语言编写的，因此运行环境需要Java环境的支持

5.1 服务端部署与运行

Zk有两种运行模式：单机模式与集群模式

Zk提供的可执行脚本

5.2 客户端相关

5.2.1 客户端运行

## 连接本地服务端
sh zkCli.sh

## 连接指定服务端
sh zkCli.sh -server ip:port

5.2.2 客户端命令

内容	命令	格式
创建	create	create [-s] [-e] path data acl -s或-e分别指定节点特性：顺序 或 临时。默认不加参数，创建的是持久节点
读取	ls	ls path [watch] 查看该节点下所有子节点
	get	get path [watch] 获取该节点下数据内容和属性信息
更新	set	set path data [version]
删除	delete	delete path [version]

5.3 Java客户端API

5.4 开源客户端

• ZkClient

• Curator

• 其他：zkui

---

第六章 经典应用场景

数据发布/订阅，负载均衡，命名服务，分布式协调/通知，集群管理，Master选举，分布式锁，分布式队列......

6.1 典型应用场景及实现

近年来很多分布式系统都以Zk为核心组件：

• Hadoop：用于高可用性（HA）配置中的名称节点选举和一些子项目的协调服务

• HBase：用于Region服务器的状态管理、元数据存储和Master服务器的选举

• Kafka：在早期版本中，用于集群管理、领导者选举、配置管理等。2.8.0后不再依赖Zk

• Dubbo：作为注册中心，管理服务的地址和配置信息

6.1.1 数据发布/订阅（全局配置中心）

• 即所谓的配置中心：发布者将数据发布到zk的一个或一系列节点上，订阅者进行数据订阅，动态获取数据。

  • 通常全局配置有以下特点

    • 数据量小

    • 运行时动态发生变化

    • 集群中各机器共享，配置一致

• 数据发布/订阅一般有两种设计模式：Push模式和Pull模式

  • Push：服务端主动将数据更新发送给订阅的客户端

  • Pull：客户端定时轮询，主动发请求拉取数

• Zk采用推拉结合的模式：客户端订阅需要关注的节点，一旦节点数据更变，服务端通过发生Watcher事件通知客户端，客户端再主动拉取

• Zk的实现方式

  • ①存储配置：在Zk上选取一个节点用于配置存储，如/app1/database_config

    • 

  • ②配置获取

    • 启动：集群中每台机器在启动初始化阶段，首先会从上面提到的Zk配置节点上读取该配置

    • 注册：同时在该配置节点上注册一个数据变更的Watcher监听。一旦数据发生变化，订阅的客户端能够得到通知

  • ③配置变更

    • 发生变更后，Zk会发送通知到各个客户端，客户端收到通知后拉取

6.1.2 负载均衡（Load Balance）

• 什么是负载均衡

  • 对多个计算机，网络连接，CPU，磁盘驱动器或其他资源进行分配负载，以达到优化资源使用，最大化吞吐率，最小化响应时间，避免过载的目的

  • 负载均衡分为两种

    • 硬件：直连交换机，比如F5，成本比较高

    • 软件：Zk是基于软件的

• 基于Zk实现的动态DNS方案（"DDNS"，Dynamic DNS）

6.1.3 命名服务

• 命名服务场景

  • 在分布式系统中，被命名的实体通常可以是集群中的机器、提供的服务地址或远程对象等。比较常见的就是一些分布式服务框架中的服务地址列表

  • 在分布式环境中，上层应用有时仅仅需要一个全局唯一的名字，类似数据库中的唯一主键

• Zk全局唯一ID命名的实现方式：通过Zk节点的顺序递增性质，获取全局唯一ID

  • 根据任务类型(type)，在该节点下创建顺序节点，获取全局唯一ID

  • 

6.1.4 分布式协调/通知

• 对于分布式机器而言，需要一个协调者(Coordinator)来控制整个系统的运行流程，如分布式事务的处理，机器间的相互协调等

• Zk通过让客户端对同一个数据节点进行Watcher注册，来实现不同系统间的协调，如果数据节点发生变化，会通知所有订阅的客户端

• 常用场景

  • 任务注册

  • 心跳检测

  • 系统调度

6.1.5 集群管理

集群管理包括两部分

• 集群监控：对整个集群运行时的状态信息收集，如：希望知道当前有多少台机器工作，每台机器运行时数据收集

• 集群控制：对集群的操作与控制，如：针对某台机器进行上下线操作

Zk做集群管理的两大优势

• 基于Watcher的订阅与监听特性

• Zk上的临时节点，一旦会话失效，临时节点会自动清除

6.1.6 Master选举

• 客户端集群每天都会定时往Zk上创建临时节点。在这个过程中，由于Zk原子性，只有一个客户端能创建成功，成功的即为Master
• 一旦Master挂了，通过Watcher机制，其余的客户端会重新选举

6.1.7 分布式锁

不赘述

6.1.8 分布式队列

不赘述，各类消息中间件已经很成熟了，不一定要用到Zk

6.2 Zk在大型分布式系统中的应用

6.2.1 Hadoop

6.2.2 HBase

6.2.3 Kafka

• 注：在 Kafka 的早期版本中，Kafka 是基于 ZooKeeper 的。从 Kafka 2.8.0 版本开始，Kafka 引入了 KRaft 模式（Kafka Raft Metadata mode）这是一个不依赖于 ZooKeeper 的元数据管理模式。在 KRaft 模式下，Kafka 可以使用自己的内部 Raft 实现来管理集群元数据，从而摆脱对 ZooKeeper 的依赖。

Zk在kafka的应用体现在以下几方面

• 管理所有Broker节点：所有Broker节点启动上线时，都会在（路径/brokers/ids）下进行注册创建属于自己的节点，并按ID排序

  • 例如/brokers/ids/1和/brokers/ids/2代表了两个Broker服务器

  • 创建完broker节点后，会把ip地址和端口写入该节点

  • 由于注册的是临时节点，Broker宕机或下线后会自动删除

• Topic注册

  • 每一个Topic都会记录在（路径/brokers/topics）下

    • 例如/brokers/topics/topic1和/brokers/topics/topic2代表了两个Topic

    • /brokers/topics/login/3->2，这个节点表明了 BrokerID=3的一个服务器，对于login的topic，提供了两个分区进行存储

• 生产者的负载均衡（如何将消息合理的发送到分布式Broker上）：Kafka提供了两种负载均衡方案

  • 传统的四层负载均衡：生产者IP地址和端口 —> 关联Broker

    • 优点：实现简单，生产者直接TCP维护到Broker

    • 缺点：写死，无法真正意义上的负载均衡，实际过程中，不同生产者的生产速率不一致

  • 基于Zk进行负载均衡：能实现动态负载均衡

• 消费者的负载均衡

6.3 Zk在阿里的实践与应用

• Metamorphosis：消息中间件

• Dubbo：RPC服务框架

• Canal：基于MySQL Binlog的增量订阅和消费组件

• ......