目录
本章不是重点,粗略的介绍了下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
|
读取 |
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的增量订阅和消费组件
......