Flink 恰好一次 - 在 sink 确认检查点和屏障答案

【问题标题】：Flink exactly once - checkpoint and barrier acknowledgement at sinkFlink 恰好一次 - 在 sink 确认检查点和屏障
【发布时间】：2018-05-31 01:53:26
【问题描述】：

我有一个带有接收器的 Flink 作业，它将数据写入 MongoDB。接收器是RichSinkFunction 的实现。

已启用外部检查点。间隔为 5000 磨机，方案为 EXACTLY_ONCE。

Flink 1.3 版，
Kafka（源主题）0.9.0

我无法升级到 Flink 1.4 的TwoPhaseCommitSink。

我有几个疑问

接收器在哪个时间点确认检查点屏障，在调用函数开始时还是在调用完成时？意味着它在确认障碍之前等待持久（保存在 MongoDB 中）响应？
如果提交 checkpoint 是由异步线程完成的，Flink 如何保证作业失败时只执行一次？如果接收器将数据保存到 MongoDB 但未提交检查点怎么办？我认为这最终会在重启时出现重复数据。
当我从 Flink 仪表板取消作业时，Flink 会完成异步检查点线程以完成还是硬杀 -9 调用？

【问题讨论】：

标签： apache-flink flink-streaming checkpointing

【解决方案1】：

首先，Flink 只有在源和接收器都支持的情况下才能保证端到端的exactly-once 一致性。如果你使用的是 Flink 的 Kafka 消费者，Flink 可以保证应用程序的内部状态是完全一致的。为了实现端到端的完全一次一致性，接收器也需要适当地支持这一点。如果 MongoDB 接收器工作正常，您应该检查它的实现。

检查点屏障通过数据传输通道发送常规消息，即检查点n 的屏障将流分成进入检查点n 和n + 1 的记录。接收器操作员将处理两个invoke() 调用之间的屏障，并触发状态后端执行检查点。然后由状态后端决定是否以及如何异步执行检查点。一旦触发检查点的调用返回，接收器可以继续处理。一旦状态后端通知接收器操作员，它将向 JobManager 报告它已完成对其状态的检查点。当所有操作员成功报告他们完成了检查点时，整体检查点就完成了。

此blog post 更详细地讨论了端到端的一次性处理以及对接收器操作员的要求。

【讨论】：

所以，一旦我确定我的数据在 Mongo 中成功保存，是否可以在接收器中强制检查点。
不，检查点由 JobManager 触发。因此，这反过来起作用，并且涉及更多。您只能在检查点完成后将数据提交到外部系统（实现CheckpointListerner 接口）。此外，您需要确保如果出现故障，您可以重复交易。这个话题太复杂了，无法在 Stack Overflow 上发表评论。检查博客文章，并可能将 TwoPhaseCommitSink 反向移植到您的版本。