最近,confluent
社区发表了一篇文章,主要讲述了Kafka
未来的2.8
版本将要放弃Zookeeper
,这对于Kafka
用户来说,是一个重要的改进。之前部署Kafka
就必须得部署Zookeeper
,而之后就只要单独部署Kafka
就行了。[1]
1.Kafka简介
Apache Kafka
最早是由Linkedin
公司开发,后来捐献给了Apack
基金会。
Kafka
被官方定义为分布式流式处理平台,因为具备高吞吐、可持久化、可水平扩展等特性而被广泛使用。目前Kafka
具体如下功能:
- 消息队列,
Kafka
具有系统解耦、流量削峰、缓冲、异步通信等消息队列的功能。 - 分布式存储系统,
Kafka
可以把消息持久化,同时用多副本来实现故障转移,可以作为数据存储系统来使用。 - 实时数据处理,
Kafka
提供了一些和数据处理相关的组件,比如Kafka Streams
、Kafka Connect
,具备了实时数据的处理功能。
下面这张图是Kafka
的消息模型:[2]
通过上面这张图,介绍一下Kafka
中的几个主要概念:
-
producer
和consumer
: 消息队列中的生产者和消费者,生产者将消息推送到队列,消费者从队列中拉取消息。 -
consumer group
:消费者集合,这些消费者可以并行消费同一个topic
下不同partition
中的消息。 -
broker
:Kafka
集群中的服务器。 -
topic
:消息的分类。 -
partition
:topic
物理上的分组,一个topic
可以有partition
,每个partition
中的消息会被分配一个有序的id
作为offset
。每个consumer group
只能有一个消费者来消费一个partition
。
2.Kafka和Zookeeper关系
Kafka架构如下图:
Kafka
的工作需要Zookeeper
的配合。那他们到底是怎么配合工作呢?看下面这张图:
2.1 注册中心
2.1.1 broker注册
从上面的图中可以看到,broker
分布式部署,就需要一个注册中心来进行统一管理。Zookeeper
用一个专门节点保存Broker
服务列表,也就是 /brokers/ids
。
broker
在启动时,向Zookeeper
发送注册请求,Zookeeper
会在/brokers/ids
下创建这个broker
节点,如/brokers/ids/[0...N]
,并保存broker
的IP
地址和端口。
❝这个节点临时节点,一旦
❞broker
宕机,这个临时节点会被自动删除。
2.1.2 topic注册
Zookeeper
也会为topic
分配一个单独节点,每个topic
都会以/brokers/topics/[topic_name]
的形式记录在Zookeeper
。
一个topic
的消息会被保存到多个partition
,这些partition
跟broker
的对应关系也需要保存到Zookeeper
。
partition
是多副本保存的,上图中红色partition
是leader
副本。当leader
副本所在的broker发生故障时,partition
需要重新选举leader
,这个需要由Zookeeper
主导完成。
broker
启动后,会把自己的Broker ID
注册到到对应topic
节点的分区列表中。
我们查看一个topic
是xxx
,分区编号是1
的信息,命令如下:
[root@master] get /brokers/topics/xxx/partitions/1/state
{"controller_epoch":15,"leader":11,"version":1,"leader_epoch":2,"isr":[11,12,13]}
❝当
❞broker
退出后,Zookeeper
会更新其对应topic
的分区列表。
2.1.3 consumer注册
消费者组也会向Zookeeper
进行注册,Zookeeper
会为其分配节点来保存相关数据,节点路径为/consumers/{group_id}
,有3
个子节点,如下图:
Zookeeper
可以记录分区跟消费者的关系,以及分区的offset
。[3]2.2 负载均衡
broker
向Zookeeper
进行注册后,生产者根据broker
节点来感知broker
服务列表变化,这样可以实现动态负载均衡。
consumer group
中的消费者,可以根据topic
节点信息来拉取特定分区的消息,实现负载均衡。
❝实际上,
Kafka
在Zookeeper
中保存的元数据非常多,看下面这张图:随着broker、topic和partition增多,保存的数据量会越来越大。 ❞
3.Controller介绍
经过上一节的讲述,我们看到了Kafka
对Zookeeper
的依赖非常大,Kafka
离开Zookeeper
是没有办法独立运行的。那Kafka
是怎么跟Zookeeper
进行交互的呢?
如下图:[4]
Kafka
集群中会有一个broker
被选举为Controller
负责跟Zookeeper
进行交互,它负责管理整个Kafka
集群中所有分区和副本的状态。其他broker
监听Controller
节点的数据变化。Controller
的选举工作依赖于Zookeeper
,选举成功后,Zookeeper
会创建一个/controller
临时节点。
Controller
具体职责如下:
- 监听分区变化
❝比如当某个分区的leader出现故障时,Controller会为该分区选举新的leader。当检测到分区的ISR集合发生变化时,Controller会通知所有broker更新元数据。当某个topic增加分区时,Controller会负责重新分配分区。
❞
- 监听
topic
相关的变化 - 监听
broker
相关的变化 - 集群元数据管理
下面这张图展示了Controller、Zookeeper和broker的交互细节:
Controller
选举成功后,会从Zookeeper
集群中拉取一份完整的元数据初始化ControllerContext
,这些元数据缓存在Controller
节点。当集群发生变化时,比如增加topic
分区,Controller
不仅需要变更本地的缓存数据,还需要将这些变更信息同步到其他Broker
。Controller
监听到Zookeeper
事件、定时任务事件和其他事件后,将这些事件按照先后顺序暂存到LinkedBlockingQueue
中,由事件处理线程按顺序处理,这些处理多数需要跟Zookeeper
交互,Controller
则需要更新自己的元数据。
4.Zookeeper带来的问题
Kafka
本身就是一个分布式系统,但是需要另一个分布式系统来管理,复杂性无疑增加了。
4.1 运维复杂度
使用了Zookeeper
,部署Kafka
的时候必须要部署两套系统,Kafka
的运维人员必须要具备Zookeeper
的运维能力。
4.2 Controller故障处理
Kafaka
依赖一个单一Controller
节点跟Zookeeper
进行交互,如果这个Controller
节点发生了故障,就需要从broker
中选择新的Controller
。如下图,新的Controller
变成了broker3
。
新的Controller
选举成功后,会重新从Zookeeper
拉取元数据进行初始化,并且需要通知其他所有的broker
更新ActiveControllerId
。老的Controller
需要关闭监听、事件处理线程和定时任务。分区数非常多时,这个过程非常耗时,而且这个过程中Kafka
集群是不能工作的。
4.3 分区瓶颈
当分区数增加时,Zookeeper
保存的元数据变多,Zookeeper
集群压力变大,达到一定级别后,监听延迟增加,给Kafaka
的工作带来了影响。
所以,Kafka
单集群承载的分区数量是一个瓶颈。而这又恰恰是一些业务场景需要的。
5.升级
升级前后的架构图对比如下:
KIP-500
用Quorum Controller
代替之前的Controller
,Quorum
中每个Controller
节点都会保存所有元数据,通过KRaft
协议保证副本的一致性。这样即使Quorum Controller
节点出故障了,新的Controller
迁移也会非常快。
官方介绍,升级之后,Kafka
可以轻松支持百万级别的分区。
❝Kafak团队把通过Raft协议同步数据的方式Kafka Raft Metadata mode,简称KRaft
❞
Kafka
的用户体量非常大,在不停服的情况下升级是必要的。
目前去除Zookeeper
的Kafka
代码KIP-500
已经提交到trunk
分支,并且已经在的2.8
版本发布。
Kafaka
计划在3.0
版本会兼容Zookeeper Controller
和Quorum Controller
,这样用户可以进行灰度测试。[5]
6.总结
在大规模集群和云原生的背景下,使用Zookeeper
给Kafka
的运维和集群性能造成了很大的压力。去除Zookeeper
是必然趋势,这也符合大道至简的架构思想。
Reference
[1]参考1: https://www.confluent.io/blog/kafka-without-zookeeper-a-sneak-peek/
[2]参考2: https://blog.csdn.net/Zidingyi_367/article/details/110490910
[3]参考3: https://www.jianshu.com/p/a036405f989c
[4]参考4: https://honeypps.com/mq/kafka-controller-analysis/
[5]参考5: https://mp.weixin.qq.com/s/ev6NM6hptltQBuTaCHJCQQ
本文使用 文章同步助手 同步