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

　　去年四月，凌晨三点十七分，我盯着 Flink Web UI 上那条跳来跳去的背压线，手边咖啡凉透，监控大屏右下角的 P99 延迟数字是 12.8 秒——比白天还高两秒。隔壁工位老张刚揉完眼睛说：“这数它不讲理啊。”我点点头，他手机壳上印着“Kafka 是神”，我信了三年。

　　其实从下午两点就开始卡，不是崩，是那种黏住的慢：Kafka Consumer 拉数据速度往下掉，Flink TaskManager 的 input queue 长度一路爬到 140 万，但 CPU 没飙，GC 日志也干净。我原以为是 topic 分区扩少了，结果发现分区数压根没动过；我原以为是序列化太重，查了一圈发现用的是 Kryo 默认配置，连 register 都没做全——可它以前跑得好好的。老张蹲在机柜前看网卡，说：“你看这个丢包率，0.003%，它配得上‘丢’字吗？”

　　我们把 consumer.group.id 改成新名字，重启 job，延迟掉到 5.3 秒。我松口气，端起杯子喝了一口冷咖啡，杯底沉着点未化的糖粒。十分钟后又涨回 11 秒。老张叼着没点着的烟：“你改 group id 的时候，有没有顺手删了那个 _consumer_offsets 里的旧 offset？没删，它就自己往老 offset 上怼。”我翻了眼 Kafka AdminCLI 的输出，第八次执行 describe offsets 命令，果然——三十六个分区里，二十九个 stuck 在三天前的 offset。Flink 自己不报错，只默默等、慢慢拖。

　　后来删 offset，调 fetch.min.bytes=1（之前是 1024），调 max.poll.records=100（之前是 500），把 fetch.max.wait.ms 从 500 压到 100。中间老张拍桌子喊“等等！先别发！”——他刚发现 broker 端 log.roll.hours=168，但我们 producer 写入峰值集中在早八点，每小时刷一次日志段，导致 compact 不及时，consumer 每次 poll 都得 scan 十几个 .log 文件。他切进 broker config 页面改成了 24，敲回车时鼠标抖了一下，误点了右边的 “Delete Topic Config” 按钮。页面没反应，他当没点着，继续干。五分钟后，所有 Flink task 报 UNKNOWN_TOPIC_OR_PARTITION。我们谁也没意识到，那一哆嗦，其实是删掉了 __consumer_offsets 主题的 cleanup.policy 配置项——默认值丢了，它就开始无限 retention.ms = -1。Topic 还在，只是底层 log 清理逻辑瘫痪了。

文章配图，仅供参考

　　恢复 cleanup.policy 后，延迟直接跳到 3.7 秒。再往后，就是调 consumer.fetch.max.wait.ms 和 socket.receive.buffer.bytes 的事了——不重要了。我那天记得最清的，是改完参数发版后第十七分钟，延迟曲线从锯齿变成一条平滑的绿线，稳在 3.6–3.9 秒之间晃。监控告警停了，老张拆开一包新烟，火机按了七下才打着。他说：“你看，Kafka 不是神，是块生锈的铁片，你非得拿砂纸顺着纹路磨，磨歪半毫米，它就咬你手指。”

　　对了，办公室绿植上周死了三棵，浇水太多；还有前台姑娘换口红颜色了，豆沙棕，上次是西柚粉。（删掉这两句，论点完全不受影响）

　　反正这事站得住的地方，就是优胜劣汰——不是架构优胜，是参数组合、人手抖、broker 配置残留、以及某个凌晨三点你没咽下去的那口咖啡渣，在一起互相熬出来的。不是哪个调参手册写对了，是它们全错了一遍之后，剩下来的那条活路。老张最后删掉那行 commit message：“修复消费卡顿”，改成“重置 consumer_offsets 的清理逻辑”。他发完 push 就关了电脑，说：“下次再这样，咱俩轮班睡这儿。”

　　有谁碰到过这个吗：fetch.max.wait.ms 设成 100 以后，consumer 端的 client-side lag 指标突然比 broker-side lag 高出整整一个数量级，但吞吐和延迟都变好了？

（编辑：航空爱好网）

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