Kafka架构与核心概念#

一句话答案#

Kafka 核心概念：Broker（节点）、Topic（主题）、Partition（分区，有序）、Replica（副本 Leader+Follower）、Consumer Group。

核心要点

一张图看懂整体结构#

Producer ──→ ┌─────────────── Kafka Cluster ───────────────┐ ──→ Consumer Group
             │  Broker0      Broker1      Broker2           │
             │  ┌────────┐   ┌────────┐   ┌────────┐        │
   Topic A   │  │ P0-L   │   │ P0-F   │   │ P0-F   │        │   C1 ← P0
   (3分区     │  │ P1-F   │   │ P1-L   │   │ P1-F   │        │   C2 ← P1
    3副本)    │  │ P2-F   │   │ P2-F   │   │ P2-L   │        │   C3 ← P2
             │  └────────┘   └────────┘   └────────┘        │
             └──────────────────────────────────────────────┘
   L=Leader（读写） F=Follower（只同步）   同组消费者分摊分区

plaintext

核心概念逐个拆解#

概念	含义	关键点
Broker	Kafka 服务节点	一个集群多个 Broker，分区副本分散在不同 Broker 上
Topic	消息的逻辑分类	只是逻辑概念，物理上由多个 Partition 组成
Partition	Topic 的物理分片	分区内有序、跨分区无序；并行的最小单位
Replica	分区的副本	分 Leader / Follower，读写只走 Leader，Follower 只同步
Offset	消息在分区内的唯一编号	单调递增，消费进度就是 offset；分区间独立
Segment	分区日志的物理分段文件	一个分区 = 多个 segment（`.log` + 索引），见 Kafka存储与日志结构
Consumer Group	消费者的逻辑分组	组内分摊分区，组间互不影响（广播效果靠多个组）
Controller	特殊角色的 Broker	负责分区 Leader 选举、元数据管理，见下文

Partition：为什么是 Kafka 的灵魂#

作用 1：水平扩展   —— 一个 Topic 的数据分散到多个 Broker，突破单机容量/吞吐上限
作用 2：并行消费   —— 一个分区同一时刻只能被组内一个消费者消费
                     → 分区数 = 消费者组内的最大并行度
                     → 消费者数 > 分区数 时，多出来的消费者空闲
作用 3：顺序保证   —— 分区内严格 FIFO；要保序就让同 key 消息进同一分区

plaintext

常见陷阱：分区不是越多越好。分区过多会增加 Leader 选举耗时、文件句柄数、端到端延迟，详见 Kafka高性能原理。

副本与读写路径#

每个分区有 replication.factor 个副本，其中 1 个 Leader、其余 Follower。
生产/消费都只和 Leader 交互；Follower 通过 Fetch 请求从 Leader 拉取数据保持同步（不分担读，避免一致性问题）。
Leader 宕机时，Controller 从 ISR（同步副本集合）中选新 Leader，细节见 Kafka-ISR机制。

Controller 与元数据（ZK vs KRaft）#

Kafka 2.8 之前：依赖 ZooKeeper
  - ZK 存储元数据（Broker 注册、Topic 配置、ISR 等）
  - 从 Broker 中选举一个作为 Controller，负责分区 Leader 选举

Kafka 2.8+（KRaft 模式，3.3 起生产可用，3.5+ 推荐）：
  - 去掉 ZK，用内部 Raft 协议（__cluster_metadata topic）管理元数据
  - 由 Controller Quorum 选主，减少外部依赖、加快元数据传播、提升分区规模上限

plaintext

Push vs Pull#

Kafka 消费者用 Pull（拉） 模式主动拉消息：

✅ 消费者按自身处理能力控制速率，不会被压垮（对比 Push 的背压问题）。
✅ 便于批量拉取，提升吞吐。
⚠️ 无消息时会空轮询 → Kafka 用 long polling（fetch.max.wait.ms）阻塞等待缓解。

面试回答（2分钟版）

Kafka 的核心架构由几个关键概念组成。Broker 是集群中的服务节点。Topic 是消息的逻辑分类，物理上被切分成多个 Partition 分布在不同 Broker 上，这是 Kafka 实现水平扩展和并行的关键——分区内消息严格有序、跨分区无序，分区数决定了消费者组内的最大并行度，消费者数超过分区数时多出来的消费者会空闲。每个 Partition 有多个 Replica 副本，分为 Leader 和 Follower，读写都只走 Leader，Follower 只负责从 Leader 拉数据做同步保证高可用，Leader 宕机时由 Controller 从 ISR 同步副本集合里选新 Leader。每条消息在分区内有唯一递增的 Offset，消费进度就是 offset。物理存储上一个分区由多个 Segment 段文件组成，配合稀疏索引快速定位。集群元数据的管理在 2.8 之前靠 ZooKeeper，由它选出 Controller Broker；2.8 之后引入 KRaft 模式用内部 Raft 协议取代 ZK，减少外部依赖、提升分区规模上限。消费侧用 Consumer Group 实现负载均衡，组内消费者分摊分区，不同组之间互不影响可实现广播。消费采用 Pull 拉模式，好处是消费者能按自身能力控制速率不被压垮，空轮询则用 long polling 缓解。

追问与易错

追问方向：

“Topic 和 Partition 的关系？为什么要分区？”→ 一个 Topic 分为多个 Partition 分布在不同 Broker 上，实现水平扩展和并行消费；Partition 数决定了消费者组内最大并行度
“Kafka 的 ZooKeeper 作用是什么？去 ZK 之后怎么做？”→ ZK 负责 Broker 注册、Controller 选举、Topic 元数据存储；Kafka 2.8+ 引入 KRaft 模式用内部 Raft 协议替代 ZK，减少外部依赖和运维复杂度
“Kafka 消息是推还是拉？为什么用拉模式？”→ Kafka 消费者用 pull 模式主动拉取消息，好处是消费者按自身处理能力控制速率，避免推模式下消费者被压垮；缺点是无消息时空轮询，Kafka 用 long polling 解决

易错点：

❌ 只知道概念不知道原理——面试官会追问底层实现
❌ 缺乏实际使用经验——结合项目场景回答更有说服力