Kafka能有什么坏心思,不过是被Zookeeper害惨了……

jinjunzhu 2021-05-20 09:47:36
最近,confluent社区发表了一篇文章,主要讲述了Kafka未来的2.8版本将要放弃Zookeeper,这对于Kafka用户来说,是一个重要的改进。之前部署Kafka就必须得部署Zookeeper,而之后就只要单独部署Kafka就行了。[1]

 

一、Kafka简介

 

Apache Kafka最早是由Linkedin公司开发,后来捐献给了Apack基金会。

 

Kafka被官方定义为分布式流式处理平台,因为具备高吞吐、可持久化、可水平扩展等特性而被广泛使用。目前Kafka具体如下功能:

 

  • 消息队列,Kafka具有系统解耦、流量削峰、缓冲、异步通信等消息队列的功能。

  • 分布式存储系统,Kafka可以把消息持久化,同时用多副本来实现故障转移,可以作为数据存储系统来使用。

 

  • 实时数据处理,Kafka提供了一些和数据处理相关的组件,比如Kafka Streams、Kafka Connect,具备了实时数据的处理功能。

 

下面这张图是Kafka的消息模型:[2]

 

 

通过上面这张图,介绍一下Kafka中的几个主要概念:

 

  • producerconsumer消息队列中的生产者和消费者,生产者将消息推送到队列,消费者从队列中拉取消息。
     

  • consumer group:消费者集合,这些消费者可以并行消费同一个topic下不同partition中的消息。
     

  • broker:Kafka集群中的服务器。

 

  • topic:消息的分类。

 

  • partition:topic物理上的分组,一个topic可以有partition,每个partition中的消息会被分配一个有序的id作为offset。每个consumer group只能有一个消费者来消费一个partition。

 

二、Kafka和Zookeeper关系

 

Kafka架构如下图:

 

 

从图中可以看到,Kafka的工作需要Zookeeper的配合。那他们到底是怎么配合工作呢?

 

看下面这张图:

 

 

 
1、注册中心

 

1)broker注册

 

从上面的图中可以看到,broker分布式部署,就需要一个注册中心来进行统一管理。Zookeeper用一个专门节点保存Broker服务列表,也就是 /brokers/ids

 

broker在启动时,向Zookeeper发送注册请求,Zookeeper会在/brokers/ids下创建这个broker节点,如/brokers/ids/[0...N],并保存broker的IP地址和端口。

 

这个节点临时节点,一旦broker宕机,这个临时节点会被自动删除。

 

2) topic注册

 

Zookeeper也会为topic分配一个单独节点,每个topic都会以/brokers/topics/[topic_name]的形式记录在Zookeeper。

 

一个topic的消息会被保存到多个partition,这些partitionbroker的对应关系也需要保存到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的分区列表。

 

3)consumer注册

 

消费者组也会向Zookeeper进行注册,Zookeeper会为其分配节点来保存相关数据,节点路径为/consumers/{group_id},有3个子节点,如下图:

 

 

这样Zookeeper可以记录分区跟消费者的关系,以及分区的offset。[3]

 

 
2、负载均衡

 

broker向Zookeeper进行注册后,生产者根据broker节点来感知broker服务列表变化,这样可以实现动态负载均衡。

 

consumer group中的消费者,可以根据topic节点信息来拉取特定分区的消息,实现负载均衡。

 

实际上,Kafka在Zookeeper中保存的元数据非常多,看下面这张图:

 

 

随着broker、topicpartition增多,保存的数据量会越来越大。

 

三、Controller介绍

 

经过上一节的讲述,我们看到了KafkaZookeeper的依赖非常大,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、Zookeeperbroker的交互细节:

 

 

Controller选举成功后,会从Zookeeper集群中拉取一份完整的元数据初始化ControllerContext,这些元数据缓存在Controller节点。当集群发生变化时,比如增加topic分区,Controller不仅需要变更本地的缓存数据,还需要将这些变更信息同步到其他Broker

 

Controller监听到Zookeeper事件、定时任务事件和其他事件后,将这些事件按照先后顺序暂存到LinkedBlockingQueue中,由事件处理线程按顺序处理,这些处理多数需要跟Zookeeper交互,Controller则需要更新自己的元数据。

 

四、Zookeeper带来的问题

 

Kafka本身就是一个分布式系统,但是需要另一个分布式系统来管理,复杂性无疑增加了。

 

 
1、运维复杂度

 

使用了Zookeeper,部署Kafka的时候必须要部署两套系统,Kafka的运维人员必须要具备Zookeeper的运维能力。

 

 
2、Controller故障处理

 

Kafka依赖一个单一Controller节点跟Zookeeper进行交互,如果这个Controller节点发生了故障,就需要从broker中选择新的Controller。如下图,新的Controller变成了broker3

 

 

新的Controller选举成功后,会重新从Zookeeper拉取元数据进行初始化,并且需要通知其他所有的broker更新ActiveControllerId。老的Controller需要关闭监听、事件处理线程和定时任务。分区数非常多时,这个过程非常耗时,而且这个过程中Kafka集群是不能工作的。

 

 
3、分区瓶颈

 

当分区数增加时,Zookeeper保存的元数据变多,Zookeeper集群压力变大,达到一定级别后,监听延迟增加,给Kafka的工作带来了影响。

 

所以,Kafka单集群承载的分区数量是一个瓶颈。而这又恰恰是一些业务场景需要的。

 

五、升级

 

升级前后的架构图对比如下:

 

 

KIP-500Quorum Controller代替之前的ControllerQuorum中每个Controller节点都会保存所有元数据,通过KRaft协议保证副本的一致性。这样即使Quorum Controller节点出故障了,新的Controller迁移也会非常快。

 

官方介绍,升级之后,Kafka可以轻松支持百万级别的分区。

 

Kafak团队把通过Raft协议同步数据的方式Kafka Raft Metadata mode,简称KRaft

 

Kafka的用户体量非常大,在不停服的情况下升级是必要的。

 

目前去除ZookeeperKafka代码KIP-500已经提交到trunk分支,并且已经在的2.8版本发布。

 

Kafka计划在3.0版本会兼容Zookeeper ControllerQuorum Controller,这样用户可以进行灰度测试。[5]

 

六、总结

 

在大规模集群和云原生的背景下,使用ZookeeperKafka的运维和集群性能造成了很大的压力。去除Zookeeper是必然趋势,这也符合大道至简的架构思想。

>>>>


参考资料

 

[1]https://www.confluent.io/blog/kafka-without-zookeeper-a-sneak-peek/

[2]https://blog.csdn.net/Zidingyi_367/article/details/110490910

[3]https://www.jianshu.com/p/a036405f989c

[4]https://honeypps.com/mq/kafka-controller-analysis/

[5]https://mp.weixin.qq.com/s/ev6NM6hptltQBuTaCHJCQQ

 

作者丨jinjunzhu
来源丨公众号:程序员jinjunzhu(ID:gh_1f109b82d301)
dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn
最新评论
访客 2023年08月20日

230721

访客 2023年08月16日

1、导入Mongo Monitor监控工具表结构(mongo_monitor…

访客 2023年08月04日

上面提到: 在问题描述的架构图中我们可以看到,Click…

访客 2023年07月19日

PMM不香吗?

访客 2023年06月20日

如今看都很棒

活动预告