现象
近期，参与了一次处理线上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循环入库，导致耗时很长。
经验教训
- 关键的线程池的执行任务超长一定要进行监控
- 如果在消息中间件中插入了一条消息，但这条消息代表了很多条消息，会导致线上出现很严重的偏移
网友评论