在开始之前，我所说的大是 GB，中期存储是几个小时。我们有一个在 AWS Kinesis Data Analytics for Flink Applications (KDA) 上运行的 Flink，它默认使用 RockDB 状态后端。KDA 中的每个 KPU（有点像任务管理器）都有 50GB 的 RockDB 存储。增量状态已启用。
我们的应用程序正在从 Kinesis 读取所有客户的事件并将其发送到各个目的地。当一个目的地变得不可访问时，我们不想停止整个处理，而是希望将该目的地的事件存储到 Flink State 中，以便稍后重新发送它们。为了避免 Flink 内存不足，我们使用RocksDBListState存储键列表，而每个键指向一个元素，RocksDBMapState其中包含事件列表的值。通过这种方式，我们可以一次序列化和反序列化一小部分待处理事件，并将它们从 RocksDB 移动到内存中，以避免出现“Out Of Memory”错误。对于每个目的地，上述所有状态都是“由状态键控”的。
我的问题是，如果这是解决此类问题的正确方法。这种大状态是否会对性能产生重大影响？是否有任何维护陷阱？我没有找到任何类似的用法和讨论。欢迎任何建议。
谢谢！