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

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

在深入分析异步导出故障中 Kafka 积压对服务边界的影响之前，必须牢固掌握 Kafka 的核心抽象与底层存储原理。本节将围绕五个关键概念展开：Topic、Partition、Consumer Group、Offset 以及消息存储机制。这些概念是理解积压成因、定位消费瓶颈、评估服务边界压力的基础。

2.1 核心概念速览

概念	定义	故障排查中的关键作用
Topic	消息的逻辑分类，类似数据库中的表	积压按 Topic 隔离，不同 Topic 的积压不会相互影响
Partition	Topic 的物理分片，每个 Partition 是一个有序、不可变的消息日志	Partition 是并行消费的最小单位，积压分布不均常由 Partition 分配倾斜导致
Consumer Group	一组消费者实例，共同消费一个或多个 Topic 的消息	Group 内消费者数量与 Partition 数的匹配关系直接决定消费吞吐
Offset	消息在 Partition 内的唯一序号，标识消费位置	Offset 滞后量（Lag）是衡量积压严重程度的核心指标
消息存储	消息以 Segment 文件形式落盘，支持顺序读写与索引检索	磁盘 I/O 瓶颈、Segment 文件过多会拖慢消费速度，加剧积压

2.2 Topic 与 Partition：逻辑分类与物理分片

Topic 是 Kafka 中最上层的消息分类单位。一个 Topic 可以被拆分为多个 Partition，每个 Partition 在物理上对应一个日志目录。Partition 内部的消息是有序的，但 Partition 之间不保证全局顺序。

积压排查要点： 当某个 Topic 的 Partition 数量少于 Consumer Group 中的消费者数量时，部分消费者会处于空闲状态，导致整体消费能力无法充分利用，积压风险上升。

最佳实践： 对于异步导出场景，建议将 Topic 的 Partition 数设置为消费者数量的 2~3 倍，以应对消费者实例的动态扩缩。

2.3 Consumer Group 与 Offset：消费协调与位置追踪

Consumer Group 是 Kafka 实现点对点消费模式的核心机制。同一个 Group 内的消费者共同消费一个 Topic 的消息，每条消息只会被 Group 内的一个消费者实例处理。Group 内消费者与 Partition 的分配关系由 Group Coordinator 和 Consumer Group Protocol 动态管理。

Offset 是消息在 Partition 内的唯一递增序号。消费者消费消息后，需要提交（commit）当前消费到的 Offset。Kafka 将 Offset 保存在内部 Topic __consumer_offsets 中。Offset 滞后量（Lag）定义为：Log End Offset (LEO) - Current Consumer Offset。

常见故障模式： 消费者提交 Offset 失败（如网络超时、消费者崩溃）会导致重复消费或消费断点回退，表现为 Lag 异常波动。排查时应重点检查消费者心跳与 Offset 提交日志。

2.4 消息存储机制：Segment 与索引

Kafka 的消息存储以 Partition 为粒度，每个 Partition 对应一个物理目录。目录内由多个 Segment 文件组成，每个 Segment 包含一个 .log 数据文件和一个 .index 偏移量索引文件。Segment 的命名规则基于该 Segment 中第一条消息的 Offset。

消息写入时采用顺序追加方式，这是 Kafka 高性能的核心原因之一。读取时通过二分查找索引文件快速定位目标 Offset 所在的物理位置。

积压与存储的关系： 当消息积压严重时，Partition 目录下的 Segment 文件数量会急剧增加。过多的 Segment 文件会导致索引膨胀、文件句柄占用过高，进而影响消费端的读取性能，形成“积压 → 存储压力 → 消费更慢 → 积压加剧”的恶性循环。

2.5 关键参数与积压排查对照

参数	默认值	积压场景下的调整建议
`num.partitions`	3	根据消费者数量与吞吐需求适当增加，建议 ≥ 消费者数 × 2
`replication.factor`	3	积压排查时需确认 ISR 列表是否完整，副本同步延迟会拖慢生产端
`min.insync.replicas`	2	设置过高可能导致生产端写入失败，间接引发积压
`max.poll.records`	500	积压时可适当增大，但需配合 `max.poll.interval.ms` 防止消费者失联
`fetch.max.bytes`	52428800 (50MB)	增大可提升单次拉取效率，但会增加内存压力
`log.segment.bytes`	1073741824 (1GB)	积压时适当减小可加快过期清理，但会增加 Segment 数量
`log.retention.hours`	168 (7天)	积压严重时可临时缩短，强制清理旧消息释放磁盘空间

2.6 积压排查中的基础检查清单

检查 Partition 数量与消费者数量匹配度：若消费者数 > Partition 数，存在空闲消费者；若消费者数 < Partition 数，单个消费者负载过高。
检查每个 Partition 的 Lag 分布：使用 kafka-consumer-groups --describe --group <group> 查看各 Partition 的 LAG 值，识别是否存在倾斜。
检查消费者 Offset 提交频率：提交间隔过长会导致重复消费范围扩大，影响 Lag 计算的准确性。
检查 Segment 文件数量与磁盘使用率：过多的 Segment 文件或磁盘接近满容量会触发 Kafka 的慢路径处理。
检查 ISR 列表：使用 kafka-topics --describe --topic <topic> 确认所有副本都在 ISR 中，避免副本同步延迟导致生产端限流。

快速命令参考：

# 查看消费者组详情（含 Lag）
kafka-consumer-groups --bootstrap-server localhost:9092 --group export-group --describe

# 查看 Topic 分区详情
kafka-topics --bootstrap-server localhost:9092 --topic async-export --describe

# 查看 Partition 目录下的 Segment 文件数
ls /data/kafka/async-export-0/ | wc -l