8.2 状态调优：给状态养生

8.2 状态调优：给状态养生

本节摘要：状态是流作业里唯一会"自然生长"的资产，养生不当就会重演第 4.4 节的解剖报告。本节给出状态调优的组合拳：TTL 的语义选择与误删陷阱、RocksDB 内存配比与写放大控制、增量快照与手动清理的配合。读完你应能为任意作业制定一份状态养护方案。

状态养生三原则

第 4 章建立过状态规模的心算公式：键数 × 单键记忆 × 生命周期。三个因子各对应一条养生原则——键数要管（倾斜与打散是 8.3 的事）、单键记忆要省（数据结构精简是编码课的事）、生命周期要限（TTL，本节主角）。调优的功夫七分在生命周期：绝大多数状态肿胀事故，根因都是"只进不出"。

TTL：给记忆定保质期

TTL（存活时间）让状态条目在无人问津一段时间后自动清理。配置它要回答两个问题。

第一个问题：计时从何时起算？ 两种口径：按更新时间（每次写入刷新计时）或按访问时间（读写都刷新）。口径选择直接决定语义：去重场景用更新时间（用户一天内重复访问要持续去重，但"过期"以最后一次写入算）；会话特征用访问时间（只要用户还在活跃，特征就一直有效）。

第二个问题：过期数据何时真正消失？ 两个层次：读取时的惰性过滤（过期了就当看不见，但占着空间）与后台的物理清理（压缩时顺手删除）。只开前者不叫清理——空间照占、快照照大，必须把物理清理策略一并打开（RocksDB 后端配套压缩触发清理的选项）。

ValueStateDescriptor<OrderStat> desc = new ValueStateDescriptor<>("shop-stat", OrderStat.class);
StateTtlConfig ttl = StateTtlConfig
    .newBuilder(Time.days(7))                          // 保质期七天
    .setUpdateType(StateTtlConfig.UpdateType.OnCreateAndWrite)   // 按写入计时
    .setStateVisibility(StateTtlConfig.StateVisibility.NeverReturnExpired)
    // 过期条目绝不返回：宁可重算也不给脏数据
    .cleanupInRocksdbCompactFilter(1000)               // 压缩时物理清理，每千次检查一轮
    .build();
desc.enableTimeToLive(ttl);
​

误删陷阱要单独交代：TTL 的语义是"无人问津才过期"，但"问津"的判定只看引擎视角的读写——业务上"活跃但暂时没数据"的键（凌晨歇业的商户）会被误判过期，之后再出现时状态从零开始。症状是"某些键的指标突然回零再重新累计"。处方有三档：调长保质期（最粗暴）、换访问时间口径（治本）、或在业务上接受重算（最诚实）。三档怎么选，取决于业务对"中断续算"的容忍度——这就是口径问题，不是参数问题。

RocksDB 的配比与写放大

选了 RocksDB 后端，配比账分三层。第一层：托管池总量（8.1 节的抽屉）。RocksDB 的写缓冲、块缓存、索引都从这个池子按需划拨；写放大抬头（4.4 节的病根）多半是池子不够、写缓冲被挤、频繁刷盘叠加压缩。第二层：单块参数。写缓冲条数与单条大小决定刷盘频率，块缓存大小决定读放大；默认值对多数作业够用，动了就要有对应症状支撑。第三层：磁盘的选择。RocksDB 的吞吐上限最终由本地盘决定，生产环境的共识是 SSD 起步——把 RocksDB 放在机械盘上，再多的内存配比都是白搭。

# RocksDB 常用的第一层处方：托管池配比（配合 8.1 的分区账一起调）
taskmanager.memory.managed.fraction: 0.4
# 状态读写走 SSD：物理路径由部署层决定，配置层确认即可
state.backend.rocksdb.localdir: /mnt/ssd/rocksdb
​

增量快照与清理的组合

状态调优的收官动作是让心跳变轻。增量快照（4.1 节提过）让每次 checkpoint 只上传变化部分——快照大小与耗时随状态总量的增长解耦，是 TB 级状态的标配。它与 TTL 是天作之合：TTL 负责让"消失的状态"真正从磁盘上走，增量快照让"留下的状态"不再拖累心跳。两者齐备后，4.2 节那套心跳体检四指标的曲线会整体下台阶——快照耗时回落到秒级、大小环比平稳、对齐不再横跳。

⚠️ 常见坑：TTL 一设了之，忘了开物理清理。惰性过滤只骗过读取，骗不过磁盘——三个月后快照越来越慢，翻日志才发现过期条目一直躺在 RocksDB 里陪压缩跑。TTL 配置必须成对出现：保质期加清理策略，缺一不完整。

状态健康度的周巡清单

调优不是一次性手术，状态需要周期性巡查。给值班体系补一张周巡清单，五项十分钟内可完成。一查快照大小周环比：连续两周增长超过两成，先怀疑状态泄漏（定时器未删、状态未清）而非流量增长。二查键数分布：抽样统计键控状态的键数量曲线，异常的阶梯式上涨常对应新的业务键维度上线。三查 TTL 覆盖率：列出作业里全部状态描述符，逐一确认声明了 TTL 或有等价的主动清理逻辑——第 4.4 节解剖报告里的"无 TTL 去重"就是这条清单要拦住的漏网之鱼。四查定时器积压：进程函数的定时器也是状态，注册多、删除少会悄悄堆积。五查序列化体积：单个状态条目的平均字节数环比陡增，通常是业务对象悄悄加了字段。周巡的意义在于把"慢性病"拦截在变成"急症"之前——状态问题几乎没有急刹车，只有提前转弯。

本节要点

• 状态养生三因子：键数（倾斜治理）、单键记忆（编码精简）、生命周期（TTL），七分功夫在生命周期。
• TTL 两问定语义：按更新还是访问计时、惰性过滤还是物理清理；配置必须"保质期加清理策略"成对出现。
• 误删陷阱的信号是"键指标回零重算"，处方按容忍度三档选：调长、换口径、接受重算。
• RocksDB 账分三层：托管池总量、单块参数、磁盘档位；写放大抬头先查托管池与盘。
• 增量快照与 TTL 组合拳把心跳四指标整体压下台阶，是 TB 级状态的标配方案。

状态养好了，还剩性能问题的最后一种脸型——数据倾斜。下一节给它做结构手术。