现象描述：
运维通告有一台kafka机器磁盘满了，运维正在进行重启。然后我们的实时的StreamingJob出现处理时间变长，出现大量的batch堆积。之前只需要2s的batch，现在需要2.2分多钟才能完成。
排查步骤：
1、查看job的stage，发现是在写入kafka处的代码执行时间长
2、查看任务执行情况，并不是所有的任务都长，而是偶尔几个。
3、确定肯定和kafka写入有关系
于是 经过排查，kafka在创建producer的时候，需要获取meta信息，然后创建对应的连接。
并且在获取meta的时候是按照你配置的brokers的地址列表挨个查询，一旦获取到就返回，获取不到就一直等待超时。每次获取的超时时间长度是tcp的超时时间，系统默认的127s。总共尝试6次。以下截图都是我同事找到，这次问题的主要排查也是他
image.png
image.png
所以在等待127s之后，尝试第二个broker,这时候获取成功
，成功创建producer,消费正常。
修复办法：
一 、streamingjob container启动后会一直存在，也就是jvm不会清理，所以可以创建一个静态的producer，这样可以保证同一个应用的不同的batch 的task，可以公用一个producer，而不需要每个batch都去创建一个producer。（推荐）
二、修改获取meta的等待时间 默认是60s
image.png
三、创建producer的时候brokers的地址列表可以打乱
网友评论