考察点
调优题是综合能力的收口，面试官想看的是方法论而非参数清单：先定位瓶颈再动手，而不是背一堆配置项。追问会往 TaskManager 内存模型、并行度怎么定、Checkpoint 参数组合走。
参考答案
调优的第一原则：先定位再动手
没有瓶颈画像的调优都是瞎调。标准动作：看反压状态找到瓶颈算子 → 看 subtask 处理量分布排除倾斜 → 看 busyTime/idleTime 判断是算不动还是在等待 → 看 GC 和 RocksDB 指标确认资源层问题。瓶颈定了，手段才有针对性。下面的手段按使用频率排。
并行度与资源
并行度是第一杠杆。定多少的依据是吞吐需求 ÷ 单并行实例实测吞吐，压测得出，别拍脑袋。几个要点：source 并行度通常对齐 Kafka 分区数；keyBy 之后的热点算子可以单独调高（setParallelism 按算子覆盖全局值）；并行度上限受 maxParallelism 约束，大作业建任务时就调大（比如 2048），否则以后扩不动；扩缩容走 Savepoint，key-group 自动重分布。
资源层面，TaskManager 的 slot 数决定资源粒度，一般每个 TaskManager 配 1-4 个 slot，CPU 核数与 slot 数对齐，避免一个 TM 塞太多 slot 导致 IO 争抢。
内存模型
Flink 的 TaskManager 内存分几块，调优常动的是：
- JVM Heap：放用户代码对象、Heap 状态后端的运行态。用 RocksDB 时堆不需要大。
- Managed Memory：RocksDB 的 Block Cache/Write Buffer、批的 sort 内存都从这里出。RocksDB 作业建议开托管（
state.backend.rocksdb.memory.managed=true），让框架统一分配，别手调 RocksDB 的几十个参数。 - Network Memory：网络缓冲。反压时缓冲被占满是正常现象，但缓冲总量太小会让非对齐 Checkpoint 的 in-flight 数据控制在一个小范围，间接影响吞吐平稳性，默认按堆外比例分配一般够用。
- Direct Memory / Overhead：网络缓冲和 JVM 开销，容器环境要预留，否则容易超容器限额被 kill。
Checkpoint 与状态优化
状态大就一定 RocksDB + 增量 Checkpoint。Checkpoint 间隔按「可接受的重放时长」定，常见 1-10 分钟，配合 minPauseBetweenCheckpoints 保证两次之间留间隔。对齐时间长的先查倾斜和反压，确认是反压导致再考虑非对齐 Checkpoint。状态能设 TTL 的都设上，Join/ProcessFunction 里的手动状态是膨胀重灾区。
算子与代码层
外部维度关联改异步 IO（AsyncDataStream）加本地缓存，同步 HTTP 查询是吞吐杀手；sink 攒批写（bulk/batch），MySQL 类 sink 几百到几千条一批；能用增量聚合就不用全量窗口函数；算子链按需拆合，两个重算子链在一起会争抢同一个线程；对象复用（enableObjectReuse）在 CPU 密集场景能省序列化开销，但要小心对象被下游改写的坑。
治理闭环
线上调优不是一次性动作：监控吞吐、延迟、Checkpoint 时长、反压占比、RocksDB 磁盘量这几个核心指标，流量增长前压测扩容，出问题按「反压定位 → 分类处理（倾斜/资源/外部依赖/状态）」的路径走。把这套流程讲出来，就是调优题的满分答案。
可能的追问
- 怎么判断该加并行度还是该优化代码？——busyTime 接近 100% 且各 subtask 均匀，先扩并行度；个别 subtask 特别忙是倾斜，先治倾斜；busy 不高但慢，查外部依赖和状态 IO。
- 堆内存给多大合适？——RocksDB 作业堆 2-4G 通常够，Heap 后端按状态量×（1.5-2 倍）估算；堆太大 Full GC 停顿反而明显。
- 调优后怎么验证效果？——对比同一流量下的吞吐、端到端延迟、Checkpoint 时长、反压时间占比，改一个变量看一组指标，别一把梭。