Flink 一次性消息处理

Posted 2023-04-18

【中文标题】Flink 一次性消息处理

【英文标题】：Flink exactly-once message processing

【发布时间】：2017-04-16 09:01:44

【问题描述】：

我已经设置了一个带有 2 个 JobManager 和 3 个 TaskManager 的 Flink 1.2 独立集群，并且我正在使用 JMeter 通过生成 Kafka 消息/事件来对其进行负载测试，然后对其进行处理。处理作业在 TaskManager 上运行，通常需要约 15K 事件/秒。 该作业已设置 EXACTLY_ONCE 检查点并将状态和检查点持久保存到 Amazon S3。 如果我关闭运行该作业的 TaskManager，它会花费一些时间，几秒钟，然后该作业会在另一个 TaskManager 上恢复。该作业主要记录连续整数的事件ID（例如从0到1200000）。 当我在 TaskManager 上检查输出时，我关闭的最后一个计数是例如 500000，然后当我在不同的 TaskManager 上检查恢复作业的输出时，它以 ~ 400000 开头。这意味着 ~100K 的重复事件。这个数字取决于测试的速度可以更高或更低。 不确定我是否遗漏了什么，但我希望在不同的 TaskManager 上恢复后，该作业会显示下一个连续数字（如 500001）。 有谁知道为什么会发生这种情况/我必须配置额外的设置才能获得一次？

【问题讨论】：

Exactly-once 并不意味着每个事件都会被处理一次。 When we say “exactly-once semantics”, what we mean is that each incoming event affects the final results exactly once. Even in case of a machine or software failure, there’s no duplicate data and no data that goes unprocessed.

【参考方案1】：

您只看到了一次的预期行为。 Flink 通过检查点和故障重放的组合来实现容错。保证不是每个事件都会被发送到管道中一次，而是每个事件都会影响管道的状态一次。

检查点在整个​​集群中创建一致的快照。在恢复期间，操作员状态将恢复，并且从最近的检查点重播源。

如需更详尽的解释，请参阅此数据工匠博客文章：High-throughput, low-latency, and exactly-once stream processing with Apache Flink™ 或 the Flink docs。