钱亚锋做实时数仓这两年，我最怕的不是数据延迟，而是状态只增不减。第一次遇到 Flink 作业内存溢出崩溃，排查到最后发现是按键分区状态里的 MapState 存了上亿条用户行为记录，磁盘直接吃掉 200 多 GB，作业恢复一次要半小时。后来我把状态生存时间（TTL）系统性地用起来，才彻底解决了这个“只进不出”的问题。这篇内容不是官方文档的翻译，而是我在真实生产环境里把 State TTL 从配置到监控踩通之后整理的完整笔记。它适合两类人：一类是被无界状态内存上涨折磨的 Flink 开发者，另一类是刚接触有状态计算、想知道 TTL 到底怎么生效的入门者。
1. 状态只增不减：一次真实的状态爆炸事故复盘
1.1 现象：状态从几个 GB 涨到 200 GB 只用了两周
那是某个实时用户标签作业，每天从消息队列里读取行为事件，按 userId 做 KeyBy 后，用 ListState 维护用户最近 30 天的访问记录。一开始状态只有几个 GB，两周后直接冲到 200 多 GB。作业开始频繁 GC，接着 RocksDB 的磁盘占用把数据盘打满，checkpoint 持续超时，最终状态恢复也要跑 30 分钟以上。当时的第一反应是加内存、加并行度，但效果都很差。内存加了 32 GB，才多撑 3 天；并行度从 20 调到 40，状态总量却没降。加内存和加并行度只能延缓状态爆炸，不能解决状态爆炸。那次事故后，我把整个 Flink 作业的状态管理从头捋了一遍，才真正意识到：在 Flink 里，按键分区状态的生命周期默认是“跟着整个作业走”，永远不主动删除。
1.2 根因：Keyed State 的“只增不删”特性
Flink 的按键分区状态（Keyed State）在逻辑上就是 key 到 value 的映射。无论是 Heap 还是 RocksDB 状态后端，存储层只会根据操作触发写入和更新，不会像数据库那样因为某个字段不再满足条件就自动回收。用户 30 天没有新行为，他对应的状态依然躺在那里。除非作业重启后 key 被重新分配，或者用户显式调用 clear()，否则旧数据几乎不会消失。实时任务最怕这种“只增不删”：数据是流的，状态是存量，业务要求只保留最近 N 天，但代码里没有定义过期规则，最终状态就会逼近无穷大。TTL 解决的核心问题，就是把“状态保留多久”这件事从业务代码中显式抽取出来，让状态后端按时淘汰不需要的数据。
1.3 TTL 不是万能的：它适合解决什么，不适合解决什么
状态生存时间适合用于会话统计、最近活跃用户、缓存型状态、防重校验这类对时间敏感的业务。比如“30 天未登录用户”“最近 1 小时点击流”“订单超时未支付”这些场景，数据一旦超过业务容忍的时间窗口，就完全失去保留价值。TTL 不适合用于全量累计型状态，比如总交易金额、历史最高分、累计投放预算。这些状态需要永久保留，设置 TTL 会导致数据过早丢失，而且 Flink 事后无法恢复。另一个容易被忽略的点是：TTL 不等同于“清理垃圾”。如果状态 key 数量巨大且写入频繁，TTL 的清理本身也会消耗 CPU 和磁盘 IO。所以在动手配置前，先想清楚业务上哪种数据可以丢弃，比调参数更重要。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。