我们正在使用Flink Kinesis Consumer将Kinesis流中的数据用于我们的Flink应用程序。
KCL库使用DynamoDB表来存储上次成功处理的Kinesis流序列号。这样下一次应用程序启动时，它会从它停止的地方恢复。
但是，似乎Flink Kinesis Consumer并没有保留任何这样的序列号。在任何持久性商店。因此，我们需要依赖ShardIteratortype（trim_horizen，latest等）来决定在应用程序重启时恢复Flink应用程序处理的位置。
对此的一种可能的解决方案可能是依赖于Flink检查点机制，但这仅在应用程序在失败时恢复时才有效，而不是在应用程序被故意取消并且需要从上次成功使用的Kinesis流序列号重新启动时才有效。
我们是否需要自己存储这些最后成功消耗的序列？
使用Flink的最佳做法是使用检查点和保存点，因为这些快照创建了一致的快照，其中包含消息队列的偏移量（在本例中为Kinesis流序列号）以及作业图的其余部分中的所有状态将数据消耗到那些偏移量。这使得可以在不丢失或重复数据的情况下恢复或重新启动。
Flink的checkpoints是Flink自动拍摄的快照，用于从故障中恢复，并采用针对快速恢复进行优化的格式。 Savepoints使用相同的底层快照机制，但是手动触发，它们的格式更关注操作灵活性而不是性能。
保存点是您正在寻找的。特别是，cancel with savepoint和resume from savepoint非常有用。
另一个选择是使用retained checkpoints和ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION。