了解 flink 保存点和检查点

Question

考虑一个带有如下管道的 Apache Flink 流应用程序：

Kafka-Source -> flatMap 1 -> flatMap 2 -> flatMap 3 -> Kafka-Sink

其中每个flatMap函数都是无状态运算符（例如Datastream的普通.flatMap函数）。

检查点/保存点如何工作，以防传入消息将在flatMap 3处挂起？ 从flatMap 1开始重新启动后消息会被重新处理还是会跳到flatMap 3 ？

我有点困惑，因为文档似乎将应用程序状态称为我可以在有状态运算符中使用的内容，但我的应用程序中没有有状态运算符。 “处理进度”是完全保存和恢复的，还是在失败/重启后会重新处理整个管道？

关于我之前的问题，失败（-> flink 从检查点恢复）和使用保存点手动重启之间有区别吗？

我尝试通过在flatMap 3放置Thread.sleep()并使用保存点取消作业来找出自己（使用EXACTLY_ONCE和 Rocksdb-backend 启用检查点）。 然而，这导致flink命令行工具挂起直到sleep结束，即使如此， flatMap 3也被执行，甚至在作业被取消之前发送到接收器。 所以似乎我无法手动强制这种情况来分析 flink 的行为。

如果我上面描述的检查点/保存点没有保存/覆盖“处理进度”，我如何确保到达我的管道的每条消息都永远不会重新处理任何给定的运算符（平面图 1/2/3）重启/失败情况？

Answer 1

当采取检查点时，每个任务（操作员的并行实例）都会检查其状态。 在您的示例中，三个 flatmap 运算符是无状态的，因此没有要检查点的状态。 Kafka 源是有状态的，并检查所有分区的读取偏移量。

在失败的情况下，作业被恢复并且所有任务都加载它们的状态，这意味着在源操作员的情况下读取偏移被重置。 因此，应用程序将重新处理自上次检查点以来的所有事件。

为了实现端到端的恰好一次，您需要一个特殊的接收器连接器，它提供事务支持（例如，用于 Kafka）或支持幂等写入。