Kafka线上单partition积压问题定位
现象
近期,参与了一次处理线上Kafka单partition积压问题的定位处理。总结一下
处理过程
我上线的情况是,16个partition的消息,其中有一个partition的积压特别大,而且该partition所在消费者同时消费者两个partition。
同事反馈之前已经尝试过重启,该partition已经迁移到了其他服务所在的机器,情况仍没有好转。
其实当时就有想过,是否是处理该partition的消息太慢,导致单topic积压,但同事反馈该代码仅仅是插入数据库,而且同时数据库没有任何慢日志。所以没往这个方向继续。
接下来怀疑kafka broker端返回慢,kafka侧开启debug日志查看了fetch和commit,其中有很重要的信息,是两次commit之间间隔大概在20多秒,然后offset差有四五百条消息,这可commit的太慢了。本着代码处理速度正常的思路(该思路已经是错的了,这个时候就应该去追查代码处理慢的问题),接下来我们尝试抓包分析,是否是fetch来回慢导致的,查到fetch其实很快。
唉,接下来我们又尝试了扩容,试图让单partition落到一台机器,排除其他partition的干扰。(从事后来看,这一步也是错误的,浪费了一些时间)
也有这部分处理时长没有监控,打开info日志,难以查找的因素。
然后运气很好,扩容后,单partition确实落到了一台机器上,果然问题没有解决。这个时候打开了INFO日志,另一位同事此时在后台查找到了处理异常的消息,处理时长达数十秒。
之前有抓包,我们打开了抓包,才发现,该代码逻辑支持批量,这条处理数十秒的消息,其实里面有数千条批量消息,在代码中执行了for循环入库,导致耗时很长。
经验教训
- 关键的线程池的执行任务超长一定要进行监控
- 如果在消息中间件中插入了一条消息,但这条消息代表了很多条消息,会导致线上出现很严重的偏移
- 点赞
- 收藏
- 关注作者
评论(0)