问题起因

前些天生产上的一套Kafka集群吞吐量异常高，根据Grafana监控发现主要数据TPS来自 __consumer_offsets队列。

其他业务TOPIC总TSP才几百+，而kafka内部Topic __consumer_offsets 达到33.85k，这现象明显不正常啊。

排查思路

首先怀疑是不是监控出问题了，Prometheus Exporter有bug? 还是Grafana Metrics写错了？又看了看其他集群的监控，发现并不是监控工具的问题。

然后登陆到kafka集群后台服务器，查看一下这个topic的LOG-END-OFFSET情况，使用kafka命令行工具kafka-consumer-groups.sh，间隔5分钟采集多次，然后计算一下每秒的增量，发现和监控显示的吞吐量基本吻合。

__consumer_offsets 22         -               2729106         -               consumer-10656153-9fd2bbbb-6e4f-41d1-9b60-2bbcf387bd65 /xxx.xxx.xxx    consumer-10656153
__consumer_offsets 30         -               0               -               consumer-10656153-9fd2bbbb-6e4f-41d1-9b60-2bbcf387bd65 /xxx.xxx.xxx    consumer-10656153
__consumer_offsets 8          -               2902605         -               consumer-10656153-9fd2bbbb-6e4f-41d1-9b60-2bbcf387bd65 /xxx.xxx.xxx    consumer-10656153
__consumer_offsets 21         -               0               -               consumer-10656153-9fd2bbbb-6e4f-41d1-9b60-2bbcf387bd65 /xxx.xxx.xxx    consumer-10656153
__consumer_offsets 4          -               26901884        -               consumer-10656153-9fd2bbbb-6e4f-41d1-9b60-2bbcf387bd65 /xxx.xxx.xxx    consumer-10656153
__consumer_offsets 27         -               1173895         -               consumer-10656153-9fd2bbbb-6e4f-41d1-9b60-2bbcf387bd65 /xxx.xxx.xxx    consumer-10656153
__consumer_offsets 7          -               829529641       -               consumer-10656153-9fd2bbbb-6e4f-41d1-9b60-2bbcf387bd65 /xxx.xxx.xxx    consumer-10656153
__consumer_offsets 9          -               1788460542      -               consumer-10656153-9fd2bbbb-6e4f-41d1-9b60-2bbcf387bd65 /xxx.xxx.xxx    consumer-10656153
__consumer_offsets 46         -               0               -               consumer-10656153-9fd2bbbb-6e4f-41d1-9b60-2bbcf387bd65 /xxx.xxx.xxx    consumer-10656153
__consumer_offsets 25         -               0               -               consumer-10656153-9fd2bbbb-6e4f-41d1-9b60-2bbcf387bd65 /xxx.xxx.xxx    consumer-10656153
......

顺便说一下Kafka的内部队列 __consumer_offsets的作用，kafka默认将这个topic分成了50个partition，用于存储consumer group每次commit的offset信息，目的是为了在consumer重启后或者在增减消费者时，可以根据此offset信息继续消费。
Consumer Group 对应Partition计算规则：Math.abs(groupID.hashCode()) % numPartitions
Topic中存储的消息格式：[Group, Topic, Partition]::[OffsetMetadata[Offset, Metadata], CommitTime, ExpirationTime]

分析到了这里，造成__consumer_offsets吞吐量过高的真相只有一个了，就是业务端的应用服务中的consumer group提交的频次过高。

既然已经定位了问题了 ，那么去追查具体服务就OK了吧，现实情况显然不是这样的，使用这套kafka集群的平台是一个非常庞大的业务系统，150+的微服务，具体哪些服务和kafka相关，哪些是消费者，估计都得梳理几天。。。

分析工具

既然已经知道问题产生的原因，同时也了解kafka内部队列__consumer_offsets的存储策略，那么写个程序去读取该topic的消息，然后分析哪些consumer group的提交频次过高，根据group name便可以直接定位具体是哪个微服务了。

coding......

开始表演show time.......

根据定位到的异常微服务排查发现，有使用offset自动提交，但是auto.commit.interval设置了100ms，也有使用手动提交offset，但无数据消费时仍然提交offset。。。太坑了

此后，代码质量的checkpoint项中增加关于kafka使用的检查。

最后分享一下工具GitHub地址：kafka-offset-consumer