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

　　去年春晚那波流量洪峰，我原以为Flink+Kafka那套配置撑得住——毕竟之前压测时延迟才300ms，结果真到峰值直接蹦到1.2秒，监控大屏上那条延迟曲线跟过山车似的，运营在群里狂@我，说优惠券发放都卡壳了。后来查日志才发现，Kafka的consumer group lag突然暴涨到百万级，Flink checkpoint时间直接翻倍，整个链路跟被灌了铅似的。

　　当时我盯着屏幕直犯懵，鼠标垫卷边了都没注意，饮水机在旁边咕嘟咕嘟响，隔壁工位的老张还在喊“谁的外卖到了”。后来拉了全链路日志才发现，问题出在Kafka的partition分配上——我们按业务模块分了16个topic，每个topic 8个partition，结果Flink的并行度设成了12，导致部分task manager要拉取两个partition的数据，网络IO直接拉满。更坑的是，Kafka的fetch.min.bytes参数默认1字节，consumer只要有空就疯狂拉数据，把网卡都榨干了。

　　调整参数那会儿，仓库卷帘门哐当响了一声，打包台上横着的那卷胶带被风吹得滚了半米远。我原以为改个fetch.min.bytes到32KB就能解决问题，结果测试环境跑出来延迟只降了15%。后来咬着牙把Flink的buffer timeout从100ms调到50ms，Kafka的num.network.threads从3加到8，延迟才勉强压到400ms——还是比压测时高30%。

　　真正让我破防的是，有次翻Kafka的GC日志，发现老年代回收居然要200ms！我们用的是G1垃圾回收器，原以为能自动优化，结果MaxGCPauseMillis没设，JVM自己按默认值在跑。后来把MaxGCPauseMillis改成50ms，Young generation size调到4G，老年代回收时间直接砍到50ms以内——这时候延迟才真正开始往下掉。

　　但最反常识的是，我们后来发现Flink的checkpoint间隔设得太频繁了！原本为了数据安全，每10秒做一次checkpoint，结果每次checkpoint都要冻结状态，导致处理延迟叠加。后来改成30秒一次，配合增量checkpoint，延迟直接又降了200ms——这他妈谁想得到？安全性和性能居然是反比关系？

　　说到这儿突然想起，去年双11有家同行更惨——他们用Flink写HDFS，没调并行度，结果单个task manager堆了200万条数据，OOM了三次，损失了半小时流量。后来他们老板直接把CTO骂到辞职，新来的架构师第一件事就是砍并行度，把单task数据量压到10万条以内。所以说啊，参数调优这事儿，真不是堆机器就能解决的——我见过有人把Kafka broker从8台加到16台，延迟反而更高，因为Zookeeper扛不住那么多连接了。

文章配图，仅供参考

　　不过话说回来，这些调优手段都有代价。比如我们把fetch.min.bytes调到32KB后，小消息的延迟反而高了；把checkpoint间隔拉到30秒，失败重试的概率也上去了。所以现在我们的策略是，平时用保守参数保稳定，大促前再切激进参数冲性能——就像赛车，平时开经济模式，比赛时才切运动模式。

　　最近在测Flink 1.17的新版checkpoint机制，据说能减少状态冻结时间。还有Kafka的KRaft模式，想去掉Zookeeper依赖。但测试环境总出怪问题——昨天跑着跑着，某个task manager的CPU突然飚到100%，查了半天发现是日志框架的异步线程池堵了。所以说啊，调优这事儿没尽头，今天降了70%，明天可能又冒出新的瓶颈。就像打游戏，刚打完一关，下一关的BOSS又变强了。

　　对了，上次调优时还发现个搞笑的事——我们有个监控脚本把毫秒当秒报，导致运营看到“延迟1.2秒”时差点吓尿，其实真实延迟才120ms。后来把监控单位统一改成毫秒，结果又有人看错小数点——所以说，技术债不光在代码里，还在人的习惯里。

　　现在我最怕的是，哪天Kafka或Flink突然来个大版本更新，把所有调优参数都改了。就像当年Hadoop从1.x升到2.x，YARN的资源模型全变，我们花了两个月重新适配。所以现在每次升级前，我都得先在测试环境跑一周压测，生怕生产环境出幺蛾子——毕竟春晚那种级别的流量，一年就一次，容不得半点闪失。

（编辑：航空爱好网）

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