Kafka为什么要放弃Zookeeper-CSDN博客

Kafka被官方定义为分布式流式处理平台，因为具备高吞吐、可持久化、可水平扩展等特性而被广泛使用。

Kafka功能：

消息队列,Kafka具有系统解耦、流量削峰、缓冲、异步通信等消息队列的功能。
分布式存储系统，Kafka可以把消息持久化，同时用多副本来实现故障转移，可以作为数据存储系统来使用。
实时数据处理，Kafka提供了一些和数据处理相关的组件，比如Kafka Streams、Kafka Connect，具备了实时数据的处理功能。

KAFKA核心概念

producer和consumer: 消息队列中的生产者和消费者，生产者将消息推送到队列，消费者从队列中拉取消息。
consumer group，消费者集合，这些消费者可以并行消费同一个topic下不同partition中的消息。
broker：Kafka集群中的服务器叫做broker。
topic：消息的分类。
partition：topic物理上的分组
- 一个topic可以有多个partition
- 每个partition中的消息会被分配一个有序的id作为offset。
- 并且每个partition只能给某个consumer group的一个消费者消费。

Kafka 和 Zookeeper 关系

Kafka 架构如下图：

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

看下面这张图：

1 、注册中心

1.1 broker 注册

broker分布式部署，就需要一个注册中心来进行统一管理。

Zookeeper用一个专门节点保存Broker服务列表，也就是 /brokers/ids。

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

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

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的分区列表。

1.3 consumer 注册

消费者组也会向Zookeeper进行注册，Zookeeper会为其分配节点来保存相关数据，节点路径为/consumers/{group_id}，有3个子节点，如下图:这样Zookeeper可以记录分区跟消费者的关系，以及分区的offset。

2 负载均衡

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

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

实际上，Kafka在Zookeeper中保存的元数据非常多，看下面这张图：随着 broker、topic 和 partition 增多，保存的数据量会越来越大。

3.Controller 介绍

经过上一节的讲述，我们看到了Kafka对Zookeeper的依赖非常大，Kafka离开Zookeeper是没有办法独立运行的。那Kafka是怎么跟Zookeeper进行交互的呢？

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 带来的问题

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

4.2 Controller 故障处理

Kafaka依赖一个单一Controller节点跟Zookeeper进行交互，如果这个Controller节点发生了故障，就需要从broker中选举新的Controller。例如，新的Controller从Broker1成了Broker3。

新的Controller选举成功后，会重新从Zookeeper拉取元数据进行初始化。

并且需要通知其他所有的broker更新ActiveControllerId。

老的Controller需要关闭监听、事件处理线程和定时任务。

分区数非常多时，这个过程非常耗时，而且这个过程中Kafka集群是不能工作的。

Zookeeper作为分布式系统，本身就是遵循CP原则。不具备高可用的特性。

4.3 分区瓶颈

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

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

5.升级

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

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

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