当前位置: 首页 > 知识库问答 >
问题:

重新平衡后停止使用来自新分配分区的消息

翟俊名
2023-03-14
bin/kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 5 --topic tracking
kafka.servers.bootstrap=localhost:9092 
kafka.topic.tracking=tracking
kafka.group.id=trackingGroup
kafka.client.id=client-1
client-1: partitions assigned:[tracking-4, tracking-3]
client-2: partitions assigned:[tracking-2, tracking-1]
client-3: partitions assigned:[tracking-0]
client-1: partitions assigned:[]
client-2: partitions assigned:[tracking-2,tracking-1, tracking-0]
client-3: partitions assigned:[tracking-4,tracking-3]

我发现分区“Tracking-3”上的消息没有被消耗!!

问题每次都会重现,在新分配的分区中有一些消息丢失,你能有什么建议吗?请帮帮我,谢谢

共有1个答案

姜德容
2023-03-14

我复制了它;这看起来像是kafka本身的问题(auto.comit.enabled=true)在重新平衡中,kafka报告未读分区的“位置”(将获取的下一条记录的偏移量(如果存在具有该偏移量的记录))作为分区的末尾。

事实上,当我使用kafka-consumer-groups工具时,未读分区的偏移量已经在“末尾”了。当我只使用一个用户运行它时,当它读取第一个分区时,我看到...

$ kafka-consumer-groups --bootstrap-server localhost:9092 --describe -group so43405009

TOPIC                          PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG        CONSUMER-ID                                       HOST                           CLIENT-ID
tracking                       0          37              40              3          client1-8129bb3d-3a83-4c83-9128-3a2762ede758      /10.0.0.6                      client1
tracking                       1          40              40              0          client1-8129bb3d-3a83-4c83-9128-3a2762ede758      /10.0.0.6                      client1
tracking                       2          40              40              0          client1-8129bb3d-3a83-4c83-9128-3a2762ede758      /10.0.0.6                      client1
tracking                       3          40              40              0          client1-8129bb3d-3a83-4c83-9128-3a2762ede758      /10.0.0.6                      client1
tracking                       4          40              40              0          client1-8129bb3d-3a83-4c83-9128-3a2762ede758      /10.0.0.6                      client1

注意CURRENT_OFFSET列。

TOPIC                          PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG        CONSUMER-ID                                       HOST                           CLIENT-ID
tracking                       0          41              44              3          client1-56d78a4b-f2df-4e31-8c5d-f8a1d8f64cf8      /10.0.0.6                      client1
tracking                       1          44              44              0          client1-56d78a4b-f2df-4e31-8c5d-f8a1d8f64cf8      /10.0.0.6                      client1
tracking                       2          44              44              0          client1-56d78a4b-f2df-4e31-8c5d-f8a1d8f64cf8      /10.0.0.6                      client1
tracking                       3          44              44              0          client1-56d78a4b-f2df-4e31-8c5d-f8a1d8f64cf8      /10.0.0.6                      client1
tracking                       4          44              44              0          client1-56d78a4b-f2df-4e31-8c5d-f8a1d8f64cf8      /10.0.0.6                      client1
TOPIC                          PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG        CONSUMER-ID                                       HOST                           CLIENT-ID
tracking                       0          44              44              0          client1-56d78a4b-f2df-4e31-8c5d-f8a1d8f64cf8      /10.0.0.6                      client1
tracking                       1          44              44              0          client1-56d78a4b-f2df-4e31-8c5d-f8a1d8f64cf8      /10.0.0.6                      client1
tracking                       2          41              44              3          client1-56d78a4b-f2df-4e31-8c5d-f8a1d8f64cf8      /10.0.0.6                      client1
tracking                       3          44              44              0          client1-56d78a4b-f2df-4e31-8c5d-f8a1d8f64cf8      /10.0.0.6                      client1
tracking                       4          44              44              0          client1-56d78a4b-f2df-4e31-8c5d-f8a1d8f64cf8      /10.0.0.6                      client1
spring.kafka.consumer.enable-auto-commit=false
TOPIC                          PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG        CONSUMER-ID                                       HOST                           CLIENT-ID
tracking                       0          52              52              0          client1-59413599-81e8-49dd-bbd7-8a62152f11e5      /10.0.0.6                      client1
tracking                       1          49              52              3          client1-59413599-81e8-49dd-bbd7-8a62152f11e5      /10.0.0.6                      client1
tracking                       2          49              52              3          client2-edfe34f9-08d5-4825-80d0-4a6cf9526e42      /10.0.0.6                      client2
tracking                       3          48              52              4          client2-edfe34f9-08d5-4825-80d0-4a6cf9526e42      /10.0.0.6                      client2
tracking                       4          51              52              1          client3-20da8742-af38-403e-b125-5d0c7c771319      /10.0.0.6                      client3
@SpringBootApplication
public class So43405009Application implements CommandLineRunner {

    public static void main(String[] args) {
        SpringApplication.run(So43405009Application.class, args);
    }

    @Autowired
    private KafkaTemplate<String, String> template;

    @Value("${spring.kafka.consumer.client-id}")
    private String clientId;

    @Override
    public void run(String... args) throws Exception {
        if (this.clientId.endsWith("1")) {
            for (int i = 0; i < 20; i++) {
                this.template.sendDefault("foo" + i);
            }
        }
    }

    @Bean
    public KafkaMessageListenerContainer<String, String> container(ConsumerFactory<String, String> cf) {
        ContainerProperties containerProperties = new ContainerProperties("tracking");
        containerProperties.setMessageListener((MessageListener<?, ?>) d -> {
            System.out.println(d);
            try {
                Thread.sleep(5_000);
            }
            catch (InterruptedException e) {
                Thread.currentThread().interrupt();
            }
        });
        KafkaMessageListenerContainer<String, String> container = new KafkaMessageListenerContainer<>(cf,
                containerProperties);
        return container;
    }

}
spring.kafka.listener.ack-mode=record
spring.kafka.consumer.enable-auto-commit=false
spring.kafka.consumer.auto-offset-reset=earliest
spring.kafka.consumer.group-id=so43405009
spring.kafka.consumer.client-id=client1
spring.kafka.template.default-topic=tracking

编辑

原来是Spring-Kafka的虫子;它在启用自动提交的情况下工作,但您必须显式启用它

spring.kafka.consumer.enable-auto-commit=true

否则,容器假定它是false,并导致上述奇怪的行为--如果启用了自动提交,那么看起来客户机不喜欢调用使用者的提交方法。#288。

 类似资料:
  • 本文向大家介绍消费组与分区重平衡相关面试题,主要包含被问及消费组与分区重平衡时的应答技巧和注意事项,需要的朋友参考一下 当有新的消费者加入到消费者组时,原本的分区就需要重新分配;比如一个topic有30个分区,原本只有两个消费者,每人负责15个分区,当新加入一个消费者时,并没有分区可以给他消费,只能是将30个分区重新分配。 每个消费者组都会有一个broker负责协调(称为group coordin

  • 我遇到了一件关于Kafka再平衡的奇怪事情。如果我增加某个主题的分区,而该主题是由一些java使用者(在同一个组中)订阅的,则不会发生使用者再平衡。在那之后,我试图通过启动一个新的消费者(或杀死一个消费者)来实现重新平衡,但在这个重新平衡中无法分配新增加的分区。我发现只有在停止所有使用者并启动它们之后,才能分配新分区。我不知道这是正常还是有任何解释。 下面是我在电脑上的测试: 1.启动Kafka,

  • 场景: 运行从名为“test”的具有10个分区的分区中消耗的Spring Boot项目。分区分配发生在13:00:00 在~13:00:30使用: 在~13:05:30触发分区重新分配。 我运行了几次这些步骤,看起来每5分钟就有一次重新分配 是否有办法更改重新分配检查操作频率 编辑: 我的用例如下:我们有引导微服务的集成测试。当主题的使用者首先引导时,如果主题不存在并且它创建的分区数等于配置的并发

  • 根据Kafka的文件: kafka保证主题分区只分配给组中的一个消费者。 但我在服务中观察到了不同的行为。以下是一些细节: 我用的是Kafka2.8和SpringKafka2.2.13。 最初我有一个Kafka主题包含5个分区,这个主题在我的服务中使用了Spring和ConcurrentKafkAlisterContainerFactory中的注释,并发性=5。这个配置对我来说很好。 后来,我开始

  • 我们有一个相对简单的分片MongoDB设置:4个分片,每个分片是一个副本集,至少有3个成员。每个集合都由从大量文件加载的数据组成;每个文件都被赋予一个单调递增的ID,并且根据ID的哈希完成分片。 我们的大部分产品都在按预期工作。然而,我有一个集合似乎没有正确地将块分布到各个碎片上。在创建索引之前,集合加载了大约30GB的数据,并且进行了分片,但是据我所知,这并不重要。以下是该集合的统计数据: 这个

  • 首先,很抱歉,如果我的术语不准确,我对Kafka很陌生,我已经尽可能多地读过了。我们有一个使用kafkastreams的服务,kafka版本:2.3.1。流应用程序具有一个流拓扑,该流拓扑从“topica”读取,执行转换并发布到另一个主题“topicb”,然后由拓扑的另一个流消费,并使用Ktable(localstore)聚合它。侦听器将ktable更改发布到另一个主题中。 主题有24个分区。我们