调实时任务，很多人第一眼盯 CPU。不对。
CPU 打满不一定忙，可能是在空转等网络。反过来，CPU 只有三成，任务也可能已经堵死。先看反压。Flink Web UI 里那个 BackPressure 面板，比 CPU 曲线诚实得多。上游发得快，下游处理慢，背压从下游往上游爬。你盯着 Source 端看，看不出病灶。
反压不是结果它是线索
反压只告诉你“堵了”，不告诉你为什么堵。常见原因：数据倾斜、外部存储写入慢、GC 抖动、序列化开销、并行度不匹配。排查顺序？别背口诀。从算子链里最慢的那一段开始。看 busy、backPressured、idle 时间占比。busy 高，说明真在算。backPressured 高，说明被下游拖着。idle 高，说明上游供不上。三者一摆，大致方向就出来了。
麻烦在于，很多监控面板默认只给平均值。平均值会骗人。一个并行子任务卡死，其他子任务正常，平均反压可能只有中等。得看分位、看最大值、看 subTask 维度。要不然调参全凭感觉。
实时计算任务的资源调优第一步是把反压定位到具体算子，而不是加资源。 加资源能缓解，但常常只是把问题往后推。
并行度和槽位别混着调
并行度不是越大越好。有人一看延迟高，先把并行度翻倍。然后呢？Kafka 分区数没变，Source 并行度上去了，多出来的子任务空转。中间算子并行度上去了，keyBy 之后状态被切得更碎，每个子任务的状态小了，但 checkpoint 的元数据操作变多。网络 shuffle 也更频繁。一增一减，不一定赚。
槽位是资源容器里的执行位置。并行度和槽位的关系，得看 slot 共享组。默认共享组下，一个 slot 能跑整条流水线。好处是本地性，坏处是任务互相抢内存和 CPU。把重算子拆到独立 slot 共享组，隔离性好了，资源利用率下来了。取舍，全是取舍。
说实话，我见过最稳的配置不是最细的，而是最清楚的。团队知道每个算子大概吃多少 CPU、多少内存、多少网络缓冲。这比拍脑袋设并行度强。
内存调优堆内堆外都要看
Flink 的内存模型不算复杂，但坑不少。总内存拆成 JVM 堆、堆外、网络缓冲、托管内存、框架堆外。调的时候，常见误区是只调 taskmanager.heap.size。新版本改配置名了，但逻辑没变。真正要盯的是 GC 日志和网络缓冲的可用量。 如果 Full GC 频繁，先别加堆。可能是状态太大、对象存活太久、或者序列化没选好。堆加到几十 G，GC 停顿反而更难看。
网络缓冲也容易忽略。上游算子写得太快，下游读得慢，缓冲池耗尽，反压立刻上来。调 memory.network.fraction，能缓解，但代价是托管内存变少。托管内存给 RocksDB 状态后端用的，少了之后读写放大、compaction 变慢。循环又回来了。
状态后端怎么选？RocksDB 适合大状态，但它是磁盘换内存。状态小、延迟敏感，就用 HashMapStateBackend。没有银弹。Checkpoint 间隔也得配合。间隔太短，状态反复刷盘，吞吐掉。间隔太长，故障恢复回放多。看业务能忍多久。这事得问业务，不能只问运维。
数据倾斜比参数难缠
数据倾斜是实时任务里最烦的一类。Key 分布不均，某个子任务 CPU 打满，其他子任务闲得发慌。加并行度没用，因为热点 key 还在同一个子任务里。两阶段聚合、加盐、本地预聚合，都是办法。但加盐之后，下游还得二次聚合，状态和网络开销都涨。
有个简单判断：看每个 subTask 的 recordsInRate。如果差一个数量级，基本就是倾斜。别急着调内存，先把 key 分布打出来。如果某个 key 占了一半流量，那它可能本来就不该走通用聚合。拆逻辑，或者单独限流。
限流不是丢数据。反压本身就是一种限流，但它是被动的。主动限流能保护下游存储。Kafka 消费端加 rate limiter，或者用 Flink 的 async I/O 控制并发。代价是延迟可能上去。但总比雪崩强。
动态扩缩容的收益和账单
K8s 上跑 Flink，动态扩缩容看起来很香。CPU 高了扩，低了缩。实际用起来，麻烦在于状态迁移。扩并行度要改 key group 分配，触发 checkpoint 和 reshard。缩并行度也一样。频繁扩缩，checkpoint 队列堆起来，反而影响稳定性。
动态扩缩容适合流量有明确潮汐的场景，不适合抖动型流量。 抖动型流量，加缓冲、加限流、加背压容忍度，比反复扩缩便宜。这里的便宜不只是钱，还有故障半径。
另外，资源请求和限制别设成一样。request 是调度依据，limit 是天花板。设成一样，节点资源碎片化，调度器很难塞下新任务。设得太松，又会互相抢。通常给 request 留余量，limit 略高，但别高到失控。具体数字得看压测。没压测就上生产，等于开盲盒。
监控要能回答问题
最后说监控。很多团队堆了一堆指标，出问题还是靠猜。为什么？因为指标没和排查路径挂钩。反压、GC、checkpoint 时长、state size、Kafka lag、外部存储 P99，这几类得能串起来看。最好一个面板解决：反压高的子任务是谁，它的 GC 怎么样，checkpoint 有没有超时，下游写库延迟多少。
别追求大而全。先把三个问题回答清楚：谁慢，为什么慢，改了什么之后变好了。没有第三条，调优就是玄学。
实时计算任务的资源调优，说到底是拿确定性换成本。加机器、加并行度、加内存，都是买确定性。但账单会来。更好的做法，是用观测把不确定性压下去。压到你能说清楚：这个算子，这个并行度，这个内存，刚好够。多一分浪费，少一分崩。那个点不好找，但值得找。