2. Kafka 基础架构回顾：Producer、Broker、Consumer、Topic、Partition、Offset 核心概念

在深入诊断 Kafka 消息积压与数据库迁移 GC 停顿的关联之前，必须对 Kafka 的基础架构有精确的理解。Kafka 是一个分布式、分区化、多副本的发布-订阅消息系统，其核心抽象围绕 Topic、Partition 与 Offset 展开。本节将系统梳理六大核心组件及其交互关系，为后续的积压诊断与 GC 调优奠定基础。

2.1 核心组件与角色定义

Kafka 集群由以下四类角色构成，它们通过 TCP 协议协同工作：

组件 角色 关键职责
Producer 消息生产者 将消息发布到指定的 Topic；支持同步/异步发送、acks 确认级别、幂等性与事务
Broker 消息代理服务器 存储消息副本、处理读写请求、管理分区 Leader 选举；集群中每个 Broker 有唯一 ID
Consumer 消息消费者 从 Broker 拉取消息；以 Consumer Group 为单位消费，组内成员协同消费分区
ZooKeeper / KRaft 元数据协调者 维护集群元数据（Broker 列表、Topic 配置、Controller 选举）；新版本逐步迁移至 KRaft
诊断视角： 在 GC 停顿场景下，Producer 的 max.block.ms 与 Consumer 的 max.poll.interval.ms 是最容易触发超时积压的两个参数。Broker 端的 GC 停顿则直接影响分区 Leader 的响应能力。

2.2 Topic、Partition 与 Offset 的层次关系

Topic 是消息的逻辑分类，Partition 是物理存储与并行度的基本单位，Offset 是消息在 Partition 内的唯一顺序标识。三者构成 Kafka 存储模型的核心层次：

Topic → Partition → Offset 层次结构 Topic: “order-events” Partition 0 Partition 1 Partition 2 Partition 0 消息序列 Offset 0 → Offset 1 → Offset 2 Offset 3 → Offset 4 → … Partition 1 消息序列 Offset 0 → Offset 1 → Offset 2 Offset 3 → Offset 4 → … Partition 2 消息序列 Offset 0 → Offset 1 → Offset 2 Offset 3 → Offset 4 → … 关键概念 • Offset 在分区内严格递增，跨分区不保证全局有序 • Consumer 通过提交 Offset 记录消费进度，积压 = HW(高水位) - Consumer Offset

2.3 分区与副本机制

每个 Partition 可以配置多个副本（Replica），副本之间通过 Leader-Follower 模型保证数据冗余。这是理解 Broker 故障与 GC 停顿影响的关键：

  • Leader Replica：处理所有生产者和消费者的读写请求。每个分区只有一个 Leader。
  • Follower Replica：从 Leader 同步数据，不对外提供服务。当 Leader 宕机或长时间不可用时，Follower 通过选举成为新 Leader。
  • ISR（In-Sync Replica）：与 Leader 保持同步的副本集合。如果 Follower 落后太多或请求超时，会被踢出 ISR。
GC 停顿风险： 当 Broker 发生长时间 GC 停顿（如 Full GC 超过 10 秒），Leader 副本无法响应 Producer 的 ack 请求，Follower 副本因未收到 Leader 的心跳而被踢出 ISR。这会导致分区 Leader 重新选举，期间生产与消费全部阻塞，直接引发消息积压。

2.4 Consumer Group 与重平衡

Consumer 以 Group 为单位消费 Topic。Group 内的消费者共同分担 Topic 下所有分区的消费任务，每个分区在同一时间只能被 Group 内的一个 Consumer 消费。这种模型决定了积压诊断的粒度：

概念 说明 与积压的关联
Consumer Group 逻辑消费单元，Group ID 唯一标识 积压按 Group 维度统计，不同 Group 消费进度独立
分区分配策略 Range、RoundRobin、Sticky、CooperativeSticky 分配不均会导致部分 Consumer 积压严重
Rebalance Group 成员变更或分区数变化时触发 Rebalance 期间所有 Consumer 停止消费，积压瞬时上升
Offset 提交 自动提交（enable.auto.commit=true）或手动提交 GC 停顿可能导致自动提交超时，触发重复消费或偏移量回退

2.5 消息写入与拉取流程

理解 Producer 写入与 Consumer 拉取的全路径，是定位 GC 停顿影响点的前提。以下流程图展示了关键路径：

Producer 写入与 Consumer 拉取流程 Producer send() Broker Leader 副本写入 → ISR 同步 → ack fetch() Consumer GC 停顿影响点（红色标记） ① Producer 端：max.block.ms 超时 → 发送队列积压 → 客户端重试队列膨胀 ② Broker 端：Leader 停顿 → ISR 收缩 → 分区选举 → 全路径阻塞 ③ Consumer 端： max.poll.interval.ms 超时 → Consumer 被踢出 Group → 触发 Rebalance → 消费中断 session.timeout.ms 超时 → Coordinator 判定 Consumer 死亡 → 分区重新分配

2.6 积压诊断的核心指标

基于上述架构，诊断消息积压时需要关注以下关键指标，这些指标将在后续章节中与 GC 日志、JVM 堆转储进行关联分析：

  • Log End Offset (LEO)：分区中最新消息的 Offset，表示当前写入进度。
  • High Watermark (HW)：所有 ISR 副本都已同步的 Offset，Consumer 只能读取到 HW 之前的消息。
  • Consumer Offset：Consumer 已提交的消费进度 Offset。
  • Lag = HW - Consumer Offset：消息积压量，单位是消息条数。
  • Total Lag：Topic 下所有分区的 Lag 之和，用于评估整体积压规模。
实战要点： 在数据库迁移场景中，Consumer 端通常需要执行数据转换或写入目标库，这些操作会占用堆内存并触发 GC。当 GC 停顿导致 Consumer 心跳超时被踢出 Group 后，该 Consumer 负责的分区 Lag 会瞬间飙升。此时如果 Broker 端也因 GC 停顿导致 HW 推进缓慢，积压会呈现“双向冻结”状态——这是最严重的积压模式。
← 上一章 📖 返回目录 下一章 →