Flink 的 StateTtlConfig 不支持同时启用多个状态清理策略（如 cleanupInRocksdbCompactFilter 和 cleanupFullSnapshot），必须且只能选择一种；本文详解合法配置方式、性能权衡及推荐实践。
flink 的 `statettlconfig` 不支持同时启用多个状态清理策略（如 `cleanupinrocksdbcompactfilter` 和 `cleanupfullsnapshot`），必须且只能选择一种；本文详解合法配置方式、性能权衡及推荐实践。
在 Apache Flink 中，为有状态计算设置 TTL（Time-To-Live）是控制状态生命周期、防止内存/磁盘无限增长的关键手段。但一个常见误区是试图组合多种清理策略——例如在同一个 StateTtlConfig 实例中同时调用 .cleanupInRocksdbCompactFilter(...) 和 .cleanupFullSnapshot()。这是非法的，Flink 在构建时会抛出 IllegalStateException（具体提示为 “Only one cleanup strategy can be configured”），因为底层状态后端（尤其是 RocksDB）无法协调多路并发清理逻辑。
✅ 正确做法是：严格二选一，并根据业务场景与资源约束合理决策：
✅ 方式一：RocksDB 压缩过滤器清理（推荐用于大状态、高吞吐场景）
该策略在 RocksDB 后台 compaction 过程中按需扫描并剔除过期条目，开销低、无额外 I/O，适合海量状态（TB 级）和对延迟敏感的流作业。
StateTtlConfig ttlConfig = StateTtlConfig
.newBuilder(Time.minutes(3))
.cleanupInRocksdbCompactFilter(1000) // 每次 compaction 扫描约 1000 条候选键
.setUpdateType(StateTtlConfig.UpdateType.OnReadAndWrite)
.setStateVisibility(StateTtlConfig.StateVisibility.NeverReturnExpired)
.build();
⚠️ 注意：cleanupInRocksdbCompactFilter(n) 并非精确清理，而是启发式采样；实际清理时机依赖 RocksDB compaction 触发频率与数据写入模式。若 compaction 不活跃，过期状态可能滞留较久。
✅ 方式二：全量快照清理 + 后台异步清理（平衡型方案）
cleanupFullSnapshot() 本身仅在生成 checkpoint/savepoint 时执行一次批量清理；为增强及时性，可搭配 .cleanupInBackground(...) —— 二者可共存（注意：cleanupInBackground 是独立策略，不与 cleanupFullSnapshot 冲突）：
StateTtlConfig ttlConfig = StateTtlConfig.newBuilder(Duration.ofMinutes(3))
.setUpdateType(StateTtlConfig.UpdateType.OnCreateAndWrite) // 避免读放大，仅写时更新 TTL 时间戳
.setStateVisibility(StateTtlConfig.StateVisibility.NeverReturnExpired)
.cleanupFullSnapshot() // 快照时彻底清理
.cleanupInBackground(Duration.ofMinutes(1)) // 每分钟后台线程扫描并删除过期项（需启用后台线程）
.build();
? 提示：.cleanupInBackground(...) 自 Flink 1.15+ 起稳定可用，要求 StateBackend 支持异步清理（RocksDB 默认支持）。它比纯压缩过滤更及时，又比每次读写都检查 TTL（OnReadAndWrite）性能开销更低。
❌ 错误示例（禁止！）
以下代码将编译通过但运行时报错：
// ❌ 非法：同时启用两种互斥清理策略
StateTtlConfig invalid = StateTtlConfig.newBuilder(Time.minutes(3))
.cleanupInRocksdbCompactFilter(1000)
.cleanupFullSnapshot() // ← 运行时抛出 IllegalStateException
.build();
? 总结建议
- 优先选 cleanupInRocksdbCompactFilter：适用于 RocksDB 后端 + 大状态 + 高吞吐作业，零额外线程开销；
- 选 cleanupFullSnapshot + cleanupInBackground：适用于需兼顾快照一致性与清理及时性的中等规模状态；
- 避免 OnReadAndWrite + 大状态：读操作频繁触发 TTL 检查会显著增加延迟，推荐 OnCreateAndWrite 或 OnWrite；
- 始终显式设置 StateVisibility：NeverReturnExpired 可防止业务逻辑意外访问过期数据，提升健壮性；
- 弃用 Time 类：使用 Duration（如 Duration.ofMinutes(3)）以适配 Flink 新版时间 API。
正确配置 TTL 清理策略，是保障 Flink 作业长期稳定运行与资源可控的核心实践之一。
