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

　　去年过年那会儿，我原以为能安心躺平三天，结果大年初三就被运维电话炸醒——Flink+Kafka那套实时采集链路，延迟直接飙到三秒多，审核那边都开始骂娘了。当时我盯着监控图，脑子嗡的一下：这特么不是平时的背压问题，Kafka的消费者组延迟像坐火箭似的往上窜，Flink的checkpoint也卡得死死的，整个链路跟被灌了水泥似的。

　　我第一反应是先骂运维：“你们是不是又偷偷调了Kafka的分区数？”结果人家甩过来一张截图——分区数没变，还是二十四个，但每个分区的消费进度条卡得跟便秘似的。再查Flink的taskmanager日志，好家伙，checkpoint超时警告刷得比春晚弹幕还密。我一边啃着冷掉的饺子，一边翻出半年前的调优文档，结果发现那文档里写的“适当增加并行度”根本没用——我把并行度从八调到十六，延迟反而涨到四秒，直接给审核系统整宕机了。

　　这时候群里突然弹出消息，测试组的小王发了张截图：“你们这Flink的state backend是不是用的rocksdb？”我盯着屏幕愣了三秒——对啊！我们为了省内存，把state backend从heap改成了rocksdb，结果rocksdb的写放大问题在春节流量暴涨时直接炸了。我抓起手机给小王发语音：“你他妈怎么不早说？”他回：“我半年前就提过，你们说‘先观察’。”我气得把手机摔在沙发上，结果把饺子汤溅到了键盘上。

　　饮水机没水了，我拎着空桶去楼下换，路上想着：Kafka的consumer lag高，可能是反序列化太慢；Flink的checkpoint超时，可能是state太大；但为什么调并行度反而更糟？我原以为增加并行度能分摊压力，结果rocksdb的磁盘IO成了瓶颈，二十四个分区被十六个taskmanager抢着读，磁盘队列直接排到外太空去了。回来后我直接把并行度调回八，把rocksdb的write_buffer_size从64MB调到256MB，又把Kafka的fetch.min.bytes从1B改成10KB——这招是偷学审核组的老张的，他说“别让消费者老去拉空消息”。

文章配图，仅供参考

　　但问题没完。第二天早上，SEO那边的人突然冲进来：“你们这延迟降了，但推荐位的曝光量怎么掉了？”我查了半天，发现是Flink的window操作太耗资源，导致部分消息被丢弃了。我原以为window是必须的——毕竟要算实时指标——结果推荐位那边说：“我们其实只需要最近五分钟的聚合数据，不用每秒都算。”我当场拍桌子：“你们早说啊！”他们回：“我们以为你们知道。”我气得把键盘敲得砰砰响，结果把隔壁工位的小李吓醒了——他昨晚加班到三点，这会儿正趴桌上睡觉。

　　后来我花了两天时间，把Flink的window从滚动窗口改成滑动窗口，又把Kafka的message.max.bytes从1MB调到4MB——这招是偷学采集组的老刘的，他说“大消息能减少网络开销”。改完这些，延迟终于稳定在三百毫秒以内，比之前降了七成。审核组的人发消息说：“这波可以，今晚加鸡腿。”我回：“加你个头，老子过年都没过好。”

　　其实现在回头看，这波调优能成，靠的不是什么高深技术，就是“优胜劣汰”——把没用的配置砍掉，把卡脖子的瓶颈找到，把该优化的参数调对。但说白了，这行最坑的就是“我以为”：我以为并行度越高越好，结果被磁盘IO打脸；我以为window必须每秒算，结果被业务需求打脸；我以为SEO和推荐位的人懂技术，结果被他们的“以为”打脸。现在我看监控图，第一眼先看ISR数量，第二眼看rocksdb的write latency，第三眼才看consumer lag——这都是血泪换来的经验。

　　窗外天已经黑了，我关掉监控页面，准备下班。突然想起测试组的小王今天没来——他昨天说要去相亲，估计这会儿正被女方问“你平时都干啥”呢。我笑了笑，心想：要是他敢说“我平时调Flink和Kafka”，这婚估计得黄。

（编辑：站长网）

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