Apache flink 如果无法提交检查点数据，会发生什么情况？

我现在正在阅读Flink的检查点机制的细节，到目前为止，我认为我对所有东西是如何联系在一起的有一个非常好的概述，但最后一个问题让我想到了这里。 这是关于检查点和提交在ExactlyOnce上下文中如何相互作用的，因为我感觉仍然存在数据丢失/重复记录的可能性。当我在Flink博客中偶然发现这一段时，我主要在想

commit

消息或其回调的潜在失败：

在成功的预提交之后，必须保证提交最终成功–我们的运营商和外部系统都需要做出这一保证。如果提交失败（例如，由于间歇性网络问题），则整个Flink应用程序将失败，并根据用户的重新启动策略重新启动，然后再次尝试提交。这个过程非常关键，因为如果提交最终没有成功，就会发生数据丢失

直到现在，我仍然觉得检查点必须首先由sink提交确认，然后才能被视为“有效”。但是，一旦所有操作员都准备好实际提交，检查点就开始存在，从那时起，接收器必须保证提交可以完成，以确保没有数据丢失如果我的提交永远无法完成，例如，如果我的卡夫卡接收器关闭较长时间，具体会发生什么情况？这是否意味着如果定义的重试最终结束，检查点状态将是或Flink将只能在完成此特定提交后才能恢复作业，因此将被卡住，直到代理再次可用为止

---

如果

commit

的回调以某种方式丢失，这会在下一次重试尝试中得到解决吗？或者由于事务现在“完成”，生产者将无法提交，我们将进入重复重试的循环？（可能更多的是卡夫卡问题）

对于提交副作用（例如外部状态，参见卡夫卡事务），Flink正在使用

假设我们正在执行检查点42。首先发出预提交请求。如果所有参与者（并行子任务/操作员）成功确认预提交，

JobManager

/

CheckpointCoordinator

将开始发送提交请求

---

问题是，如果失败发生在这个时候，就没有办法回头了。如果某个提交失败或存在其他不相关的失败，作业将从检查点42重新启动，Flink将重新尝试提交挂起/预提交的事务。如果再次出现故障，请按照进行冲洗和重复。如果要避免数据丢失，提交尝试最终必须成功。没有别的办法。我们无法还原这些事务，因为一旦发出某些提交请求，某些事务可能已经提交，因此我们无法仅回滚其中的一部分（否则将出现数据重复问题）

请考虑下沉的情况，只要选定的重试策略在没有成功地与检查点42关联的事务的情况下成功地完成了任务，就不会有这样的情况。在这一点上，检查点42假设关于接收器的事情不是真的，我确实有数据丢失。对吗？是的，大卫·丹德森。如果要确保在不运行群集的情况下提交事务（外部副作用得以实现），则需要使用savepoint停止。@DavidAnderson感谢您详细阐述我的问题，这正是我想了解的细节。因此，Flink作业并不是无法从该检查点启动，而是将发生“只是”数据丢失，并且作业将能够在无错误的情况下启动（手动重新启动时）。我刚才还有一个想法：如果我没有显式地配置retain，那么这个场景中的检查点还会存在吗？默认情况下，检查点具有特定的生命周期，但它们仅在作业进入“已取消”或“已失败”状态时才被清除？我想first@kopaka即使您没有将检查点配置为在取消时保留，如果需要，也会存在一个检查点：即，如果作业失败。默认情况下，检查点是自动管理的，只有当故障恢复不再需要检查点时，才会清除检查点。一旦作业停止或取消，它就不会再失败。因此，只有手动取消才能清除检查点，这很好。另一个适合这个范围的问题是：保存点如何？我假设它们在一致性方面的工作方式类似（等待所有操作符准备好预提交，然后触发提交）。但是，由于检查点是手动创建的，所以检查点可能会在之后触发，这会保存应用程序的较新状态。从保存点而不是最新的检查点恢复将导致接收器中出现重复，对吗？这是在创建保存点而不取消作业时的预期行为，只是希望确保。