Kafka的架构是怎么样的？

---

面试记录 2026-10-12

题目：Kafka的架构是怎么样的？

难度：medium

标签：db/mq/kafka, mq/kafka, difficulty/medium

评分：⭐⭐☆☆☆（2/5）

我的回答

Kafka 主要的架构相当于是三层的，生产者、消费者，还有自身的 Broker，也就是说加自身的处理端。另外处理端会涉及中间的协调，以前需要 Zookeeper 去进行协调，后来他把 Zookeeper 的操作移给了自己，用一个 Kafka 自身的 Topic 消息来做协调操作，完成了自己的闭环，就不需要再额外的 Zookeeper 了;

Kafka 是一个分布式的消息系统，它自身可以有部署在多台机器上，涉及主服务跟相关的分服务，用于进行分布式的支持。

点评

优点：

• 答出了"三层架构"这个基本骨架：Producer / Broker / Consumer
• 提到 ZooKeeper → KRaft 的演进——这是 Kafka 3.x 的重要变革，说明有跟进新版本的意识
• 意识到 Kafka 是分布式、多机部署的

不足：

• 完全没提 Topic 和 Partition——这是 Kafka 存储层最核心的抽象
• 完全没提 Replication 和 ISR——副本机制是 Kafka 高可用的基石
• 完全没提 Consumer Group——Kafka 消费模型的核心抽象，也是 rebalance 发生的地方
• "主服务跟相关的分服务" 表述模糊——Kafka 里所有 Broker 都是对等的，差异只在 Partition Leader/Follower 角色上
• 没提 Controller Broker 或 KRaft Quorum——专门负责元数据变更和 Leader 选举
• 没提 __consumer_offsets 这个内部 Topic

补充：

• 存储层：Topic → Partition → Segment（.log + .index），一个 Topic 由 N 个 Partition 组成，每个 Partition 是一个 append-only log
• 副本层：每个 Partition 有 Leader + Follower，形成 ISR，写入走 Leader，读可以走 Follower
• 协调层：ZK 时代由 ZooKeeper 存元数据 + 选 Controller；KRaft 时代用 KRaft Quorum（Raft 协议） 内嵌在 Kafka 里
• 消费层：Consumer Group 是消费模型的抽象，__consumer_offsets 存消费位点

完整讲解

第一部分：知识重点剖析

核心考点定位：考察对 Kafka 分层架构、副本机制、消费者模型的完整理解，尤其是"如何在保持简单组件的前提下做到高吞吐 + 高可用"这个设计哲学。

知识点拆解：

1. 三大角色组件：

• Producer：生产者，通过 Partitioner 决定消息路由，异步批量发送到 Leader Broker
• Broker：Kafka 的服务节点，所有 Broker 对等，无 Master/Slave 之分；每个 Broker 可以承载多个 Partition Leader 和 Follower
• Consumer：消费者，通常以 Consumer Group 形式工作

1. 存储层：Topic → Partition → Segment：

• Topic 是业务逻辑容器
• Partition 是物理上并行处理的单位，是 append-only log
• 每个 Partition 由多个 Segment 组成，.log（消息数据）+ .index（offset → position 索引）

1. 副本层：Leader/Follower + ISR：

• 每个 Partition 有一个 Leader，负责读写
• 其他是 Follower，异步复制
• ISR（In-Sync Replicas）：与 Leader 保持同步的 Follower 集合，acks=all 语义下的 ack 边界
• Leader 挂掉后从 ISR 中选举新 Leader

1. 协调层演进：

• ZooKeeper 时代：ZK 存集群元数据（Broker 注册、Topic 元数据、Partition Leader），有 Controller Broker 监听 ZK 变更
• KRaft 时代（Kafka 3.x）：用 Raft 协议 替代 ZK，通过 KRaft Quorum（内嵌 Controller Quorum）管理元数据，去除外部依赖

1. 消费层：Consumer Group：

• 消费者组是 Kafka 消费模型的核心，组内消费者共享 Partition，实现"一个 Partition 一个消费者"
• 消费位点存在内部 Topic __consumer_offsets（默认 50 分区）
• 消费者加入/退出触发 Rebalance

Kafka 的设计哲学：所有 Broker 对等，没有中心节点，通过 Partition 实现并行，通过 ISR 副本实现高可用。

第二部分：考察方向与延伸递进

考察方向：

• 深度：Segment 的滚动策略（log.roll.ms / log.roll.size）、Controller 的具体职责、KRaft 如何存元数据（MetadataTopic）
• 广度：与 RocketMQ（NameServer + Broker Master/Slave）架构对比、与 Elasticsearch（Master/Data/Coordinating）架构对比
• 应用：如何规划 Broker 数量和 Partition 分布、如何处理 Partition Leader 切换、KRaft 迁移的风险

延伸递进面试题：

1. Kafka 为什么让所有 Broker 对等，而不是采用 Master-Slave 模型？

• 解答要点：对等模型避免了单点故障和 Master 的性能瓶颈；通过 Partition 层的 Leader/Follower 而非 Broker 层的 Master/Slave，粒度更细、扩展更灵活

1. Controller Broker 挂了会怎样？

• 解答要点：ZK 时代另一个 Broker 会从 ZK 争抢 Controller 锁；KRaft 时代 Controller Quorum 由多个 Controller 组成，Quorum 多数存活即可；期间只有正常读写，元数据变更暂停

1. KRaft 相比 ZooKeeper 有哪些优势？

• 解答要点：去外部依赖、元数据写入性能大幅提升（批量+压缩）、大集群规模下启动更快、故障恢复更快

1. __consumer_offsets 内部 Topic 是什么？

• 解答要点：存消费者组的消费位点，默认 50 个分区，副本因子 5；本质是 Kafka 用 Kafka 存储自己的元数据

第三部分：面试者参考回答（300-400 字口语化）

面试官您好，Kafka 的架构我一般会从四层来讲。

第一层是角色组件，核心就三个：Producer、Broker、Consumer。特别想强调的是 所有 Broker 都是对等的，没有 Master/Slave 之分，差异只体现在"哪些 Broker 担任哪些 Partition 的 Leader/Follower"上，这是 Kafka 高可用和弹性扩展的关键设计。

第二层是存储层，一个 Topic 会被切成 N 个 Partition，每个 Partition 是一个 append-only 的顺序日志，物理上再拆成多个 Segment（.log + .index）。Partition 是 Kafka 并行的最小单位，也是消费者并行度的天花板。

第三层是副本层，每个 Partition 都有 Leader + Follower，形成 ISR（同步副本集）。写入走 Leader，Leader 落盘后通过异步复制给 Follower，acks=all 语义下等 ISR 全部确认才算成功。Leader 挂掉从 ISR 里选新 Leader。

第四层是协调层，这块经历过一次大演进：ZK 时代由 ZooKeeper 存元数据并选 Controller Broker；Kafka 3.x 引入了 KRaft（Kafka Raft Protocol），用内嵌的 Raft Quorum 替代 ZooKeeper，去掉了外部依赖，元数据管理性能也大幅提升。

消费端则是 Consumer Group，组内消费者共享 Partition，消费位点存在内部 Topic __consumer_offsets 里——这个设计很妙，Kafka 用 Kafka 自己存自己的元数据。

当然，Kafka 的架构复杂度并不低，特别是 KRaft 迁移和跨集群容灾（MirrorMaker 2）这些工程细节，实际落地还是要看具体场景权衡。