2. Kafka 核心架构回顾：Topic、Partition、Broker、Producer、Consumer、Consumer Group
在深入 Kafka 堆积场景之前，必须对 Kafka 的核心架构有清晰、准确的理解。堆积的本质是生产速度 > 消费速度，而这一失衡现象直接作用于 Topic、Partition、Broker、Producer、Consumer 和 Consumer Group 这六大核心组件。本节将逐一拆解这些组件及其在堆积场景下的关键行为。
2.1 六大核心组件定义与职责
| 组件 | 核心职责 | 堆积场景下的关键角色 |
|---|---|---|
| Broker | Kafka 服务器节点，负责消息存储、副本同步、请求处理 | 磁盘 I/O 瓶颈、网络吞吐上限、日志段文件管理 |
| Topic | 消息的逻辑分类，由多个 Partition 组成 | 堆积直接表现为 Topic 的 Lag 持续增长 |
| Partition | Topic 的最小存储单元，有序、不可变的消息序列 | 单 Partition 的读写能力决定消费上限 |
| Producer | 消息生产者，将消息发送到指定 Topic 的 Partition | 发送速率、批次大小、重试机制影响堆积速度 |
| Consumer | 消息消费者，从 Partition 拉取消息进行处理 | 消费速率、提交偏移量策略决定 Lag 消除速度 |
| Consumer Group | 一组 Consumer 实例，共同消费一个或多个 Topic | 分区分配策略、Rebalance 频率影响消费连续性 |
2.2 核心架构关系图
下图展示了 Producer、Broker、Consumer Group 之间的数据流与核心组件关系。注意 Partition 是并行消费的基本单位，也是堆积发生的精确位置。
2.3 Partition：堆积的精确位置
Partition 是 Kafka 实现水平扩展和并行消费的基础。每个 Partition 是一个有序、不可变的消息序列，通过偏移量（Offset）唯一标识每条消息。在堆积场景下，我们需要关注以下三个关键偏移量：
- Log End Offset (LEO)：Partition 中最新消息的下一个偏移量，代表生产者已写入的位置。
- Current Offset (CO)：Consumer 当前已消费到的偏移量。
- Committed Offset：Consumer 已提交到 Kafka 的偏移量，用于故障恢复。
堆积公式： Lag = LEO - Committed Offset。当 Lag > 0 且持续增长时，即发生堆积。
2.4 Consumer Group 与分区分配策略
Consumer Group 是 Kafka 实现消费负载均衡和容错的核心机制。Group 内的每个 Consumer 负责消费一个或多个 Partition。当 Group 内成员变化或 Topic 分区数变化时，会触发 Rebalance 操作。
| 分区分配策略 | 策略说明 | 堆积场景影响 |
|---|---|---|
| Range | 按 Topic 分区范围顺序分配，可能导致分配不均 | 部分 Consumer 负载过高，Lag 集中在少数 Partition |
| RoundRobin | 所有 Topic 分区轮询分配给 Consumer，分配较均匀 | 负载相对均衡，但 Rebalance 时所有 Consumer 暂停 |
| Sticky | 尽量保持已有分配，减少 Rebalance 时的分区移动 | Rebalance 影响最小，适合堆积恢复场景 |
| Cooperative Sticky | 增量式 Rebalance，只移动必要分区 | 堆积恢复期间消费中断时间最短 |
2.5 堆积场景下的组件行为链路
当堆积发生时，各组件的行为链路如下：
- Producer 持续以高吞吐写入 Topic，Partition 的 LEO 快速推进。
- Broker 磁盘 I/O 和网络带宽成为瓶颈，日志段文件频繁滚动。
- Consumer 消费速率低于生产速率，Committed Offset 落后于 LEO。
- Consumer Group 内部分区分配不均，导致部分 Consumer Lag 异常高。
- 堆积持续恶化，可能触发 日志保留策略 删除未消费消息，造成数据丢失。
注意： 堆积不等于故障，但长期堆积会引发磁盘空间耗尽、Consumer 超时、Rebalance 频繁等连锁问题。后续章节将针对这些场景进行结构化日志采集与性能调优。
2.6 核心组件参数速查表
以下参数在堆积诊断和调优中频繁使用，建议熟记：
| 组件 | 关键参数 | 默认值 | 堆积调优建议 |
|---|---|---|---|
| Producer | batch.size |
16384 (16KB) | 增大至 32KB~64KB 提升吞吐 |
| Producer | linger.ms |
0 | 设为 5~20ms 增加批次填充率 |
| Broker | log.retention.bytes |
-1 (无限制) | 根据磁盘容量设置上限，防止堆积撑爆磁盘 |
| Consumer | max.poll.records |
500 | 根据处理能力调整，避免单次拉取过多 |
| Consumer | fetch.max.bytes |
52428800 (50MB) | 增大可提升拉取效率，但需注意网络 |
2.7 本节小结
理解 Kafka 六大核心组件及其在堆积场景下的行为，是后续进行结构化日志分析和性能调优的前提。请务必掌握以下要点：
- 堆积的精确位置是 Partition，衡量指标是 Lag。
- Consumer Group 的分区分配策略直接影响堆积的分布和恢复速度。
- 各组件参数需要根据堆积场景进行协同调优，单一参数调整效果有限。