2018年05月31日 13:26:59 xiaoguozi0218 阅读数：2018更多
年后上线的系统，与其他业务系统的通信方式采用了第三代消息系统中间件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.