Kafka 4.0 新架构详解(图文全面总结)

Kafka是大型架构核心，下面我详解Kafka 4.0新架构@mikechen

Kafka 4.0新架构

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

最大的变化只有一句话：

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

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

整体架构，如下所示：

             +----------------+
             | Controller     |
             | Quorum (Raft)  |
             +----------------+
                ↑    ↑    ↑
                |    |    |
+---------+  +---------+  +---------+
| Broker1 |  | Broker2 |  | Broker3 |
+---------+  +---------+  +---------+

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 元数据一致性系统。

整体架构，如下：

           +----------------------+
           | Controller Quorum    |
           |   (Raft Cluster)     |
           +----------------------+
              ↑      ↑      ↑

+---------+ +---------+ +---------+
| Broker1 | | Broker2 | | Broker3 |
+---------+ +---------+ +---------+

在 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”，变成“完全自治的分布式流平台”。