📚 课程目录第2章 Kafka基础回顾

2. Kafka 基础回顾：Topic、Partition、Consumer Group、Offset 机制与消息存储原理

在深入 Kafka 堆积场景的治理之前，必须重新夯实 Kafka 的核心抽象。堆积的本质是生产速度 > 消费速度，而 Topic、Partition、Consumer Group 与 Offset 正是定义这一速度差的坐标系。本节从逻辑模型到物理存储，逐层拆解这些基础概念。

2.1 Topic 与 Partition：逻辑队列与物理分片

Topic（主题）是 Kafka 中消息的逻辑分类。一个 Topic 被切分为多个 Partition（分区），每个 Partition 是一个有序、不可变的消息日志。Partition 是 Kafka 并行度的基本单位：

顺序写入：消息追加到 Partition 尾部，利用磁盘顺序 I/O 获得极高吞吐。
分区内有序：同一 Partition 内消息按 Offset 递增，但跨 Partition 不保证全局有序。
物理隔离：不同 Partition 可分布在集群的不同 Broker 上，实现水平扩展。

堆积关联点：Partition 数量决定了消费端最大并行度。当消费速度跟不上时，增加 Partition 数并同步增加消费者线程是常见的扩容手段，但需注意 Rebalance 开销。

2.2 Consumer Group 与消费语义

Consumer Group（消费组）是 Kafka 实现点对点与发布-订阅两种模型的关键机制。同一 Group 内的消费者共同消费一个 Topic，每条消息只被 Group 内一个消费者实例处理。

概念	说明	堆积场景影响
Group Coordinator	负责管理 Group 成员与分配 Partition	Rebalance 期间消费暂停，可能加剧堆积
Partition 分配策略	Range / RoundRobin / Sticky / Cooperative	不均匀分配导致部分消费者积压严重
消费者数量上限	≤ Partition 总数，多余消费者闲置	扩容消费者前必须先扩容 Partition
心跳与超时	session.timeout.ms 控制失效检测	超时触发 Rebalance，造成消费抖动

2.3 Offset 机制：消费进度的唯一凭证

Offset（偏移量）是 Partition 内每条消息的唯一递增序号。消费者通过提交 Offset 来记录消费进度。Kafka 2.0+ 默认将 Offset 提交到内部 Topic __consumer_offsets，而非 ZooKeeper。

自动提交（enable.auto.commit=true）：周期性提交，可能重复消费或丢失消息。
手动提交（enable.auto.commit=false）：业务代码控制提交时机，精确控制 at-least-once / exactly-once 语义。
Offset 重置：当消费者组首次消费或 Offset 失效时，通过 auto.offset.reset 决定从 earliest / latest 开始消费。

堆积诊断关键指标：current_offset 与 log_end_offset 的差值即为堆积深度。监控此差值的变化趋势，比监控绝对值更有意义。

2.4 消息存储原理：Segment 与索引文件

Kafka 的消息持久化并非单文件存储，而是采用分段日志（Segment） 结构。每个 Partition 对应一个目录，目录内包含多个 Segment 文件及配套索引：

topic-partition/
├── 00000000000000000000.log        # 消息数据文件
├── 00000000000000000000.index      # 偏移量 → 物理位置索引
├── 00000000000000000000.timeindex  # 时间戳 → 偏移量索引
├── 00000000000000102453.log
├── 00000000000000102453.index
└── 00000000000000102453.timeindex

.log 文件：存储消息体，每条消息包含 CRC、magic、attributes、key、value 等字段。
.index 文件：稀疏索引，记录 Offset 与文件物理位置的映射，用于快速定位。
.timeindex 文件：按时间戳索引，支持按时间维度回溯消费。
滚动策略：当 Segment 大小达到 log.segment.bytes（默认 1GB）或时间达到 log.roll.hours（默认 7 天）时，创建新 Segment。

  堆积与存储的关系：堆积消息会持续占用磁盘空间。当 Segment 文件过多时，索引查询效率下降，消费者拉取延迟增加，形成“堆积 → 查询慢 → 消费更慢”的恶性循环。这是后续“慢查询”治理的核心切入点。

2.5 核心概念关系图

下图展示了 Topic、Partition、Consumer Group、Offset 与存储文件之间的逻辑关系：

2.6 消息写入与拉取流程

理解消息的写入路径与拉取路径，有助于定位堆积瓶颈：

Producer 发送：根据 key 或轮询策略选择 Partition，批量发送到 Leader Broker。
Leader 写入：追加到当前活跃 Segment 文件，同时更新 Offset。
Follower 同步（可选）：ISR 列表中的 Follower 拉取数据并写入本地日志。
Consumer 拉取：向 Broker 发送 FetchRequest，携带 Partition 与 Offset。
Broker 响应：从 Segment 文件中读取数据，返回给 Consumer。
Consumer 提交：处理完成后提交 Offset，标记消费进度。

  堆积场景下的关键路径：步骤 5 中，Broker 需要从磁盘读取数据。当 Segment 文件数量巨大或索引稀疏时，磁盘寻道时间成为瓶颈。这是后续“慢查询”治理中引入缓存层（如 Redis）的直接原因。

2.7 关键参数速查表

参数	默认值	堆积场景建议
`num.partitions`	3	根据预期吞吐量提前规划，堆积后扩容需触发 Rebalance
`log.segment.bytes`	1073741824 (1GB)	堆积严重时可适当减小，加快过期清理
`log.retention.hours`	168 (7天)	根据堆积容忍度缩短，避免磁盘写满
`fetch.max.bytes`	52428800 (50MB)	增大可提升单次拉取效率，减少网络往返
`max.poll.records`	500	堆积时适当增大，但需注意处理超时
`auto.offset.reset`	latest	新消费者加入时避免从 earliest 重读大量堆积数据

以上是 Kafka 基础回顾的核心内容。Topic 与 Partition 定义了消息的物理分布，Consumer Group 与 Offset 定义了消费的边界与进度，Segment 存储结构决定了读写性能的底层约束。这些概念是后续分析堆积成因、设计分治策略的理论基石。