Flink+Kafka实时流处理延迟直降70%调优实录

　　去年国庆节那会儿，我原以为调个Flink+Kafka的延迟顶多熬两宿，结果愣是整了七天——业务方催得比运维还急，电话一个接一个，泡面都泡了五盒，凉透了都没顾上吃。最开始是监控报警，说实时流处理的延迟从三百毫秒飙到了一秒二，业务方直接炸锅：“这数据都滞后快两秒了，用户端都卡成PPT了！”我当时还嘴硬：“国庆节谁闲着没事儿搞你们数据？”结果一查，Kafka的消费者组堆积了二十多万条消息，Flink的并行度拉满到二十，CPU却只用了三成——这哪是资源不够，分明是卡脖子了。

　　头两天我盯着Flink的TaskManager日志，满屏的“Checkpoint timeout”和“Backpressure”，心想这不就是老问题吗？调大checkpoint间隔，把并行度提到三十，结果延迟反而涨到了一秒五。运维在旁边嘀咕：“是不是Kafka的broker压力太大？”我查了Kafka的监控，磁盘IO、网络带宽都没满，可消费者就是拉不动数据——就像你明明能跑百米，但鞋里塞了块石头，越使劲越慢。手机这时候震个不停，业务方又在群里@我：“用户投诉量涨了三倍，你们到底行不行？”我回了个“在调”，转头骂运维：“你们Kafka的分区是不是没调好？”运维翻了个白眼：“分区数和消费者数都匹配的，你自己看日志。”

　　第三天，我实在熬不住了，把Flink的配置全倒出来，一条一条比对。突然发现一个细节：Flink的“taskmanager.network.memory.fraction”设的是0.1，而Kafka的“fetch.min.bytes”是1MB——这俩参数看着不相关，可实际运行起来，Flink的网络缓冲区太小，导致数据传输时频繁阻塞，而Kafka的消费者又因为fetch.min.bytes太大，每次拉数据都要等满1MB才返回，一来二去，延迟就堆起来了。我试着把网络缓冲区调大到0.3，fetch.min.bytes改成64KB，重启Flink后，延迟直接掉到四百毫秒。业务方在群里喊：“降了！降了！”我松了口气，泡面还没拆，运维又凑过来：“不对啊，这延迟怎么还波动？”

　　第四天，波动的问题更邪乎——延迟有时候能降到两百毫秒，有时候又飙回八百。我查了Flink的背压监控，发现是某个算子的反压特别严重，可这个算子只是简单的过滤和映射，按理说不该卡。运维说：“会不会是数据倾斜？”我查了Kafka的分区消费情况，发现确实有一个分区的数据量是其他分区的三倍——原来业务方在生产数据时，某个字段的值分布不均，导致Kafka的分区键没打散，数据全堆到了一个分区上。我让业务方改生产逻辑，重新分配分区键，他们却说：“国庆节改代码？你们先想办法扛过去！”我气得直拍桌子：“不改代码，这延迟永远降不下来！”最后业务方妥协，临时加了个重分区算子，把数据打散后再处理，延迟终于稳定在三百毫秒以内。

　　第五天，我以为万事大吉了，结果运维突然喊：“Kafka的磁盘空间要满了！”我查了监控，发现堆积的消息虽然被消费了，但Kafka的日志保留时间设的是七天，而业务方要求保留三天——多出来的四天数据占了几百GB空间。我赶紧改配置，把日志保留时间改成三天，结果Kafka的broker开始疯狂删除旧日志，磁盘IO直接飙到100%，Flink的消费者又因为Kafka的响应变慢，延迟再次涨到六百毫秒。业务方在群里骂：“你们到底会不会调？”我回：“会调，但你们能不能别乱改需求？”运维在旁边补刀：“谁让你们当初不确认好需求？”我气得把键盘一摔：“这锅我不背！”

文章配图，仅供参考

　　第七天，我复盘整个过程，发现最坑的不是参数没调好，而是业务方和生产环境的各种“意外”：需求变来变去、数据分布不均、服务器资源混用……这些细节单个看都不致命，但堆在一起就能把延迟搞到崩溃。我原以为调优就是改改参数，结果发现优胜劣汰的从来不是技术，而是对细节的把控——谁更懂业务，谁更清楚数据的来龙去脉，谁就能在这场拉锯战里赢。运维说：“下次再遇到这种事儿，先让业务方签个确认书，省得背锅。”我笑了笑：“确认书？他们连密码都不改，你还指望他们签确认书？”

　　现在回头看，这事儿防不住——业务方永远有新需求，生产环境永远有意外，我们能做的，就是在每次崩溃后，把那些坑一个个填上，下次遇到类似的问题，能少熬两宿。至于延迟能不能永远稳定在两百毫秒以内？谁知道呢，反正国庆节已经过了，下次再搞，说不定又是另一个故事了。

（编辑：站长网）

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