Kafka 架构
Kafka 的架构核心：分区日志 + 多副本 + ISR 机制。面试主线：组件、副本模型、元数据管理。
集群组件
| 组件 | 职责 |
|---|---|
| Broker | 服务节点，存储分区数据 |
| Topic/Partition | 数据组织：Topic 分多个分区 |
| 副本（Replica） | 分区多副本（leader + follower） |
| 控制器（Controller） | 集群管理：分区分配、leader 选举 |
| 元数据 | 分区归属、配置（KRaft 管理） |
分区副本与 ISR
ISR: 同步副本集合, leader 故障从中选举
- ISR（In-Sync Replicas）：与 leader 保持同步的副本集合
- 写确认：acks=all 时 ISR 全部落盘才返回
- leader 选举只从 ISR 选（落后太多的副本不能当 leader，防丢数据）
- 副本数 3 是生产标配（容忍 1 台故障）
写入路径
生产者 → 分区 leader（追加写日志段）→ 副本同步 → acks 返回- 顺序追加写（磁盘顺序 IO，见高吞吐篇）
- 消息在分区内有序，跨分区无序
- 分区是并行和顺序的平衡点：分区分摊吞吐，分区内保顺序
KRaft：去 ZooKeeper
- 早期版本用 ZooKeeper 存元数据 + 选主（controller）
- KRaft（2.8 引入，3.x 稳定）：Kafka 自己的 Raft 实现，元数据日志化
- 收益：少一个组件、部署简化、controller 故障恢复更快
- 面试点：新版本默认 KRaft，ZK 已是历史
面试追问
- Kafka 集群有哪些组件？ Broker、分区副本、控制器（KRaft）。元数据管理是核心
- ISR 是什么？ 与 leader 保持同步的副本集合。acks=all 等 ISR 确认，选举只从 ISR 选
- 为什么副本 3？ 容忍 1 台故障，是成本与可用性的平衡
- 分区的作用？ 并行单位（吞吐）+ 顺序单位（分区内有序）。分摊数据
- KRaft 解决什么？ 去掉 ZooKeeper：部署简化、元数据管理更快。新版本默认