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

文章配图，仅供参考

　　最开始我原以为调参数就能解决，把Kafka的`fetch.min.bytes`从1改到32，Flink的`bufferTimeout`从100ms降到10ms，结果延迟反而涨了——后来发现是Kafka的ISR（In-Sync Replicas）同步太慢，副本跟不上主分区，数据得等两次网络往返。那会儿耳机戴久了耳朵疼，我摘了耳机喊：“得动Kafka的`unclean.leader.election.enable`！”队友老张在旁边煮泡面，锅盖“咣当”一声，他喊：“这玩意儿关了会不会丢数据？”我回：“丢数据总比卡死强，先试！”

　　改完ISR同步确实快了，但Flink那边又出问题——消费端的`max.poll.records`设得太大，每次拉取1000条数据，处理不过来，堆积在TaskManager的内存里，GC压力直接拉满。我查日志时发现，每5分钟就有一次Full GC，每次停300ms，这哪行？外卖送到了，我边啃炸鸡边改参数，把`max.poll.records`从1000降到200，`max.poll.interval.ms`从300000（默认5分钟）改成60000（1分钟），让Flink更频繁拉数据，但每次少拉点。结果延迟从200ms掉到150ms，效果还行，但没到预期。

　　这时候老李在语音里一直咳嗽，说：“会不会是Kafka的`compression.type`？我们用的是snappy，压缩解压会不会拖时间？”我愣了下——之前没想过压缩的影响。查了下文档，snappy确实比lz4慢，但压缩率高。我们数据量不大，对吞吐要求不高，但对延迟敏感，于是把`compression.type`从snappy改成lz4，重启Kafka后，延迟又掉了30ms，到120ms左右。

　　但还不够，老板在群里催：“说好降70%呢？现在才降40%！”我充电线不够长，只能歪着坐看监控，发现Flink的`checkpointInterval`设的是10秒，每次checkpoint会冻结状态后端，导致处理延迟。我原以为checkpoint间隔短点能保证数据不丢，结果反而成了瓶颈。于是把`checkpointInterval`从10秒改成30秒，`minPauseBetweenCheckpoints`从0改成5秒，让checkpoint错开高峰期。改完延迟掉到80ms，离目标还差20ms。

　　这时候老张突然说：“会不会是网络？我们Kafka和Flink不在同一个AZ（可用区），跨AZ网络延迟可能有10ms。”我一拍桌子——对啊！之前光盯着参数，没考虑物理层。赶紧联系运维，把Flink的TaskManager迁到和Kafka同一个AZ，延迟直接掉到60ms，比最初200ms降了70%，老板终于在群里发了“OK”。

　　后来复盘时，老李说：“你这波调优，优胜劣汰的逻辑挺狠——先砍ISR同步的冗余，再砍Flink的批量拉取，接着换压缩算法，最后动网络，每一步都是把慢的环节淘汰掉。”我挠头：“我也就打了个大概，其实中间试了好多错的，比如一开始调`bufferTimeout`反而更卡，后来才发现是ISR的问题。”老张在旁边笑：“你键盘F键都快敲秃了，还说‘打个大概’？”

　　对了，退坑的那个朋友老王，之前搞Spark Streaming的，去年转行卖保险了。他说流处理太累，每天盯着延迟曲线，比看股票还紧张。我倒觉得还行——至少这次调优后，老板没再因为延迟骂人，虽然键盘F键声音还是不一样，但至少不用歪着坐了。

（编辑：站长网）

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