目录
[第五章 使用Zookeeper](#第五章 使用Zookeeper)
[5.1 服务端部署与运行](#5.1 服务端部署与运行)
[5.2 客户端相关](#5.2 客户端相关)
[5.2.1 客户端运行](#5.2.1 客户端运行)
[5.2.2 客户端命令](#5.2.2 客户端命令)
[5.3 Java客户端API](#5.3 Java客户端API)
[5.4 开源客户端](#5.4 开源客户端)
[第六章 经典应用场景](#第六章 经典应用场景)
[6.1 典型应用场景及实现](#6.1 典型应用场景及实现)
[6.1.1 数据发布/订阅（全局配置中心）](#6.1.1 数据发布/订阅（全局配置中心）)
[6.1.2 负载均衡（Load Balance）](#6.1.2 负载均衡（Load Balance）)
[6.1.3 命名服务](#6.1.3 命名服务)
[6.1.4 分布式协调/通知](#6.1.4 分布式协调/通知)
[6.1.5 集群管理](#6.1.5 集群管理)
[6.1.6 Master选举](#6.1.6 Master选举)
[6.1.7 分布式锁](#6.1.7 分布式锁)
[6.1.8 分布式队列](#6.1.8 分布式队列)
[6.2 Zk在大型分布式系统中的应用](#6.2 Zk在大型分布式系统中的应用)
[6.2.1 Hadoop](#6.2.1 Hadoop)
[6.2.2 HBase](#6.2.2 HBase)
[6.2.3 Kafka](#6.2.3 Kafka)
[6.3 Zk在阿里的实践与应用](#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的增量订阅和消费组件
-
......