2. Kafka 核心架构回顾：Broker、Topic、Partition、Producer、Consumer、ZooKeeper/KRaft 角色与数据流

在进行压力测试与异常自动复盘之前，必须对 Kafka 的核心架构有清晰、准确的理解。本章将系统回顾 Kafka 集群中的关键角色、它们之间的协作关系以及数据流转路径，为后续的压测指标解读与异常定位奠定基础。

2.1 核心角色与职责

Kafka 是一个分布式流处理平台，其架构由多个协同工作的组件构成。下表总结了各核心角色的定义与主要职责：

2.2 架构组件关系图

下图展示了 Kafka 集群中各组件之间的逻辑关系与数据流向：

2.3 数据流与消息生命周期

理解一条消息从产生到被消费的完整生命周期，是分析压测异常的关键。以下是标准的数据流步骤：

1. 消息生产： Producer 根据分区策略（如轮询、key 哈希）选择目标 Partition，将消息追加到 Leader 副本。
2. 副本同步： Leader 副本将消息复制到所有 ISR（In-Sync Replicas）中的 Follower 副本。
3. 消息确认： 根据 acks 配置（0、1、all），Producer 等待确认后认为发送成功。
4. 消息存储： Broker 将消息持久化到磁盘日志文件中，并维护偏移量索引。
5. 消息消费： Consumer 通过拉取模型（pull）从 Partition 中读取消息，并提交消费偏移量。
6. 日志清理： 根据保留策略（时间或大小），Broker 定期删除过期消息。

2.4 ZooKeeper 与 KRaft 模式对比

Kafka 的元数据管理经历了从 ZooKeeper 到 KRaft（Kafka Raft）的演进。下表对比了两种模式的关键差异：

2.5 分区与副本的数据流细节

为了更清晰地展示分区领导者与副本之间的数据同步机制，下图以单个 Topic 的 3 个分区为例，展示了数据写入与复制的详细流程：

2.6 关键数据流路径总结

以下列表总结了压测中需要重点关注的几条数据流路径及其潜在异常点：

• Producer → Leader Partition： 网络延迟、请求超时、批次大小不匹配可能导致发送失败。
• Leader → Follower 复制： 网络带宽不足或 Follower 处理缓慢会导致 ISR 收缩，触发 ReplicaFetcherThread 异常。
• Consumer → Partition 拉取： 消费组再平衡、偏移量提交失败、拉取线程阻塞会造成消费延迟。
• Broker → ZooKeeper/KRaft： 元数据更新频繁时，ZooKeeper 会话超时或 KRaft 领导者切换可能引发集群不稳定。