Flink RocksDB状态后端读取耗时过长问题排查求助

我有一个Flink 1.19应用，其中包含一个带有TTL（5分钟）的ValueState（Boolean类型）的KeyedProcessFunction，处理着35000 rps的数据流。我已将RocksDB配置为Flink的状态后端：

state.backend: rocksdb
state.backend.incremental: "true"
state.checkpoint-storage: filesystem
state.checkpoints.dir: s3://some_path/state_checkpoints
state.savepoints.dir: s3://some_path/state_savepoints

同时配置了Checkpointing：

execution.checkpointing.storage: "filesystem"
execution.checkpointing.dir: s3://some_path/execution_checkpoints
execution.checkpointing.interval: "1min"
execution.checkpointing.mode: "AT_LEAST_ONCE"
execution.checkpointing.min-pause: "1min"
execution.checkpointing.timeout: "2min"
execution.checkpointing.tolerable-failed-checkpoints: "2"
execution.checkpointing.max-concurrent-checkpoints: "3"
execution.checkpointing.unaligned: "true"

托管内存设置为1.5GB，框架堆内存+任务堆内存为400MB，配置3个CPU、3个任务槽。

应用运行时，该KeyedProcessFunction的numRecordsInPerSecond在每个任务槽中从6500rps骤降至100-150rps，且低吞吐量状态会持续4-5分钟。此时火焰图显示org.rocksdb.RocksDB.get:-2占用100%的资源。请问导致该现象的原因可能是什么？

1. RocksDB TTL批量过期清理触发 #

你的ValueState设置了5分钟TTL，当大量key集中达到过期时间窗口时，RocksDB会触发后台批量清理操作。这个过程中需要遍历状态、标记并删除过期条目，还可能伴随Compaction（压缩）操作，会严重挤占RocksDB的IO和CPU资源。业务请求的get操作被抢占资源后响应延迟急剧升高，导致吞吐量骤降，而持续4-5分钟的时长也和TTL窗口高度匹配。

2. Checkpoint与TTL清理的资源冲突 #

你配置的Checkpoint间隔为1分钟，且允许最多3个并发Checkpoint。当Checkpoint的快照生成（尤其是增量Checkpoint对RocksDB状态的遍历、持久化）和TTL批量清理同时发生时，两者会争抢RocksDB的核心资源，直接导致RocksDB.get操作阻塞，拖慢整个处理流程。

3. 托管内存不足引发磁盘频繁换页 #

1.5GB托管内存由3个任务槽平分后，每个槽仅能分配到500MB。RocksDB的Block Cache、Write Buffer等核心组件依赖托管内存，当内存不足时，RocksDB会频繁将缓存数据换入换出磁盘，产生大量随机IO。此时get操作需要从磁盘读取数据，性能急剧下降，表现为火焰图中RocksDB.get占用100%资源。

4. Key分布不均导致热点槽资源耗尽 #

如果数据流中的key分布极不均衡，某个任务槽负责的key数量远多于其他槽，当这些key集中达到TTL过期时间时，该槽的RocksDB需要处理远超正常量的过期清理，同时业务请求的get操作也集中在该槽，直接导致资源耗尽，吞吐量骤降。

5. RocksDB Compaction策略不匹配场景 #

默认的RocksDB Compaction策略可能不适合高吞吐+TTL的场景。当大量过期key积累后，Compaction需要处理大量无效数据，会占用大量IO和CPU资源，阻塞正常的get请求。再加上你开启了增量Checkpoint，Compaction频率可能进一步提升，加剧资源冲突。

内容的提问来源于stack exchange，提问作者Paul