📚 课程目录第2章 Kafka核心概念回顾

2. Kafka 核心概念回顾：Topic、Partition、Offset、Producer、Consumer、Broker、Zookeeper/KRaft 的作用

在深入驱动评分与低延迟方案之前，必须牢固掌握 Kafka 的七大核心概念。这些概念构成了 Kafka 分布式消息引擎的骨架，也是后续所有调优与架构设计的基础。本节将逐一拆解每个角色的职责与协作关系。

2.1 核心概念全景图

下图展示了 Kafka 集群中 Producer、Broker、Topic、Partition、Consumer Group 以及元数据管理组件（Zookeeper / KRaft）之间的数据流与协调关系。

2.2 概念详解与职责

概念	核心职责	关键特征
Topic	消息的逻辑分类，类似数据库中的表	可配置分区数、副本数、保留策略
Partition	Topic 的物理分片，实现并行读写	有序追加、不可变、每个分区独立 Offset
Offset	分区内消息的唯一递增序号	Consumer 通过 Offset 控制消费进度
Producer	将消息发布到指定 Topic	支持同步/异步、acks 确认、幂等性
Consumer	从 Topic 拉取消息进行处理	属于 Consumer Group，实现负载均衡
Broker	Kafka 服务器节点，存储消息	集群模式、Leader/Follower 副本机制
Zookeeper / KRaft	管理集群元数据、Controller 选举	Zookeeper 为旧版；KRaft 为 2.8+ 去 ZooKeeper 方案

2.3 核心概念深度解析

2.3.1 Topic 与 Partition

Topic 是消息的逻辑容器。一个 Topic 可以被多个 Consumer Group 订阅，每条消息只能被同一 Group 内的一个 Consumer 消费。
Partition 是 Topic 的物理存储单元。每个 Partition 是一个有序、不可变的日志文件（Log Segment）。
分区数决定了 Topic 的最大并行度：Producer 可并发写入不同分区，Consumer 可并发读取不同分区。

设计建议： 分区数并非越多越好。过多分区会增加 Broker 的元数据开销、文件句柄占用以及 Leader 选举时间。通常建议分区数 ≤ Broker 数 × 2~3。

2.3.2 Offset 与消费进度

Offset 是分区内每条消息的唯一标识，从 0 开始递增。Consumer 通过提交 Offset 来记录消费位置。
Kafka 支持 自动提交（enable.auto.commit=true）和 手动提交。在低延迟场景下，推荐手动提交以精确控制 at-least-once 语义。

// 手动提交 Offset 示例（Java）
consumer.commitSync(); // 同步提交，阻塞直到成功
// 或
consumer.commitAsync((offsets, exception) -> {
    if (exception != null) {
        log.error("Commit failed for offsets: {}", offsets, exception);
    }
});

2.3.3 Producer 与消息确认

Producer 通过 acks 参数控制消息持久化级别：
- acks=0：不等待确认，吞吐最高，可能丢消息。
- acks=1：等待 Leader 写入本地日志，不等待 Follower。
- acks=all（或 -1）：等待所有 ISR 副本确认，最安全。
在驱动评分场景中，若允许少量数据丢失换取极致延迟，可考虑 acks=1；金融级场景必须 acks=all。

2.3.4 Consumer Group 与再均衡

同一 Group 内的 Consumer 共同消费 Topic 的所有分区，每个分区只分配给一个 Consumer。
当 Consumer 加入/离开时，触发 Rebalance（再均衡），期间消费暂停。低延迟系统应尽量减少 Rebalance 频率。

避坑提示： 频繁的 Rebalance 会导致消费抖动和延迟飙升。建议使用 session.timeout.ms 和 heartbeat.interval.ms 合理配置，避免因网络抖动触发无效 Rebalance。

2.3.5 Broker 与副本机制

每个 Partition 有多个副本（Replica），分布在不同的 Broker 上。副本分为 Leader（负责读写）和 Follower（同步数据）。
ISR（In-Sync Replicas）：与 Leader 保持同步的副本集合。当 Leader 宕机时，从 ISR 中选举新 Leader。

2.3.6 Zookeeper 与 KRaft

Zookeeper：负责 Broker 注册、Topic 元数据、Controller 选举、Consumer Group 位移管理（旧版）。
KRaft：Kafka 2.8+ 引入的 Raft 协议实现，去除了对 Zookeeper 的依赖，简化运维并降低延迟。

2.4 Zookeeper 与 KRaft 架构对比

对比维度	Zookeeper 模式	KRaft 模式
依赖组件	需要独立 Zookeeper 集群	无外部依赖，Kafka 自管理元数据
元数据存储	存储在 ZK 节点中	存储在 Kafka 内部 Topic（__cluster_metadata）
Controller 选举	通过 ZK 临时节点选举	基于 Raft 协议选举
运维复杂度	高，需维护 ZK 集群	低，统一管理
延迟影响	ZK 读写增加额外网络开销	元数据操作延迟更低
适用版本	Kafka 2.8 之前	Kafka 2.8+（生产推荐 3.0+）

  关键结论： 对于新建的 Kafka 集群，尤其是对延迟敏感的驱动评分系统，强烈建议使用 KRaft 模式。它消除了 Zookeeper 这一外部依赖，减少了元数据操作的网络跳数，同时简化了运维。

2.5 本章小结

Topic 是逻辑分类，Partition 是物理分片，Offset 是消费指针。
Producer 负责写入，Consumer 负责读取，Broker 负责存储与副本。
Zookeeper 是传统元数据管理方案，KRaft 是未来趋势，推荐在新项目中采用。
理解这些核心概念是后续章节中配置调优、低延迟方案设计的前提。