Flink 的 Kafka connector 修复后仍会向 Kafka 提交 offset

我本以为只是给 Flink 在事务性 topic 上的作业做一个简单的 off-by-one 修复。我甚至觉得刚开始的时候自己还把它描述成“一个快速修复”。 一系列 review 提出了各种问题，而这些问题本质上都是同一个主题的不同变体：如果这个 partition 什么都没投递过呢？如果这个 split 还没有拿到真正的 offset 呢？如果 checkpoint 和 commit 之间有一条记录到达呢？如果这个 split 是有界的呢？ 这个修复的核心思路和我第一次提交时相比没有太大变化，但它周围几乎一切都变了。🙂 我并不声称 committed offset 现在在所有情况下都是正确的。我的 pull request 关注的是当 commit 发生时，哪个 offset 会被提交。它不改变什么会触发 commit，也不改变如果 commit 从未被触发会发生什么。 还有其他方面需要考虑。例如，FLINK-36532 正在研究用 savepoint 停止作业。savepoint 保存了 source 的 offset，但它们从未到达 Kafka。为此打开的 pull request 解释说，原因是上面描述的异步设计。当一个 checkpoint 完成时，commit 会作为一个任务排队到 split fetcher 上。stop-with-savepoint 在 savepoint 完成后立即关闭 reader，而 fetcher 在未运行排队任务的情况下关闭。consumer group 就停留在更早的 checkpoint 的 offset 上，或者如果之前没有执行过 commit，则根本没有 committed offset。 committed offset 是一条旁路。它是尽力而为的，绝不允许让作业失败，而且 Flink 的处理保证并不覆盖它。这意味着没有哪一段代码单独负责把它做对。reader 生命周期中的每一步（一个 checkpoint 完成、一个 split 结束、一个 reader 关闭、一个作业重启）都自行决定什么会到达 Kafka。我在这里描述了其中几步。而且我也展示了我多么容易漏掉步骤！ 非常感谢 Aleksandr、Martijn、Efrat、Arvid 在这个 pull request 上对我的耐心——正是他们的 review 发现了这里所写的大部分内容，而我也从这个过程中学到了很多关于 Flink 的 Kafka connector 内部机制的知识。 Tags: apacheflink, apachekafka, flink, kafka This entry was posted on Saturday, October 24th, 2026 at 4:33 pm and is filed under code. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.