Flink+Kafka深度调优：流处理延迟直降70%

　　去年七月份那会儿，群里有人贴了张监控图——Flink+Kafka的流处理延迟曲线，跟坐过山车似的，白天稳得像条死鱼，晚上十点突然飙到三秒，第二天早上又掉回五百毫秒。我盯着那图看了三分钟，外卖都凉了也没动筷子。这他妈哪是延迟波动，分明是有人在后台偷偷改参数。

　　当时我原以为又是Kafka的ISR同步问题，结果翻日志发现，Flink的Checkpoint间隔被谁调成了五分钟——问了一圈，运维小哥说“怕影响性能所以放宽了”。我直接笑出声，这逻辑就跟说“我少跑两趟厕所就能多写两行代码”一样离谱。后来拉着他一起看源码，发现Kafka的fetch.min.bytes参数被设成了1MB，消费者线程全堵在拉消息的路上，堆积的记录数直接爆了三万条。

文章配图，仅供参考

　　真正让我破防的是，把Checkpoint间隔改回三十秒后，延迟确实降了，但吞吐量掉了两成。老板在群里问“为什么处理速度变慢了”，我盯着屏幕上的监控图，突然想起上周测试环境也出现过类似情况——当时以为是网络抖动，现在看来，可能是Flink的buffer timeout和Kafka的linger.ms参数打架了。这两个参数一个管发送缓冲区，一个管消息批量发送，调一个另一个就得跟着动，就跟拧螺丝似的，左边紧了右边松，最后全乱套。

　　窗外开始下雨，我关了三个浏览器标签页，全是Kafka和Flink的官方文档。突然想起上个月客户那边也遇到过延迟问题，他们用的是Flink 1.13，Kafka 2.8，我让他们把num.io.threads从8调到16，结果延迟没降，反而报了“Too many open files”的错。后来发现是Linux的ulimit没调，文件描述符限制卡在1024，消费者线程根本开不起来。这事儿我到现在都没想明白——为什么参数调对了，系统反而崩了？

　　后来我们干脆上了压测工具，模拟了三种场景：高吞吐低延迟、低吞吐高延迟、混合负载。结果发现，当Kafka的replication.factor设为3时，Flink的并行度超过16就会触发副本同步延迟，这时候就算把network.threads调到16也没用，反而会因为线程竞争导致CPU飙升。最搞笑的是，我们把Kafka的log.flush.interval.messages从10000调到5000后，延迟降了30%，但磁盘IO直接翻倍，SSD的寿命估计得少半年。

　　群里有人问：“那你们最后怎么解决的？”我敲了行字：“把Flink的taskmanager.numberOfTaskSlots从4调到2，Kafka的num.partitions从24降到12，然后关了自动水位线调整。”对方回了个“？”，我补了句：“别问，问就是玄学。”其实我心里也没底——这些参数调整后，延迟确实降了70%，但我不确定是优化的功劳，还是因为那周业务量刚好少了三成。

　　现在回头看，这波调优能成，根本不是因为参数调得准，而是把那些“可能有用”的配置全删了。就像老张说的：“系统越复杂，越要往简单了调。”我原以为深度调优得把每个参数都摸透，结果发现，很多时候“优胜劣汰”就是靠删——删掉那些看起来很厉害但实际上没卵用的配置，删掉那些“以防万一”的冗余设计，删掉那些让系统变慢的“优化”。

　　上周我又看了眼监控，延迟稳定在200毫秒以内，比之前好了太多。但我还是不敢说这波调优绝对正确——也许下周业务量暴涨，或者Kafka又出个新版本，这些参数又得重新调。不过至少现在，我能确定两件事：第一，别信官方文档里的“推荐配置”，那玩意儿可能比你的测试环境还老；第二，调优不是拼参数数量，是拼谁更敢删东西。

　　对了，今天运维小哥又偷偷改了num.network.threads，从8调回12。我问他为什么，他说“感觉这样更快”。我盯着监控图看了十分钟，延迟没变，吞吐量也没变。可能他是对的，也可能只是今天运气好。反正调优这事儿，谁也说不准。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!