记一次线上Kafka消息堆积踩坑总结

时间:2021-11-30 10:34:53

2018年05月31日 13:26:59 xiaoguozi0218 阅读数:2018更多

个人分类: 大数据

年后上线的系统,与其他业务系统的通信方式采用了第三代消息系统中间件Kafka。由于是第一次使用,踩了很多坑,通过这篇博客和大家分享一下,也算是做个总结,以便以后温故而知新。

一、线上问题

系统平稳运行两个多月,基本上没有问题,知道最近几天,突然出现Kafka手动提交失败,堆栈信息如下:

记一次线上Kafka消息堆积踩坑总结

通过堆栈信息可以看出,有两个重要参数: session.timeout  和 max.poll.records

session.timeout.ms : 在使用Kafka的团队管理设施时,用于检测消费者失败的超时时间。消费者定期发送心跳来向经纪人表明其活跃度。如果代理在该会话超时到期之前没有收到心跳,那么代理将从该组中删除该消费者并启动重新平衡。

max.poll.records : 在一次调用poll()中返回的最大记录数。

根据堆栈的提示,他让增加 session.timeout.ms 时间 或者 减少 max.poll.records。

二、解决过程

然后我琢磨,上线两个月都没有问题,为什么最近突然出现问题了。我想肯定是业务系统有什么动作,我就去问了一个下,果然头一天风控系统kafka挂掉了,并进行了数据重推,导致了数据阻塞。但是我又想即使阻塞了也会慢慢消费掉牙,不应该报错呀。后来我看了一下kafka官网上的参数介绍,发现max.poll.records默认是2147483647 (0.10.0.1版本),也就是kafka里面有多少poll多少,如果消费者拿到的这些数据在制定时间内消费不完,就会手动提交失败,数据就会回滚到kafka中,会发生重复消费的情况。如此循环,数据就会越堆越多。后来咨询了公司的kafka大神,他说我的kafka版本跟他的集群版本不一样让我升级kafka版本。于是我就升级到了0.10.2.1,查阅官网发现这个版本的max.poll.records默认是500,可能kafka开发团队也意识到了这个问题。并且这个版本多了一个max.poll.interval.ms这个参数,默认是300s。这个参数的大概意思就是kafka消费者在一次poll内,业务处理时间不能超过这个时间。后来升级了kafka版本,把max.poll.records改成了50个之后,上了一次线,准备观察一下。上完线已经晚上9点了,于是就打卡回家了,明天看结果。第二天早起满心欢喜准备看结果,以为会解决这个问题,谁曾想还是堆积。我的天,思来想去,也想不出哪里有问题。于是就把处理各个业务的代码前后执行时间打印出来看一下,添加代码,提交上线。然后观察结果,发现大部分时间都用在数据库IO上了,并且执行时间很慢,大部分都是2s。于是想可能刚上线的时候数据量比较小,查询比较快,现在数据量大了,就比较慢了。当时脑子里第一想法就是看了一下常用查询字段有没有添加索引,一看没有,然后马上添加索引。加完索引观察了一下,处理速度提高了好几倍。虽然单条业务处理的快乐, 但是堆积还存在,后来发现,业务系统大概1s推送3、4条数据,但是我kafka现在是单线程消费,速度大概也是这么多。再加上之前的堆积,所以消费还是很慢。于是业务改成多线程消费,利用线程池,开启了10个线程,上线观察。几分钟就消费完了。大功告成,此时此刻,心里舒坦了好多。不容易呀!

总结:

1、 使用Kafka时,消费者每次poll的数据业务处理时间不能超过kafka的max.poll.interval.ms,该参数在kafka0.10.2.1中的默认值是300s,所以要综合业务处理时间和每次poll的数据数量。

2、Java线程池大小的选择,

对于CPU密集型应用,也就是计算密集型,线程池大小应该设置为CPU核数+1;

对于IO密集型应用 ,线程池大小设置为    2*CPU核数+1.