《从Paxos到Zookeeper》——第五、六章：经典应用场景

目录

第五章使用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进行负载均衡：能实现动态负载均衡
消费者的负载均衡