在开始之前，我指的大存储是gb，中期存储是小时。我们有一个Flink运行在AWS Kinesis Data Analytics for Flink Applications (KDA)上，它默认使用RockDB State Backend。KDA(有点像任务管理器)中的每个KPU都有50GB的RockDB存储空间。
我们的应用程序正在从Kinesis读取所有客户的事件并发送到各个目的地。当一个目的地变得不可访问时，我们希望将该目的地的事件存储到Flink State中，以便稍后重新发送它们，而不是停止整个处理。为了避免Flink中的内存不足，我们使用RocksDBListState来存储键列表，而每个键指向RocksDBMapState中的一个元素，其值为事件列表。通过这种方式，我们可以一次序列化和反序列化一小部分挂起事件，并将它们从RocksDB移到内存中，以避免"内存不足"。错误。以上所有的状态都是"由州键"的。每个目的地。
我的问题是，这是否是解决这类问题的正确方法。这种大型状态会对性能产生重大影响吗?这有什么维护缺陷吗?我没有发现任何类似的用法和讨论。欢迎提出任何建议。
谢谢!
我认为你应该能够得到你所提议的工作。但我想知道，你是否真的需要这个键列表。MapState提供了一个迭代器，用于遍历键，而使用RocksDB，该迭代器可以保证按顺序遍历序列化的键。也许这就是你所需要的?
当然，您可以预期最终会有大型检查点，这可能是操作上的麻烦——尽管在gb的规模上，它应该不会太糟糕。
一个可能更简单的替代方案是为每个目标部署一个单独的作业，当其目标不可用时，让作业失败，然后恢复。