3. Kafka核心概念：Topic、Partition、Consumer Group、Offset管理、消息可靠性保证
好，咱们进入第三章。说实话，Kafka 是整个实时数据管道的心脏。ODS 到 DWD 的清洗，说白了就是数据在 Kafka 里流转、被消费、被转换的过程。你要是搞不懂这几个核心概念，后面写 Flink 作业肯定会踩坑。
我刚开始接触 Kafka 时，觉得它不就是个消息队列嘛。后来在线上环境被折磨过几次，才真正理解每个设计背后的用意。今天咱们就把 Topic、Partition、Consumer Group、Offset 和可靠性保证这几个硬骨头啃下来。
一句话总结：Topic 是数据分类，Partition 是并行基石，Consumer Group 是水平扩展的关键，Offset 是消费进度的指针，可靠性保证是这一切能跑稳的前提。
3.1 Topic：数据的逻辑分类
Topic 是 Kafka 里最基础的概念。你可以把它理解成数据库里的表，或者文件系统里的文件夹。同一类数据就放到同一个 Topic 里。
举个例子，我们做实时数仓时，会把用户行为日志放到 ods_user_behavior Topic，把订单数据放到 ods_order Topic。这样下游的消费者各取所需，互不干扰。
我个人习惯在命名 Topic 时带上层级信息，比如 ods_xxx、dwd_xxx、dws_xxx。这样一看名字就知道数据到了哪个阶段，运维起来特别方便。
小技巧：Topic 的命名最好统一规范，建议用「数据域_业务过程_分区策略」的格式。比如 ods_user_login_d 表示按天分区的用户登录日志。
3.2 Partition：并行的基石
Partition 是 Kafka 实现高吞吐的核心。一个 Topic 可以分成多个 Partition，每个 Partition 是一个有序的、不可变的日志文件。
为什么要分区？说白了就是为了并行。你想想看，如果只有一个 Partition，那所有消费者都得排队读，吞吐量上不去。分成多个 Partition 后，多个消费者可以同时读不同的 Partition，吞吐量就上去了。
我记得有一次线上 Kafka 集群出现消费积压，排查下来发现 Topic 只设置了 3 个 Partition，但 Consumer Group 里开了 10 个消费者。结果 7 个消费者闲着，3 个忙死。这就是典型的「分区数 < 消费者数」导致的资源浪费。
| 分区数 | 消费者数 | 实际工作消费者数 | 说明 |
|---|---|---|---|
| 3 | 3 | 3 | 完美匹配，每个消费者处理一个分区 |
| 3 | 5 | 3 | 2 个消费者闲置，浪费资源 |
| 5 | 3 | 3 | 部分消费者处理多个分区，负载不均 |
避坑指南：我曾经在生产环境犯过一个错误——Topic 创建后分区数设得太小，后面想扩容。虽然 Kafka 支持动态增加分区，但扩容后分区与消费者的分配会重新触发 Rebalance，导致短暂的服务不可用。所以，创建 Topic 时最好根据预估流量预留 2-3 倍的分区数。
3.3 Consumer Group：消费的协作机制
Consumer Group 是 Kafka 实现点对点（Queue）和发布订阅（Pub/Sub）两种模式的关键。同一个 Group 内的消费者协同消费 Topic 的数据，不同 Group 之间互不干扰。
我举个例子你就明白了：假设我们有一个 ods_user_behavior Topic，里面有 6 个 Partition。
- 实时清洗作业（Group A）：开了 3 个消费者，每个消费者处理 2 个 Partition，把数据从 ODS 清洗到 DWD。
- 实时报表作业（Group B）：开了 6 个消费者，每个消费者处理 1 个 Partition，直接消费原始数据做报表。
你看，两个 Group 各自消费，互不影响。这就是发布订阅模式。而 Group 内部，多个消费者分摊 Partition，这就是点对点模式。
这里有个关键点：同一个 Partition 只能被同一个 Group 内的一个消费者消费。这是 Kafka 保证消息有序性的前提。如果你需要严格有序，那就只能用一个 Partition，但吞吐量会下降。这是个 trade-off，得根据业务场景取舍。
核心原则：Consumer Group 内的消费者数不要超过 Topic 的分区数，否则多余的消费者会闲置。反过来，如果消费者数少于分区数，部分消费者会处理多个分区。
3.4 Offset：消费进度的指针
Offset 是 Kafka 里最容易让人迷糊的概念。说白了，它就是消息在 Partition 里的位置编号。每条消息在 Partition 内都有一个唯一的 Offset，从 0 开始递增。
消费者消费完一条消息后，会提交 Offset，告诉 Kafka「我已经处理到这条消息了，下次从这里继续」。这样即使消费者挂了重启，也能从上次的位置继续消费，不会重复也不会丢失。
Offset 的提交方式有两种：
- 自动提交（enable.auto.commit=true）：消费者每隔一段时间自动提交 Offset。简单但不可控，容易丢消息或重复消费。
- 手动提交（enable.auto.commit=false）：业务代码里显式调用
commitSync()或commitAsync()。可控但代码复杂一些。
我个人习惯在实时清洗作业里用手动提交。为什么呢？因为清洗逻辑通常涉及状态操作，如果自动提交，万一消息处理到一半挂了，Offset 已经提交了，重启后就会跳过这条消息，数据就丢了。
// 手动提交 Offset 的示例
while (true) {
ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));
for (ConsumerRecord<String, String> record : records) {
// 处理消息，比如清洗、转换
processRecord(record);
}
// 处理完一批消息后手动提交
consumer.commitSync();
}经验之谈：我建议在实时清洗作业里使用「处理完再提交」的策略。先处理消息，处理成功后再提交 Offset。如果处理失败，不提交 Offset，下次重启还能重新消费。这样虽然可能重复处理，但至少不会丢数据。
3.5 消息可靠性保证
消息可靠性是实时数据清洗的生命线。数据丢了，清洗得再好也没用。Kafka 提供了三个维度的可靠性保证：
3.5.1 生产者端：ACK 机制
生产者发送消息时，可以设置 acks 参数来控制消息的确认级别：
| acks 值 | 含义 | 可靠性 | 性能 |
|---|---|---|---|
| 0 | 不等待任何确认，发完就算成功 | 最低 | 最高 |
| 1 | 等待 Leader 副本确认即可 | 中等 | 中等 |
| all（或 -1） | 等待所有 ISR 副本确认 | 最高 | 最低 |
我在实时清洗场景下，通常设置 acks=all。虽然性能会差一些，但数据安全是第一位的。你想想看，如果 Leader 挂了，消息还没同步到 Follower，那数据就丢了。这种事故我经历过一次，再也不敢用 acks=1 了。
3.5.2 服务端：副本机制
Kafka 的每个 Partition 可以有多个副本（Replica），分布在不同的 Broker 上。副本分为 Leader 和 Follower。生产者只往 Leader 写，消费者也只从 Leader 读。Follower 负责从 Leader 同步数据。
当 Leader 挂了，Kafka 会从 ISR（In-Sync Replica）中选举一个新的 Leader。ISR 是指与 Leader 保持同步的副本集合。
避坑指南：我曾经遇到过一个场景——某个 Broker 磁盘满了，导致 Follower 长时间无法从 Leader 同步数据，被踢出了 ISR。结果 Leader 挂了之后，ISR 里只剩一个副本，选举不出新的 Leader，整个 Partition 不可用。所以，一定要监控 ISR 的状态，确保副本数足够。
3.5.3 消费者端：至少一次语义
Kafka 默认提供「至少一次（At Least Once）」语义。也就是说，消息至少会被处理一次，但可能重复处理。这是由 Offset 提交机制决定的——如果消息处理完了但 Offset 提交失败，重启后会重新消费这条消息。
对于实时清洗来说，重复消费是可以接受的，因为清洗逻辑通常是幂等的。比如把 JSON 解析成结构化数据，重复解析一次结果一样。但如果你需要「精确一次（Exactly Once）」语义，就得配合事务或幂等生产者来实现，这个后面章节会详细讲。
3.6 知识体系总览
下面这张图把 Kafka 的核心概念串起来了，你可以对照着理解它们之间的关系：
这张图把今天讲的核心概念串在了一起。你看，Topic 在最上层，下面挂着 Partition，Partition 里维护着 Offset。Producer 往 Partition 写数据，Consumer Group 里的消费者从 Partition 读数据，并通过 Offset 记录消费进度。最下面那层是可靠性保证，贯穿整个链路。