你说通过Kafka AdminClient获取Lag会有性能问题？尊嘟假嘟0.o

0.前言

前阵子团队里出了个大故障，本质是因为其他语言实现的client有问题，非常频繁的请求大量元数据，而Kafka服务端这边也没有做什么限制，导致Kafka Broker宕了。

在相关的复盘报告中，复盘方提到了我这边的监控程序（用于观察线上实时作业的堆压）会频繁的去获取一些元数据，也是在间接的增加Kafka集群的压力，建议修改成消费__consumer_offsets的方式。（我这边用的是AdminClient#listConsumerGroupOffsets和AdminClient.listOffsets来获取commit和end的offset）

这个事老哥之前有和我沟通过几次，那时我问他：你这边有什么根据吗？他没有正面回答我——听说这老哥之前在别的地方维护过很大的Kafka集群，对此我半信半疑的在网上搜索过一阵子，但是并没有找到对应的答案。

直到这次，我这边的监控程序被要求整改。对此我觉得莫名其妙，于是有了这篇文章——我们来扒一扒源码。

本文的代码基于Kafka 3.9。

消费__consumer_offsets本质上来说就是Consumer顺序读Broker上的日志，消费过程这块网上源码解析非常多，总体来说代价也不大，就不再赘述了。我们直接来看AdminClient上的实现。

1.AdminClient相关源码分析

1.1 AdminClient#listConsumerGroupOffsets

这边整理了一份核心面试笔记包括了：Java面试、Spring、JVM、MyBatis、Redis、MySQL、并发编程、微服务、Linux、Springboot、SpringCloud、MQ、Kafka 面试专题

 需要全套面试笔记的【点击此处即可】免费获取

bash

代码解读

复制代码

|--ListConsumerGroupOffsetsHandler |--ApiKeys.OFFSET_FETCH \--handleOffsetFetchRequest \--handleOffsetFetchRequestFromCoordinator \--handleOffsetFetchRequestFromZookeeper

在早期版本中，kafka的元数据是保存在的zk里的。为了更全面的带大家阅读代码，我们把两个实现都读一遍。

From KRaft

bash

代码解读

复制代码

\--fetchOffsetsForGroup |--GroupCoordinatorAdapter \-- fetchOffsets \--handleFetchOffset |--GroupCoordinator \--handleFetchOffsets |--GroupmetadataManager \--getOffsets

那么从getOffsets的实现为：

vbnet

代码解读

复制代码

def getOffsets(groupId: String, requireStable: Boolean, topicPartitionsOpt: Option[Seq[TopicPartition]]): Map[TopicPartition, PartitionData] = { trace("Getting offsets of %s for group %s.".format(topicPartitionsOpt.getOrElse("all partitions"), groupId)) val group = groupMetadataCache.get(groupId) if (group == null) { topicPartitionsOpt.getOrElse(Seq.empty[TopicPartition]).map { topicPartition => val partitionData = new PartitionData(OffsetFetchResponse.INVALID_OFFSET, Optional.empty(), "", Errors.NONE) topicPartition -> partitionData }.toMap } else { group.inLock { if (group.is(Dead)) { topicPartitionsOpt.getOrElse(Seq.empty[TopicPartition]).map { topicPartition => val partitionData = new PartitionData(OffsetFetchResponse.INVALID_OFFSET, Optional.empty(), "", Errors.NONE) topicPartition -> partitionData }.toMap } else { val topicPartitions = topicPartitionsOpt.getOrElse(group.allOffsets.keySet) topicPartitions.map { topicPartition => if (requireStable && group.hasPendingOffsetCommitsForTopicPartition(topicPartition)) { topicPartition -> new PartitionData(OffsetFetchResponse.INVALID_OFFSET, Optional.empty(), "", Errors.UNSTABLE_OFFSET_COMMIT) } else { val partitionData = group.offset(topicPartition) match { case None => new PartitionData(OffsetFetchResponse.INVALID_OFFSET, Optional.empty(), "", Errors.NONE) case Some(offsetAndMetadata) => new PartitionData(offsetAndMetadata.offset, offsetAndMetadata.leaderEpoch, offsetAndMetadata.metadata, Errors.NONE) } topicPartition -> partitionData } }.toMap } } } }

在这里我们可以看到，相关的信息其实从groupMetadataCache这个内存缓存中获取的， 并不是一个很重的操作。而缓存的load方法是loadGroupsAndOffsets，因为篇幅原因，不再展开，有兴趣的同学可以自行阅读。

From Zookeeper

逻辑非常简单，直接粘代码：

scss

代码解读

复制代码

private def handleOffsetFetchRequestFromZookeeper(request: RequestChannel.Request): CompletableFuture[Unit] = { val header = request.header val offsetFetchRequest = request.body[OffsetFetchRequest] def createResponse(requestThrottleMs: Int): AbstractResponse = { val offsetFetchResponse = // reject the request if not authorized to the group if (!authHelper.authorize(request.context, DESCRIBE, GROUP, offsetFetchRequest.groupId)) offsetFetchRequest.getErrorResponse(requestThrottleMs, Errors.GROUP_AUTHORIZATION_FAILED) else { val zkSupport = metadataSupport.requireZkOrThrow(KafkaApis.unsupported("Version 0 offset fetch requests")) val (authorizedPartitions, unauthorizedPartitions) = partitionByAuthorized( offsetFetchRequest.partitions.asScala, request.context) // version 0 reads offsets from ZK val authorizedPartitionData = authorizedPartitions.map { topicPartition => try { if (!metadataCache.contains(topicPartition)) (topicPartition, OffsetFetchResponse.UNKNOWN_PARTITION) else { val payloadOpt = zkSupport.zkClient.getConsumerOffset(offsetFetchRequest.groupId, topicPartition) payloadOpt match { case Some(payload) => (topicPartition, new OffsetFetchResponse.PartitionData(payload, Optional.empty(), OffsetFetchResponse.NO_METADATA, Errors.NONE)) case None => (topicPartition, OffsetFetchResponse.UNKNOWN_PARTITION) } } } catch { case e: Throwable => (topicPartition, new OffsetFetchResponse.PartitionData(OffsetFetchResponse.INVALID_OFFSET, Optional.empty(), OffsetFetchResponse.NO_METADATA, Errors.forException(e))) } }.toMap val unauthorizedPartitionData = unauthorizedPartitions.map(_ -> OffsetFetchResponse.UNAUTHORIZED_PARTITION).toMap new OffsetFetchResponse(requestThrottleMs, Errors.NONE, (authorizedPartitionData ++ unauthorizedPartitionData).asJava) } trace(s"Sending offset fetch response $offsetFetchResponse for correlation id ${header.correlationId} to client ${header.clientId}.") offsetFetchResponse } requestHelper.sendResponseMaybeThrottle(request, createResponse) CompletableFuture.completedFuture[Unit](()) }

首先检查用户是否被授权访问指定的组，如果没有授权，则返回授权失败的错误响应。然后根据请求中的分区信息，将分区分为授权和未授权的分区。对于授权的分区，尝试从ZooKeeper中获取消费偏移量，并根据结果生成相应的分区数据。如果出现异常，则生成一个包含无效偏移量的分区数据。最后将授权和未授权的分区数据合并，并将响应发送回客户端。

1.2 AdminClient#listOffsets

bash

代码解读

复制代码

|--ListOffsetsHandler |--ApiKeys.LIST_OFFSETS \--handleListOffsetRequest \--handleListOffsetRequestV0 \--handleListOffsetRequestV1AndAbove

这里也分成了两个版本，引入KRaft之前是handleListOffsetRequestV0，之后则是handleListOffsetRequestV1AndAbove。除了在部分功能支持的差异和错误处理更加细致外，核心调用的replicaManager.fetchOffsetForTimestamp并无变化。而这个函数的底层实现本质是调用Kafka Log，即去Broker的Log上查询相关的信息。

2.小结

listConsumerGroupOffsets这个命令在KRaft之前的实现是读取Zookeeper，但由于ZK存储的特性，小量点查的代价并不大。如果在启用KRaft的情况下，并不是什么性能瓶颈。

而listOffsets则是通过Kafka Broker读取对应Topic Partition中的Log实现的，相比Consumer消费__consumer_offsets来说，性能在其之下——如果进行大频次的读，本质上来说是在做随机IO读，是比不上消费__consumer_offsets的顺序读的。如果高频次的做读取操作，是一定会引起IO压力的。