4. Kafka 核心概念回顾:Topic、Partition、Consumer Group、Offset

在深入 PSI 漂移告警的流处理实现之前,必须牢固掌握 Kafka 的四个核心抽象。它们是构建任何可靠流处理管道的基础,也是后续理解数据分区、并行消费、状态恢复与偏移量监控的前提。

4.1 Topic(主题)—— 数据流的逻辑分类

Topic 是 Kafka 中用于组织和管理数据流的基本单元,可以理解为数据库中的“表”或文件系统中的“文件夹”。生产者将消息写入特定的 Topic,消费者从该 Topic 读取消息。在 PSI 漂移场景中,我们通常会为原始指标流、预处理流、告警事件流分别定义不同的 Topic。

属性 说明
名称 全局唯一,如 psi-raw-metrics、drift-alerts
持久化 消息按配置保留时间(如 7 天)或大小存储在磁盘上
多订阅者 一个 Topic 可被多个独立的 Consumer Group 重复消费
分区数 创建时指定,决定 Topic 的最大并行处理能力

4.2 Partition(分区)—— 并行与有序的基石

每个 Topic 由一个或多个 Partition 组成。Partition 是 Kafka 存储和复制的最小单位,也是实现水平扩展与消息有序性的关键。

  • 物理存储:每个 Partition 对应一个日志文件(Log),消息以追加方式写入。
  • 顺序保证:消息在 单个 Partition 内 是有序的,但跨 Partition 不保证全局顺序。
  • 并行度:一个 Partition 只能被同一个 Consumer Group 内的一个消费者线程消费,因此 Partition 数量决定了该 Topic 的最大消费并行度。
  • 分区策略:生产者可通过 Key 哈希、轮询或自定义分区器决定消息写入哪个 Partition。在 PSI 漂移场景中,通常使用模型 ID 或特征名称作为 Key,确保同一模型的漂移指标进入同一 Partition,便于状态聚合。
实践建议: 在创建 Topic 时,Partition 数量应至少大于等于预期的最大消费者线程数。对于高吞吐的 PSI 指标流,建议初始设置 6~12 个 Partition,后续根据负载动态调整。
Topic 与 Partition 内部结构 Topic: psi-raw-metrics Partition 0 Leader (Broker 1) Offset: 0 → 1 → 2 → 3 Key: model-A PSI: 0.12, 0.15, ... Follower (Broker 2) Partition 1 Leader (Broker 2) Offset: 0 → 1 → 2 Key: model-B PSI: 0.08, 0.09, ... Follower (Broker 3) Partition 2 Leader (Broker 3) Offset: 0 → 1 → 2 → 3 → 4 Key: model-C PSI: 0.21, 0.18, ... Follower (Broker 1)

4.3 Consumer Group(消费者组)—— 弹性消费与负载均衡

Consumer Group 是 Kafka 实现点对点(Queue)与发布-订阅(Pub-Sub)两种消费模型的核心机制。一个 Group 内的消费者共同消费一个 Topic 的消息,每条消息只会被 Group 内的 一个 消费者实例处理。

  • 负载均衡:Group 内消费者数量变化时,Kafka 自动触发 Rebalance,重新分配 Partition 与消费者的对应关系。
  • 故障转移:若某个消费者崩溃,其负责的 Partition 会被分配给 Group 内其他健康消费者。
  • 隔离性:不同 Group 消费同一 Topic 互不干扰,各自维护独立的消费进度。
PSI 漂移场景映射: 每个模型监控任务对应一个 Consumer Group。例如 psi-monitor-group-prod 负责生产环境的漂移检测,psi-monitor-group-staging 负责预发布环境。两个 Group 可以同时消费同一份原始指标 Topic,但各自独立计算和告警。

4.4 Offset(偏移量)—— 消费进度的精确指针

Offset 是 Partition 内每条消息的唯一递增序号,标识消息在日志中的位置。消费者通过提交 Offset 来记录自己已经处理到的位置,这是实现“断点续传”和“精确一次语义”的基础。

概念 说明
当前 Offset 消费者当前正在处理的消息位置
已提交 Offset 消费者成功处理后向 Kafka 汇报的位置,用于故障恢复
Log-End Offset (LEO) Partition 日志中最新写入的消息位置
HW (High Watermark) 所有 ISR 副本都同步到的 Offset,消费者只能读取 HW 之前的消息
常见陷阱: 在 PSI 漂移告警中,如果消费者在处理完漂移计算之前就自动提交 Offset,一旦进程崩溃重启,会跳过未处理的消息,导致漏告警。建议使用 手动提交 模式,在确保告警逻辑执行完毕后再提交 Offset。
Consumer Group 消费与 Offset 管理流程 Partition 0 日志 Offset 0: PSI=0.05 Offset 1: PSI=0.08 Offset 2: PSI=0.12 Offset 3: PSI=0.15 Offset 4: PSI=0.22 Offset 5: PSI=0.31 Offset 6: PSI=0.09 Offset 7: PSI=0.18 LEO = 8, HW = 7 拉取 Consumer Group psi-monitor-group Consumer-1 处理 Offset 0~3 Consumer-2 处理 Offset 4~7 已提交 Offset: Consumer-1: 4 Consumer-2: 8 __consumer_offsets 内部 Topic Group: psi-monitor-group Topic: psi-raw-metrics Partition 0 → Offset 4 Partition 1 → Offset 8 提交

4.5 四者关系总结

Topic、Partition、Consumer Group、Offset 四者共同构成了 Kafka 的分布式消息模型。理解它们之间的关系,是后续配置 PSI 漂移检测拓扑、设置告警阈值、以及排查消费延迟问题的前提。

  • Topic 是逻辑容器,Partition 是物理分片。
  • Consumer Group 是消费实体,Group 内的消费者与 Partition 形成 N:N 的分配关系。
  • Offset 是消费进度的精确指针,存储在 Kafka 内部 Topic __consumer_offsets 中。
  • 在 PSI 漂移场景中,通过监控 Consumer Group 的 Lag(滞后量) 可以判断流处理是否健康,Lag 过大意味着漂移检测可能无法实时响应。
关键指标: 在后续的告警实践中,我们将重点监控 records-lag-max 和 offset-commit-rate 两个指标。前者反映消费积压程度,后者反映提交稳定性。当 Lag 持续增长时,说明 PSI 计算逻辑存在瓶颈或下游告警写入过慢。