Flink+Kafka最佳实践：实时计算的黄金搭档

KafkaSource<String> source = KafkaSource.<String>builder()
    .setBootstrapServers("kafka:9092")
    .setTopics("orders")
    .setGroupId("flink-order-group")
    .setStartingOffsets(OffsetsInitializer.committedOffsets(OffsetResetStrategy.LATEST))
    .setValueOnlyDeserializer(new SimpleStringSchema())
    .build();

// 设置Watermark策略
env.fromSource(source,
    WatermarkStrategy.<String>forBoundedOutOfOrderness(Duration.ofSeconds(5)),
    "Kafka Source");

// 两者都开：Flink管恢复，定期提交到Kafka方便监控消费进度
KafkaSource.builder()
    .setProperty("enable.auto.commit", "true")
    .setProperty("auto.commit.interval.ms", "5000")
    // Flink Checkpoint才是真正的恢复依据

我们就是两者都开。Flink Checkpoint负责故障恢复（精确到条），同时定期提交Offset到Kafka方便运维用Kafka Manager看消费延迟。

生产踩坑集锦

坑一：Partition数和并行度不匹配

Kafka Topic: 6个Partition
Flink Source并行度: 8

结果：2个SubTask闲着没数据，浪费资源
      且会导致Watermark不推进（无数据的SubTask不产生Watermark）

最佳实践：Source并行度 = Partition数，或者Partition数是并行度的整数倍

坑二：消费延迟持续增大

排查步骤：
1. 看是否反压（下游处理不过来）
2. 看是否数据倾斜（某个Partition数据量远大于其他）
3. 看Checkpoint是否影响（Checkpoint期间暂停消费）
4. 看Source并行度是否够（加并行度+加Partition）

坑三：新Topic/新Partition不被发现

// 默认不会自动发现新Partition
// 需要手动开启
.setProperty("flink.partition-discovery.interval-millis", "30000") // 每30秒扫描

坑四：数据重复消费

Flink从Checkpoint恢复时会从保存的Offset重新消费
→ 下游必须做幂等（UPSERT/去重）
→ 这不是Bug，是At-Least-Once到Exactly-Once的设计

面试回答模板

「Flink消费Kafka的Offset由Checkpoint管理，故障恢复从Checkpoint保存的Offset开始消费。同时开启Kafka的auto commit方便监控。

注意事项：Source并行度和Partition数匹配、开启Partition自动发现、下游做幂等处理。

我遇到过消费延迟持续增大的问题，排查发现是某个Partition数据量是其他的10倍，加了Partition并重新分配后解决。」

📌 总结

记忆点	内容
Offset管理	Flink Checkpoint为主，Kafka commit为辅
并行度	Source并行度 = Partition数或其因子
分区发现	开启partition-discovery.interval
数据重复	恢复时重放是设计，下游做幂等
延迟排查	反压→倾斜→Checkpoint→并行度

▶ 下一篇预告：DAY 15 Flink+Doris/StarRocks

---

Wood聊大数据 | 9年大数据老兵，聊技术、聊职场、聊成长

---

小红书正文

Flink+Kafka是实时计算的黄金搭档，但生产踩坑不少。

Offset管理：Flink Checkpoint管恢复，同时开Kafka auto commit方便监控消费进度。

四个坑：① Partition数和并行度不匹配——闲的闲死忙的忙死，且Watermark不推进 ② 新Partition不被发现——要手动开partition-discovery ③ 消费延迟增大——按反压→倾斜→Checkpoint→并行度顺序排查 ④ 数据重复——恢复时重放是设计，下游做幂等。

最佳实践：Source并行度=Partition数。别多也别少。