我们在Kubernetes上使用Apache Flink job cluster，它由一个Job Manager和两个Task Managers组成，每个都有两个插槽。群集是使用Lightbend Cloudflow框架进行部署和配置的。
我们还将RocksDB状态后端与S3兼容存储一起使用，以实现持久性。从CLI创建savepoints都没有任何问题。我们的工作由几个关键状态（MapState）组成，并且往往非常庞大（我们希望每个状态至少150 Gb）。作业的Restart Strategy设置为Failure Rate。我们将Apache Kafka用作来源，并在整个工作中下沉。
我们目前正在做一些测试（主要是PoC的测试），还有一些问题尚待解决：
我们进行了一些综合测试，并将错误的事件传递给了工作。在执行过程中引发了Exceptions。由于Failure Rate策略，将发生以下步骤：通过源读取Kafka的已损坏消息->操作员尝试处理该事件，并最终抛出Exception->作业重新启动并读取来自Kafka的相同记录，位于->操作员失败-> Failure Rate最终超过给定值之前，作业最终停止。接下来我该怎么办？如果我们尝试重新启动该作业，似乎它将以最新的Kafka使用者状态恢复，并且将再次读取损坏的消息，从而使我们回到前面提到的行为？解决这些问题的正确步骤是什么？ Flink是否利用任何一种所谓的Dead Letter Queues？
另一个问题是关于检查点和还原机制。我们目前无法确定在作业执行过程中引发的哪些异常被认为是至关重要的，并导致从最新检查点自动恢复之后导致作业失败？如前一种情况所述，作业内部引发的普通Exception导致连续重启，最终导致作业终止。我们正在寻找能够重现集群（Job Manager失败，Task Manager失败或其他情况）的情况，从而导致从最新检查点自动恢复。考虑到Kubernetes集群中的这种情况，欢迎提出任何建议。
我们沉入了Flink官方文档，但没有找到任何相关信息，或者可能以错误的方式理解了此信息。非常感谢！
答案 0 :(得分：2)
Flink的Kafka解串器采用的方法是，如果deserialize方法返回null，则Flink Kafka使用者将静默跳过损坏的消息。而且，如果抛出IOException，则管道将重新启动，这可能会导致失败/重新启动循环。
这在this section of the docs的最后一段中进行了描述。
可以在https://issues.apache.org/jira/browse/FLINK-5583和https://issues.apache.org/jira/browse/FLINK-3679以及https://github.com/apache/flink/pull/3314中找到有关该主题的过去的工作和讨论。
死信队列将是一个很好的改进，但是我不知道在这方面的任何努力。 （目前，过程函数的侧面输出是实现死信队列的唯一方法。）