凌晨两点十七分的告警提示音，我现在听见还是会生理性皱眉。
那是个跑了快一年的Flink实时任务，之前稳得像钉在集群上，突然就连续三次Checkpoint超时，紧接着TaskManager直接OOM挂掉。当时为了赶业务方的实时大屏出数，我们临时把并行度从8拉到16，堆内存直接给了4G，本来想着是救急，结果硬扛了两周，最后还是在大促流量峰值直接崩了。
说白了，大部分人对实时计算任务的资源调优，第一反应都是”不够就加”。
真不是。
先搞清楚你要调的到底是什么
很多人上来就对着监控图扒CPU使用率、内存占用率，看到数字高就往上拉资源配额，根本没搞清楚自己的任务到底卡在哪。我见过有人把一个每天处理几千万条的实时任务，并行度拉到128，结果大部分slot全在等网络传输，CPU平均使用率连10%都不到，钱花了，故障还是没少出。
实时计算任务的瓶颈从来不是”资源总量不够”，而是”资源和任务的运行阶段不匹配”。Checkpoint慢的时候，你加再多的计算资源也没用，瓶颈在状态后端的存储写入速度，或者是跨节点的网络带宽被占满了。之前碰到过一个流任务，每秒处理2万条数据，Checkpoint每次要跑40多秒，一开始大家都觉得是并行度太低，把并行度从16拉到32，结果Checkpoint时间直接涨到了1分20秒——因为并行度翻倍，要对齐的barrier数量也翻倍，跨节点传输的压力直接堆上去了。
那时候大家才反应过来，之前盯着并行度调优的思路从根上就错了。最后把并行度调回16，给状态后端的本地磁盘换了SSD，Checkpoint时间直接降到8秒，比之前拉到32的时候还稳。
别信什么”通用调优模板”
网上随便搜就能出来一堆”实时计算调优三板斧”，什么并行度设多少合适，堆内存占比要调到多少，网络缓冲开多大。真把这些参数抄到自己的生产任务上，十有八九要踩坑。为什么？因为每个任务的状态大小不一样，数据倾斜的程度不一样，上下游的链路时延要求不一样，甚至连集群的网络拓扑是三机架还是单机房，都会影响最终的资源消耗。
比如之前那个OOM的任务，我们后来查了trace才发现，根本不是内存给少了，是因为任务里有个自定义的聚合函数，把过去10分钟的窗口数据全存在了堆内存里，没有走托管状态。当时流量涨了30%，堆内存里的对象直接翻了倍，哪怕你给8G堆内存，只要对象引用不释放，迟早还是要OOM。
很多时候你以为的资源问题，本质上是代码写的有内存泄漏。
这里的取舍其实特别现实：你如果图快，直接把堆内存从4G拉到8G，确实能多扛个三五天，但每次GC的时间会从100ms涨到1s多，整个任务的端到端时延直接从200ms飘到1s，业务方那边的实时大屏数据延迟越来越高，你还得挨骂。反过来，你花两个小时把那个自定义的聚合逻辑改成走RocksDB托管状态，哪怕还是用原来的4G堆内存，任务的稳定性反而能提一大截。对吧？这笔账其实很好算，但大部分人故障一急就忘了。
调优从来不是一次性的事
很多团队的实时任务上线之后，就再也没人管了。资源配额是上线的时候拍脑袋定的，跑个半年，业务逻辑改了三版，流量涨了三倍，数据倾斜的key从原来的几个变成了上百个，原来的资源配置当然就不对了。
我之前接触过的一个推荐链路的实时任务，上线的时候给了8个slot，跑了半年，业务方加了三个维度的用户标签计算，每个slot的CPU使用率从20%涨到了85%，还是没人调，最后遇到一次活动流量峰值，直接把整个集群同节点的slot资源全占满，影响了其他十几个任务的运行。
实时计算任务的资源调优，本质上是给任务的运行留足够的冗余弹性，而不是把资源卡到刚好能跑。
什么意思呢？比如你算下来任务平时的CPU使用率是30%，你不能就给刚好够30%的资源，要留至少40%的冗余空间，应对突发的流量峰值，应对偶尔的数据倾斜，应对集群其他节点宕机之后的任务漂移。之前有团队为了省资源，把所有实时任务的平均CPU使用率卡到80%以上，结果一次单个节点的硬件故障，把上面跑的3个任务挪到其他节点，直接把本来就满的节点压垮，连锁反应崩了半个集群。我到现在都记得那次故障复盘会，运维的同学脸都绿了，说本来想给老板省点服务器钱，结果算上故障损失的业务收入，够买三倍的新服务器。
其实真没那么玄。
你不用去背那些复杂的计算公式，也不用照着别人的参数抄。每次任务出问题的时候，先别急着加资源，花十分钟看一眼监控的trace，看看到底是CPU打满了，还是内存不够，还是网络堵了，还是状态写得太慢。
调对一次，比你瞎加十倍资源有用。