Kafka 4.0 新架构详解

Kafka 4.0新架构#

Kafka 4.0 是 Kafka 十多年发展中的一次“架构级”升级。

最大的变化只有一句话：

Kafka 正式彻底移除 ZooKeeper，全面进入 KRaft 时代。

这是 Kafka 从“依赖外部协调系统”，走向“自身完整分布式元数据架构”的关键转折。

整体架构，如下所示：

1
+----------------+
2
|Controller|
3
|Quorum(Raft)|
4
+----------------+
5
↑↑↑
6
|||
7
+---------++---------++---------+
8
|Broker1||Broker2||Broker3|
9
+---------++---------++---------+

Kafka 4.0 的核心新架构是全面默认采用 KRaft 模式，彻底移除 ZooKeeper，使 Kafka 成为完全自洽的分布式系统 。

KRaft架构#

在以往的 大规模生产实践中，ZooKeeper模式暴露了三大致命痛点：

元数据同步瓶颈：随着集群规模和 Topic/Partition 数量激增（达万级以上）。

ZK 的写性能随节点增加而下降，元数据同步延迟甚至可达秒级。

“惊群效应”与脑裂风险：当集群控制器（Controller）发生变更时，ZK 需要向所有 Broker 广播变更，容易导致极端情况下的集群不可用。

在 4.0 版本中，ZooKeeper 模式被完全移除，且不再支持从 ZK 的向后兼容迁移。

这意味着 Kafka 彻底转向了纯 KRaft（Kafka Raft） 架构。

KRaft，就是：Kafka + Raft，本质：Kafka 内部实现了一套：Raft 元数据一致性系统。

整体架构，如下：

1
+----------------------+
2
|ControllerQuorum|
3
|(RaftCluster)|
4
+----------------------+
5
↑↑↑
6

7
+---------++---------++---------+
8
|Broker1||Broker2||Broker3|
9
+---------++---------++---------+

在 KRaft 架构下，集群中的节点角色被清晰地划分为两类（通过 process.roles 配置）

• Broker 角色：只负责纯粹的数据读写（Data Plane），不参与集群维度的决策

• Controller 角色：负责管理集群元数据、分区状态及 Leader 选举（Control Plane）

• 混合角色（Broker, Controller）：在小规模集群中，一个节点可以同时兼任两种角色

这些 Controller 节点，共同组成了一个 Metadata Quorum（元数据法定人数集群），它们不再依赖外部第三方组件，而是直接使用 Kafka 内部优化过的 Raft 协议来保证强一致性

整体对比，如下：

总之，Kafka 4.0 自己实现了一套 Raft 元数据系统，也就是：Kafka + Raft

让 Kafka 从“依赖 ZooKeeper”，变成“完全自治的分布式流平台”