Flink 1.13.2中Timers与State TTL存储及选型相关问题咨询

以下回答基于你使用的 Flink 1.13.2 + RocksDB状态后端 场景：

1. 通过timerService创建的Timer会存储在哪里？是存储在RocksDB中还是Task内存中？ #

Flink 1.13版本默认启用RocksDB原生Timer服务，你注册的registerProcessingTimeTimer定时器默认存储在RocksDB中，和业务状态一样支持持久化、容错。你也可以通过配置state.backend.rocksdb.timer-service.factory: heap手动指定Timer存储在TaskManager的堆内存中。

2. 通过StateTtlConfig配置的State TTL相关数据会存储在哪里？ #

TTL的核心元数据（状态的最后更新/访问时间戳）会和业务状态值绑定，一起存储在你配置的状态后端也就是RocksDB中，不会单独存储在其他位置。

3. 使用timerService或者State TTL时，是否会有内容存储到内存中？ #

两者都会有少量热数据缓存到内存中，不会全量加载所有数据：

• Timer场景：RocksDB会缓存热的Timer条目，同时Timer触发前只会把即将到期的小批量Timer加载到堆内存中执行触发逻辑；如果你手动配置了堆内存Timer服务，所有Timer会全量存储在堆内存中。
• State TTL场景：RocksDB的块缓存会缓存被访问的热状态条目，TTL过期判断逻辑只会处理当前加载到内存的状态条目，不会加载全量状态。

4. 若存在百万级Key的场景，应该优先选择哪种状态清理方式？ #

优先选择StateTtlConfig配置状态TTL：

• TTL的实现更轻量，不需要为每个Key单独注册定时器，元数据和业务状态绑定存储，存储开销远低于为每个Key注册Timer的方案。
• Flink对TTL清理做了多层优化：访问状态时自动校验并清理过期状态、后台异步增量清理过期状态、RocksDB compaction阶段自动过滤过期状态，整体性能远高于自定义Timer清理的方案。
• 只有你需要在状态过期时执行自定义逻辑（比如输出过期事件到侧输出流、触发额外计算）时，才需要选择TimerService的方案。

5. 使用timerService时，创建百万级Key是否会导致内存溢出异常？ #

默认配置下不会出现OOM：

• 因为Timer默认存储在RocksDB中，只有即将到期的小批量Timer会加载到内存执行，百万级Timer全量存在磁盘中，不会占用太多堆内存。
• 如果你手动配置了堆内存Timer服务，百万级Timer会全量存储在堆内存中，大概率会触发内存溢出。另外如果大量Timer的触发时间高度集中，瞬间加载的到期Timer过多也有小概率触发OOM，可以通过调整Timer加载批次大小降低风险。

6. 使用State TTL时，创建百万级Key是否会导致内存溢出异常？ #

不会出现OOM：
所有状态和TTL元数据全量存储在RocksDB磁盘中，只有被访问的热状态会加载到RocksDB的块缓存中，缓存大小可以通过RocksDB内存参数灵活配置，只要参数配置合理，即使是千万级Key也不会出现内存溢出。

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