【kafka】__consumer_offsets部分分区异常导致消费不到数据问题排查

最新推荐文章于 2024-05-12 19:55:45 发布
最新推荐文章于 2024-05-12 19:55:45 发布
阅读量6.3k 收藏 5
点赞数 5
分类专栏： Kafka 文章标签： kafka java 大数据 分布式 spark
本文为博主原创文章，未经博主允许不得转载。更多精彩，微信公众号关注: 大数据与实时计算!
本文链接：https://blog.csdn.net/u013128262/article/details/105728758
版权

记一次kafka消费异常问题的排查

文章目录

一、问题描述

问题描述

部分消费组无法通过broker(new-consumer)正常消费数据,更改消费组名后恢复正常。

group名(可能涉及业务信息，group名非真实名):

  • group1-打马赛克
  • group2-打马赛克

kafka版本:
0.9.0.1

二、简单分析

1、describe对应消费组

describe对应消费组时抛如下异常:

Error while executing consumer group command The group coordinator is not available.
org.apache.kafka.common.errors.GroupCoordinatorNotAvailableException: The group coordinator is not available.

2、问题搜索

搜索到业界有类似问题,不过都没有解释清楚为什么出现这种问题，以及如何彻底解决(重启不算)!

  • http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/Problem-with-Kafka-0-9-Client-td4975.html

三、深入分析

日志是程序员的第一手分析资料。Kafka服务端因为现网有大量服务在运营，不适合开启debug日志，所以我们只能从客户端入手。

1、开启客户端debug日志

将客户端日志等级开成debug级别,发现持续循环地滚动如下日志:

19:52:41.785 TKD [main] DEBUG o.a.k.c.c.i.AbstractCoordinator - Issuing group metadata request to broker 43
19:52:41.788 TKD [main] DEBUG o.a.k.c.c.i.AbstractCoordinator - Group metadata response ClientResponse(receivedTimeMs=1587642761788, disconnected=false, request=ClientRequest(expectResponse=true, callback=org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient$RequestFutureCompletionHandler@1b68ddbd, request=RequestSend(header={api_key=10,api_version=0,correlation_id=30,client_id=consumer-1}, body={group_id=30cab231-05ed-43ef-96aa-a3ca1564baa3}), createdTimeMs=1587642761785, sendTimeMs=1587642761785), responseBody={error_code=15,coordinator={node_id=-1,host=,port=-1}})
19:52:41.875 TKD [main] DEBUG o.apache.kafka.clients.NetworkClient - Sending metadata request ClientRequest(expectResponse=true, callback=null, request=RequestSend(header={api_key=3,api_version=0,correlation_id=31,client_id=consumer-1}, body={topics=[topic打马赛克]}), isInitiatedByNetworkClient, createdTimeMs=1587642761875, sendTimeMs=0) to node 43

我们大致可以看出循环在做着几件事情(先后不一定准确):

  • 从某个broker Issuing group metadata request
  • 获取Group metadata
  • 发起metadata request

我们聚焦到获取Group metadata的error关键字responseBody={error_code=15,coordinator={node_id=-1,host=,port=-1}},大致得出是kafka服务端没有给出coordinator的node结点信息。

2、服务端如何响应请求

请求对应的入口函数

首先我们需要查看api_key=10请求对应的服务端源码:

需要从kafka.server.KafkaApis中寻找对应的api接口函数

  def handle(request: RequestChannel.Request) {
  ……
        case RequestKeys.GroupCoordinatorKey => handleGroupCoordinatorRequest(request)
  ……
    }

handleGroupCoordinatorRequest逻辑

  def handleGroupCoordinatorRequest(request: RequestChannel.Request) {
    val groupCoordinatorRequest = request.body.asInstanceOf[GroupCoordinatorRequest]
    val responseHeader = new ResponseHeader(request.header.correlationId)

    if (!authorize(request.session, Describe, new Resource(Group, groupCoordinatorRequest.groupId))) {
      val responseBody = new GroupCoordinatorResponse(Errors.GROUP_AUTHORIZATION_FAILED.code, Node.noNode)
      requestChannel.sendResponse(new RequestChannel.Response(request, new ResponseSend(request.connectionId, responseHeader, responseBody)))
    } else {
      val partition = coordinator.partitionFor(groupCoordinatorRequest.groupId)

      // get metadata (and create the topic if necessary)
      val offsetsTopicMetadata = getOrCreateGroupMetadataTopic(request.securityProtocol)
        // 第一个可能存在的问题:offsetsTopicMetadata的errCode不为空
      val responseBody = if (offsetsTopicMetadata.errorCode != Errors.NONE.code) {
        new GroupCoordinatorResponse(Errors.GROUP_COORDINATOR_NOT_AVAILABLE.code, Node.noNode)
      } else {
        val coordinatorEndpoint = offsetsTopicMetadata.partitionsMetadata
          .find(_.partitionId == partition)
          .flatMap {
            partitionMetadata => partitionMetadata.leader
          }
        // 第二个可能存在的问题:coordinatorEndpoint为空
        coordinatorEndpoint match {
          case Some(endpoint) =>
            new GroupCoordinatorResponse(Errors.NONE.code, new Node(endpoint.id, endpoint.host, endpoint.port))
          case _ =>
            new GroupCoordinatorResponse(Errors.GROUP_COORDINATOR_NOT_AVAILABLE.code, Node.noNode)
        }
      }

      trace("Sending consumer metadata %s for correlation id %d to client %s."
        .format(responseBody, request.header.correlationId, request.header.clientId))
      requestChannel.sendResponse(new RequestChannel.Response(request, new ResponseSend(request.connectionId, responseHeader, responseBody)))
    }
  }

其中error_code=15对应的是Errors.GROUP_COORDINATOR_NOT_AVAILABLE.code

从源码不难看出，导致Errors.GROUP_COORDINATOR_NOT_AVAILABLE.code可能点有二:

  • 疑似问题点一:offsetsTopicMetadata的errCode不为空

    offsetsTopicMetadata.errorCode != Errors.NONE.code

    offsetsTopicMetadata的errCode不为空,意味着整个__consumer_offsets元数据获取都有问题。但是现场只是部分group有问题,这里出问题的可能性不大。

  • 疑似问题点二:coordinatorEndpoint为空

    val coordinatorEndpoint = offsetsTopicMetadata.partitionsMetadata
        .find(_.partitionId == partition)
        .flatMap {
          partitionMetadata => partitionMetadata.leader
        }

    从offsetsTopicMetadata获取到的元数据，过滤出coordinator.partitionFor(groupCoordinatorRequest.groupId)分区的leader。而coordinator.partitionFor(groupCoordinatorRequest.groupId)正是与group名相关!这里出问题的可能性极大!

partitionFor相关的逻辑:

  def partitionFor(groupId: String): Int = Utils.abs(groupId.hashCode) % groupMetadataTopicPartitionCount

即取group名的正hashCode模groupMetadataTopicPartitionCount(即__consumer_offsets对应的分区数)。

注:可能涉及业务信息，group名非真实名。而结果是正式group名算出的结果。

scala> "group1-打马赛克".hashCode % 50
res2: Int = 43

scala> "group2-打马赛克".hashCode % 50
res3: Int = 43

我们发现2个异常的消费组,其partitionFor后的值均为43,我们初步判断分区可能与__consumer_offsets的43分区相关!
接下来我们就要看下offsetsTopicMetadata相关的逻辑,来确认异常。

offsetsTopicMetadata的逻辑

val offsetsTopicMetadata = getOrCreateGroupMetadataTopic(request.securityProtocol)

getOrCreateGroupMetadataTopic -> metadataCache.getTopicMetadata -> getPartitionMetadata

  private def getPartitionMetadata(topic: String, protocol: SecurityProtocol): Option[Iterable[PartitionMetadata]] = {
    cache.get(topic).map { partitions =>
      partitions.map { case (partitionId, partitionState) =>
        val topicPartition = TopicAndPartition(topic, partitionId)

        val leaderAndIsr = partitionState.leaderIsrAndControllerEpoch.leaderAndIsr
        val maybeLeader = aliveBrokers.get(leaderAndIsr.leader)

        val replicas = partitionState.allReplicas
        val replicaInfo = getAliveEndpoints(replicas, protocol)

        maybeLeader match {
          case None =>
            debug("Error while fetching metadata for %s: leader not available".format(topicPartition))
            new PartitionMetadata(partitionId, None, replicaInfo, Seq.empty[BrokerEndPoint],
              Errors.LEADER_NOT_AVAILABLE.code)

          case Some(leader) =>
            val isr = leaderAndIsr.isr
            val isrInfo = getAliveEndpoints(isr, protocol)

            if (replicaInfo.size < replicas.size) {
              debug("Error while fetching metadata for %s: replica information not available for following brokers %s"
                .format(topicPartition, replicas.filterNot(replicaInfo.map(_.id).contains).mkString(",")))

              new PartitionMetadata(partitionId, Some(leader.getBrokerEndPoint(protocol)), replicaInfo, isrInfo, Errors.REPLICA_NOT_AVAILABLE.code)
            } else if (isrInfo.size < isr.size) {
              debug("Error while fetching metadata for %s: in sync replica information not available for following brokers %s"
                .format(topicPartition, isr.filterNot(isrInfo.map(_.id).contains).mkString(",")))
              new PartitionMetadata(partitionId, Some(leader.getBrokerEndPoint(protocol)), replicaInfo, isrInfo, Errors.REPLICA_NOT_AVAILABLE.code)
            } else {
              new PartitionMetadata(partitionId, Some(leader.getBrokerEndPoint(protocol)), replicaInfo, isrInfo, Errors.NONE.code)
            }
        }
      }
    }
  }

offsetsTopicMetadata即对于topic下所有leader、replicaInfo、isr正常分区的元数据信息,所以我们判断__consumer_offsets 43分区leader、replicaInfo、isr等可能存在异常,导致find(_.partitionId == partition)时找不到根据hashCode取模后对应的分区。

四、回到现网

1、__consumer_offsets分区信息验证

Topic:__consumer_offsets        PartitionCount:50       ReplicationFactor:3     Configs:segment.bytes=104857600,cleanup.policy=compact,compression.type=uncompressed
        Topic: __consumer_offsets       Partition: 0    Leader: 18      Replicas: 18,2,17       Isr: 18
        Topic: __consumer_offsets       Partition: 1    Leader: 19      Replicas: 19,17,18      Isr: 19,18
        Topic: __consumer_offsets       Partition: 2    Leader: 20      Replicas: 20,18,19      Isr: 19,20,18
        Topic: __consumer_offsets       Partition: 3    Leader: 21      Replicas: 21,19,20      Isr: 19,20,21
        Topic: __consumer_offsets       Partition: 4    Leader: 22      Replicas: 22,20,21      Isr: 20,21,22
        Topic: __consumer_offsets       Partition: 5    Leader: 23      Replicas: 23,21,22      Isr: 23,21,22
        Topic: __consumer_offsets       Partition: 6    Leader: 24      Replicas: 24,22,23      Isr: 23,24,22
        Topic: __consumer_offsets       Partition: 7    Leader: 25      Replicas: 25,23,24      Isr: 23,25,24
        Topic: __consumer_offsets       Partition: 8    Leader: 26      Replicas: 26,24,25      Isr: 26,25,24
        Topic: __consumer_offsets       Partition: 9    Leader: 27      Replicas: 27,25,26      Isr: 27,26,25
        Topic: __consumer_offsets       Partition: 10   Leader: 28      Replicas: 28,26,27      Isr: 27,26,28
        Topic: __consumer_offsets       Partition: 11   Leader: 27      Replicas: 0,27,28       Isr: 27,28
        Topic: __consumer_offsets       Partition: 12   Leader: 28      Replicas: 1,28,0        Isr: 28
        Topic: __consumer_offsets       Partition: 13   Leader: -1      Replicas: 2,0,1 Isr: 
        Topic: __consumer_offsets       Partition: 14   Leader: -1      Replicas: 3,1,2 Isr: 
        Topic: __consumer_offsets       Partition: 15   Leader: -1      Replicas: 4,2,3 Isr: 
        Topic: __consumer_offsets       Partition: 16   Leader: -1      Replicas: 5,3,4 Isr: 
        Topic: __consumer_offsets       Partition: 17   Leader: -1      Replicas: 6,4,5 Isr: 
        Topic: __consumer_offsets       Partition: 18   Leader: -1      Replicas: 7,5,6 Isr: 
        Topic: __consumer_offsets       Partition: 19   Leader: 8       Replicas: 8,6,7 Isr: 8
        Topic: __consumer_offsets       Partition: 20   Leader: 9       Replicas: 9,7,8 Isr: 9,8
        Topic: __consumer_offsets       Partition: 21   Leader: 10      Replicas: 10,8,9        Isr: 10,8,9
        Topic: __consumer_offsets       Partition: 22   Leader: 11      Replicas: 11,9,10       Isr: 11,10,9
        Topic: __consumer_offsets       Partition: 23   Leader: 12      Replicas: 12,10,11      Isr: 11,12,10
        Topic: __consumer_offsets       Partition: 24   Leader: 13      Replicas: 13,11,12      Isr: 13,11,12
        Topic: __consumer_offsets       Partition: 25   Leader: 14      Replicas: 14,12,13      Isr: 13,12,14
        Topic: __consumer_offsets       Partition: 26   Leader: 15      Replicas: 15,13,14      Isr: 13,14,15
        Topic: __consumer_offsets       Partition: 27   Leader: 16      Replicas: 16,14,15      Isr: 14,16,15
        Topic: __consumer_offsets       Partition: 28   Leader: 42      Replicas: 17,15,42      Isr: 42,15
        Topic: __consumer_offsets       Partition: 29   Leader: 18      Replicas: 18,17,19      Isr: 19,18
        Topic: __consumer_offsets       Partition: 30   Leader: 19      Replicas: 19,18,20      Isr: 19,20,18
        Topic: __consumer_offsets       Partition: 31   Leader: 20      Replicas: 20,19,21      Isr: 19,20,21
        Topic: __consumer_offsets       Partition: 32   Leader: 21      Replicas: 21,20,22      Isr: 20,21,22
        Topic: __consumer_offsets       Partition: 33   Leader: 22      Replicas: 22,21,23      Isr: 23,21,22
        Topic: __consumer_offsets       Partition: 34   Leader: 23      Replicas: 23,22,24      Isr: 23,24,22
        Topic: __consumer_offsets       Partition: 35   Leader: 24      Replicas: 24,23,25      Isr: 23,25,24
        Topic: __consumer_offsets       Partition: 36   Leader: 25      Replicas: 25,24,26      Isr: 26,25,24
        Topic: __consumer_offsets       Partition: 37   Leader: 26      Replicas: 26,25,27      Isr: 27,26,25
        Topic: __consumer_offsets       Partition: 38   Leader: 27      Replicas: 27,26,28      Isr: 27,26,28
        Topic: __consumer_offsets       Partition: 39   Leader: 28      Replicas: 28,27,0       Isr: 27,28
        Topic: __consumer_offsets       Partition: 40   Leader: 28      Replicas: 0,28,1        Isr: 28
        Topic: __consumer_offsets       Partition: 41   Leader: -1      Replicas: 1,0,2 Isr: 
        Topic: __consumer_offsets       Partition: 42   Leader: -1      Replicas: 2,1,3 Isr: 
        Topic: __consumer_offsets       Partition: 43   Leader: -1      Replicas: 3,2,4 Isr: 
        Topic: __consumer_offsets       Partition: 44   Leader: -1      Replicas: 4,3,5 Isr: 
        Topic: __consumer_offsets       Partition: 45   Leader: -1      Replicas: 5,4,6 Isr: 
        Topic: __consumer_offsets       Partition: 46   Leader: -1      Replicas: 6,5,7 Isr: 
        Topic: __consumer_offsets       Partition: 47   Leader: 8       Replicas: 7,6,8 Isr: 8
        Topic: __consumer_offsets       Partition: 48   Leader: 8       Replicas: 8,7,9 Isr: 9,8
        Topic: __consumer_offsets       Partition: 49   Leader: 9       Replicas: 9,8,10        Isr: 10,9,8

43分区果然存在leader异常的情况

2、问题复现

我们使用UUID批量生成消费组名,使其hashCode取模后为异常分区的分区号,再使用其进行消费时均出现消费异常的问题。

3、问题思考

  • 为什么__consumer_offsets部分分区会产生leader、replicaInfo、isr异常?
    与网络抖动和一些集群操作可能有关，需要具体问题具体分析

  • 如何将__consumer_offsets异常分区恢复正常？
    这里不详细介绍可以参考http://blog.itpub.net/31543630/viewspace-2212467/ 。

五、参考资料

  • Kafka new-consumer设计文档 https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Detailed+Consumer+Coordinator+Design

  • Kafka无法消费?!我的分布式消息服务Kafka却稳如泰山！ http://blog.itpub.net/31543630/viewspace-2212467/

  • Problem with Kafka 0.9 Client http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/Problem-with-Kafka-0-9-Client-td4975.html

  • ErrorMapping https://github.com/apache/kafka/blob/0.9.0/core/src/main/scala/kafka/common/ErrorMapping.scala

pierre94
关注
  • 5
    点赞
  • 踩
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
【kafka】一次磁盘故障后消费者无法消费
九师兄
01-04 881
1.概述 转载：Kafka 运维纪实 – 一次磁盘故障后消费者无法消费 Kafka 自从某个版本加入 isr 等机制后真是越来越复杂了，再也不是原来那个单纯的 The log 了，碰上网络有个什么风吹草动经常耍点小脾气，不过小脾气就是小脾气，过会儿一般自己就好了，最多重启一下 Broker 也能自动恢复。不过这次好像真的生气了，大年初二一大早就看到 RCA 群里热闹非凡，有8台 Broker 嗝屁了。额，shit ，大年初二诶，还让人过年不了。 由于过年回老家，进了山区，左上角的4G图标一直显示成E，.
Storm消费Kafka异常 - topic其中两个分区达到某个值不进行消费，持续阻塞
jast
01-15 2540
Kafka消费storm，突然有两个分区无法消费数据(或重复消费无法提交offset) offset是我们自己进行管理，kafka日志也是正常没有报错，storm日志也是没有报错~ 就是卡住了 1.尝试将partition为0,1的offset记录删除，重新跑一遍，结果还是到那个offset处卡住 2.再次尝试手动修改offset跳过卡住的那一条数据(这种做法会丢失一条数据,在数据不允许...
在IDEA上使用Flink 无法消费Kafka 【一段时间后报错：TimeoutException: Timed out waiting for a node assignment. Call: d】
最新发布
2202_75658539的博客
05-12 628
记录自己在学习Flink中遇到一个问题，在IDEA上写Flink消费者，想要消费Kafka，可是在Kafka生产者模式下生产数据却无法正常被消费 确认了消费Kafka的服务器参数(setBootstrapServers)，和消费主题(setTopics)无误后 确认了zookeeper和kafka已经开启
kafka出现若干分区不消费的现象
u010952362的博客
01-02 1万+
kafka出现若干分区不消费的现象背景定位过程验证解决方法 背景 近日，有用户反馈kafka有topic出现某个消费组消费的时候，有几个分区一直不消费消息，消息一直积压（图1）。除了一直积压外，还有一个现象就是消费组一直在重均衡，大约每5分钟就会重均衡一次。具体表现为消费分区的owner一直在改变（图2）。 （图1） （图2） 定位过程 业务侧没有报错，同时kafka服务端日志也一切正常，同事...
Kafka一个节点挂掉，导致服务不可消费
李振伟的博客
09-14 3951
kafka集群，一个节点挂掉，导致不可消费； kafka修改默认副本数； kafka为现有topic扩副本。
Kafka某Topic的部分partition无法消费问题
clz1314521的专栏
06-04 3042
今天同事反馈有个topic出现积压。于是上kfk管理平台查看该topic对应的group。发现6个分区中有2个不消费，另外4个消费也较慢，总体lag在增长。查看服务器日志，日志中有rebalance 12 retry。Exception，之后改消费线程停止。于是分析代码，将每个处理逻辑加上耗时日志，分析发现又是hbase写入耗时达到3秒。于是将hbase写入开关关闭。重新运行后，消费正常。
记一次Kafka不能消费故障
微步的博客
10-30 9636
背景： kafka集群机器升级，使得部分spark Streaming不能消费读取数据 问题原因： kafka会自动创建一个默认的topic __consumer_offsets，用于保存offset到Kafka系统 由于我们集群kafka节点有7个，当逐渐的下架上架机器后，使得__consumer_offsets  Partition 出现Leader为-1 Kafka将直连Kaf...
kafka_exporter-1.6.0.linux-amd64.tar.gz
09-06
centos kafka_exporter kafka_exporter-1.6.0.linux-amd64.tar
kafka.rar_DEMO_avro_consumer_kafka_producer
07-13
kafka的生产消费示例程序，其中数据生产时需要avro序列化，消费时需要反序列化
kafka_2.11-0.10.2.0.tar.gz
06-10
kafka_2.11-0.10.2.0 版解压使用 kafka kafka kafka kafka kafka
kafka_hdfs_consumer
07-04
kafka_hdfs_consumer实现
kafka资源下载kafka_2.11-2.0.0.tgz
09-18
kafka_2.11-2.0.0.tgz .
记一次由于__consumer_offset导致的Kafka故障
Ricky点滴
05-30 7384
记一次Kafka故障 2018.05.30 Kafka 0.10.0.10 背景介绍 因Kafka集群中一个节点宕机，因集群高可用机制集群工作正常，但是发现部分消费者无法读取到数据 故障原因 Kafka将直连Kafka的消费信息记录到了__consumer_offset这个topic中，这个topic在我们的集群中复制因子为1，并且所有的Partition落在了...
kafka_consumer不消费数据的问题排查
sunlang的博客
11-19 5966
背景： 初始的时候，在cdh中部署了kafka集群 后来方案改为kafka消息平台和cdh中的hive，spark等计算平台分离 由于之前的kafka部署配置，污染到后面的apache的kafka集群，使得其消费不到消息 我们查看__consumer_offsets 这个topic情况 我们apach kafka中的broker根本没有123，这个是cdh中的配置 实际的三个brokerid是0，1，2 停掉集群，在zookeeper中删除 rmr /brokers/topics/__co
启动kafka无反应_kafka consumer无法正常启动原因调查
weixin_31773159的博客
12-23 2511
生产环境三个服务分别消费kafka(version 1.1.0)不同topic里的日志分析结果，将其写入HBase，其中消费kafka使用的是consumer的subscribe API。服务稳定运行了几个月，某次因为HBase升级将其临时关闭，在重新启动过程中，诡异的问题发生了。现象三个服务中有一个可以正常启动，另外两个在启动过程中似乎卡在某个地方block住。打开info级别的日志，发现如下可...
【Kafka】kafka动态获取某个topic的partition信息
热门推荐
三也_攻城狮
05-17 1万+
无意中发现了一个巨牛的人工智能教程，忍不住分享一下给大家。教程不仅是零基础，通俗易懂，而且非常风趣幽默，像看小说一样！觉得太牛了，所以分享给大家。点这里可以跳转到教程。 现在有这样一种场景，系统启动前，预期abc topic创建了一个100个分区，大概用个一段时间，之后可能会动态新增分区数，这就要求生产者在生产数据时，能够动态实时的获取分区数，做到及时有效的哈希生效，让数据进入新增的分区，kaf...
解决kafka集群由于默认的__consumer_offsets这个topic的默认的副本数为1而存在的单点故障问题
TPH_BETTER.的博客
05-18 1444
转自：https://blog.51cto.com/u_15278282/4896623 解决kafka集群由于默认的__consumer_offsets这个topic的默认的副本数为1而存在的单点故障问题 抛出问题： __consumer_offsets这个topic是由kafka自动创建的，默认50个，但是都存在一台kafka服务器上，这是不是就存在很明显的单点故障？ 经测试，如果将存储__consumer_offsets的这台机器kill掉，所有的消费者都停止消费了。请问这个问题是怎么解决的呢？ 原因
【Kafka】Offset存储机制、__consumer_offsets
m0_45406092的博客
07-04 4470
文章目录1. 为什么需要存储Offset2. __consumer_offsets2.1 OffsetCommitRequest2.1.1 Key 和 Value2.2 OffsetCommitResponse2.3 查看__consumer_offsets中的消息3. offset要提交到__consumer_offsets的哪个分区参考 1. 为什么需要存储Offset 由于消费者在消费消息的时候可能会由于各种原因而断开消费，当重新启动消费者时我们需要让它接着上次消费的位置offset继续消费，因此消
kafka __consumer_offsets 详细
06-08
`__consumer_offsets`是Kafka内部的一个主题，用于保存消费者组的消费进度。每个消费者组都有一个对应的`__consumer_offsets`主题，其中每个分区都对应一个消费者组的一个分区，并记录了该消费者组在该分区中消费的最新位置（即offset）。 `__consumer_offsets`主题的格式为`(group, topic, partition)`，其中`group`表示消费者组的名称，`topic`表示该主题所属的topic名称，`partition`表示该主题的分区编号。每个`__consumer_offsets`主题的消息都包含了以下信息： - `group`: 消费者组的名称 - `topic`: 该消息所属的topic名称 - `partition`: 该消息所属的分区编号 - `offset`: 消费者组在该分区中的最新消费位置 - `timestamp`: 消费者组在该分区中消费的时间戳 - `metadata`: 可选字段，包含了消费者组的其他元数据信息 Kafka的消费者会定期地更新`__consumer_offsets`主题中的offset，以便下次消费时从正确的位置开始消费。消费者也可以手动更新`__consumer_offsets`主题中的offset，从而实现手动管理offset的功能。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值