2. Kafka 核心架构回顾：Topic、Partition、Consumer Group、Offset、Broker 角色与数据流

在深入诊断堆积问题之前，必须重新校准 Kafka 核心架构的认知。堆积的本质是生产速率 > 消费速率，但根因往往隐藏在分区分配、偏移量提交、Broker 角色交互等底层机制中。本节从最基础的五个核心概念出发，串联完整数据流，为后续的 API 治理与 Docker 调优打下精确的语义基础。

2.1 五大核心概念速览

2.2 Broker 角色与数据流

一个 Kafka 集群由多个 Broker 组成，每个 Broker 承担三种角色：分区 Leader、分区 Follower 和 Controller。理解角色分工是定位 Broker 级瓶颈的前提。

• Controller：集群的“大脑”，负责分区 Leader 选举、Broker 上下线处理。Controller 故障会导致集群短暂不可用。
• Leader：每个分区有且仅有一个 Leader，负责处理所有生产请求和消费请求。Leader 的负载直接决定该分区的吞吐上限。
• Follower：从 Leader 同步数据，作为冗余备份。Follower 不对外提供服务，但会参与 ISR（In-Sync Replicas）机制。

2.3 Topic 与 Partition 的物理存储

每个 Partition 在磁盘上对应一个目录，目录名格式为 <topic>-<partition>。目录内包含多个 .log 文件（消息数据）、.index 文件（偏移量索引）和 .timeindex 文件（时间戳索引）。

# 示例：Topic "orders" 的 Partition 0 在 Broker 上的目录结构
/var/lib/kafka/data/orders-0/
├── 00000000000000000000.log      # 消息数据文件
├── 00000000000000000000.index    # 偏移量索引
├── 00000000000000000000.timeindex # 时间戳索引
├── 00000000000000123456.log
├── 00000000000000123456.index
└── 00000000000000123456.timeindex

每个 .log 文件大小达到 log.segment.bytes（默认 1GB）后，Kafka 会滚动创建新文件。堆积诊断时，活跃 Segment（当前正在写入的 .log 文件）的大小和写入速率是重要指标。

2.4 Consumer Group 与 Offset 管理

Consumer Group 是 Kafka 实现点对点和发布-订阅两种模式的核心机制。组内每个消费者负责一个或多个分区，分区分配策略由 partition.assignment.strategy 决定。

2.5 完整数据流与堆积点定位

从生产者到消费者的完整数据流包含 6 个关键阶段，每个阶段都可能成为堆积的瓶颈：

1. 生产者发送：序列化、分区选择、压缩、缓冲区等待 → 堆积在客户端缓冲区
2. 网络传输：生产者 → Broker Leader 的网络延迟 → 堆积在网络层
3. Broker 写入：Leader 写入本地日志、Follower 同步 → 堆积在磁盘 I/O
4. 消费者拉取：消费者发送 FetchRequest，Leader 返回数据 → 堆积在消费者处理能力
5. 消费者处理：业务逻辑耗时、外部依赖阻塞 → 堆积在应用层
6. Offset 提交：提交失败或延迟 → 堆积在 Offset 管理

2.6 关键配置参数速查