1 · kafka-kraft#

1.1 · S 什么场景#

学习 Kafka 新版本部署、阅读 Kafka 架构资料，或者排查集群控制面问题时，经常会看到 KRaft。

过去 Kafka 依赖 ZooKeeper 保存集群元数据，比如：

• broker 注册信息
• topic / partition 元数据
• leader 选举相关状态
• ACL、配额等部分控制面信息

现在 Kafka 正在用 KRaft 替代 ZooKeeper，这已经是理解 Kafka 新架构时绕不过去的一部分。

1.2 · C 什么冲突#

Kafka 本身已经是一个分布式日志系统，但它过去又依赖另一个分布式系统 ZooKeeper 来保存自己的元数据，这会带来几个明显冲突：

• 架构上多一套外部依赖，部署更复杂
• 运维时需要同时维护 Kafka 和 ZooKeeper 两个集群
• 故障定位跨两套系统，排查路径更长
• 元数据一致性、控制器选举逻辑分散在两种机制里，理解成本高

本质冲突是：

Kafka 的数据面已经很强，但控制面长期依赖外部系统。

1.3 · Q 什么问题#

1.3.1 · 1. KRaft 到底是什么#

KRaft = Kafka Raft Metadata mode

它表示 Kafka 不再依赖 ZooKeeper，而是使用 Kafka 自己基于 Raft 的机制来管理集群元数据。

可以把它理解成：

把原来放在 ZooKeeper 里的控制面元数据，收回到 Kafka 自己内部管理。

1.3.2 · 2. 它解决了什么问题#

主要解决三类问题：

• 降低部署和运维复杂度
• 统一元数据存储和控制器选举机制
• 让 Kafka 架构更完整，减少对外部系统的强依赖

1.3.3 · 3. KRaft 里的元数据放哪#

放在 Kafka 集群自己的 metadata log 中。

这是一份专门记录集群元数据变更的日志，包含：

• broker 注册与下线
• topic 创建、删除、配置变更
• partition 分配
• ISR、leader 变更等控制面事件

和普通业务消息日志不同，metadata log 不是给业务消费的，而是给 Kafka 内部控制器和 broker 同步集群状态用的。

1.3.4 · 4. KRaft 下还有 controller 吗#

有，而且 controller 的概念更重要了。

在 KRaft 模式下，controller 节点负责：

• 接收和提交元数据变更
• 维护集群元数据的最新状态
• 处理 leader 选举、broker 状态变化等控制逻辑

这些 controller 节点会组成一个 quorum，通过 Raft 选出 leader controller。

只有 leader controller 才能提交新的元数据记录，其他 controller 负责复制和容错。

1.3.5 · 5. broker 和 controller 是什么关系#

KRaft 模式下，节点角色可以拆分：

• broker：负责处理生产、消费、存储业务数据
• controller：负责管理元数据和控制面决策

部署上常见两种方式：

• 开发 / 测试环境：同一个节点同时承担 broker,controller
• 生产环境：通常建议把 controller quorum 独立出来

这样做的目的，是把数据面和控制面职责分离，降低相互影响。

1.3.6 · 6. 为什么说它基于 Raft#

因为 KRaft 用的是 Kafka 自己实现的 Raft 协议来复制元数据日志。

关键点是：

• controller 之间通过 Raft 保证元数据复制
• 多数派确认后，元数据记录才算提交
• leader controller 宕机后，剩余 controller 可以重新选主

所以 KRaft 的核心不是“去掉 ZooKeeper”这么简单，而是：

Kafka 用自己的共识协议接管了元数据管理。

1.4 · A 回答问题#

1.4.1 · 一句话理解

KRaft 是 Kafka 用 Raft 协议内建元数据管理能力、从而替代 ZooKeeper 的新架构模式。

1.4.2 · 为什么 Kafka 要引入 KRaft#

因为旧架构下 Kafka 依赖 ZooKeeper 管理元数据，导致：

• 系统组件更多
• 部署与升级更麻烦
• 故障排查链路更长
• 控制面不够统一

KRaft 的目标就是把这些能力收回 Kafka 内部。

1.4.3 · KRaft 带来的直接收益#

• 少维护一套 ZooKeeper 集群
• 元数据管理逻辑更统一
• 控制器选举机制更清晰
• 整体架构更简化
• 更符合 Kafka 后续演进方向

1.4.4 · 需要记住的关键词

• KRaft = Kafka Raft
• metadata log
• controller quorum
• leader controller
• broker / controller roles
• ZooKeeper removal

1.4.5 · 容易混淆的点

1.4.5.1 · KRaft 不是用来存业务消息的#

它管理的是 集群元数据，不是 topic 里的普通业务消息。

1.4.5.2 · KRaft 不是把 ZooKeeper 功能原封不动搬进 Kafka#

它不是简单“内嵌一个 ZooKeeper”，而是换成了 Kafka 自己的元数据日志和 Raft 共识机制。

1.4.5.3 · 去掉 ZooKeeper 不代表没有 controller#

controller 依然存在，只是它的工作方式和元数据存储方式变了。

1.5 · 迁移和实践注意点

• 老版本 Kafka 可能仍然运行在 ZooKeeper 模式，读文档时要先区分部署模式
• 看到 process.roles=broker,controller 这类配置时，基本就是 KRaft 模式
• 看到 controller.quorum.voters 时，说明需要显式配置 controller quorum
• KRaft 集群启动前通常需要先格式化元数据目录
• 生产环境重点关注 controller quorum 的奇数节点部署与容错设计

1.6 · 可以怎么记

可以用一句顺口的话记：

以前 Kafka 把“谁来管集群”交给 ZooKeeper，现在 Kafka 自己用 Raft 来管。

1.7 · 参考

• https://developer.confluent.io/learn/kraft