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 只同步（2.4 起可配置消费者就近读 Follower）
Offset	消息在分区内的唯一编号	单调递增，消费进度就是 offset；分区间独立
Segment	分区日志的物理分段文件	一个分区 = 多个 segment（`.log` + 索引），见 Kafka存储与日志结构
Consumer Group	消费者的逻辑分组	组内分摊分区，组间互不影响（广播效果靠多个组）
Controller	集群控制角色	负责分区 Leader 选举、元数据管理；ZK 时代是某个 Broker 兼任，KRaft 下是 Controller 节点组成的 Raft Quorum，见下文

Partition：为什么是 Kafka 的灵魂#

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

plaintext

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

副本与读写路径#

每个分区有 replication.factor 个副本，其中 1 个 Leader、其余 Follower。
默认生产/消费都只和 Leader 交互；Follower 通过 Fetch 请求从 Leader 拉取数据保持同步。Kafka 2.4 起（KIP-392）可配置 replica.selector.class=RackAwareReplicaSelector + 消费者 client.rack，让消费者从同机房的 Follower 读，省跨机房流量；Follower 只能读到 HW 以内的数据，写仍然只走 Leader。
Leader 宕机时，Controller 从 ISR（同步副本集合）中选新 Leader，细节见 Kafka-ISR机制。

Controller 与元数据（ZK vs KRaft）#

ZooKeeper 模式（3.x 及以前）：
  - ZK 存储元数据（Broker 注册、Topic 配置、ISR 等）
  - 从 Broker 中选举一个作为 Controller，负责分区 Leader 选举

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

Kafka 4.0（2025-03）：彻底移除 ZooKeeper，只支持 KRaft；
  ZK 集群要先在 3.x 上迁移到 KRaft，再升级到 4.x

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（2.4 起可配置消费者就近读 Follower），Follower 负责从 Leader 拉数据做同步保证高可用，Leader 宕机时由 Controller 从 ISR 同步副本集合里选新 Leader。每条消息在分区内有唯一递增的 Offset，消费进度就是 offset。物理存储上一个分区由多个 Segment 段文件组成，配合稀疏索引快速定位。集群元数据的管理在 2.8 之前靠 ZooKeeper，由它选出 Controller Broker；2.8 之后引入 KRaft 模式用内部 Raft 协议取代 ZK，减少外部依赖、提升分区规模上限，4.0 起已彻底移除 ZooKeeper、只剩 KRaft。消费侧用 Consumer Group 实现负载均衡，组内消费者分摊分区，不同组之间互不影响可实现广播。消费采用 Pull 拉模式，好处是消费者能按自身能力控制速率不被压垮，空轮询则用 long polling 缓解。

追问与易错

追问方向：

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

易错点：

❌ Partition 越多吞吐越高——分区多了文件句柄、Leader 选举和故障恢复时间、Controller 元数据都会增加；而且分区只能增不能减
❌ 消费进度由 Broker 替消费者记着——进度是消费组自己提交到内部 Topic __consumer_offsets 的，按（组, Topic, 分区）存；没提交就重启，会按 auto.offset.reset 重新定位
❌ Kafka 4.x 还要部署 ZooKeeper——4.0 起只支持 KRaft，元数据由 Controller 节点管理