当前位置: 首页 > 面试题库 >

消费组与分区重平衡

刘泰
2023-03-14
本文向大家介绍消费组与分区重平衡相关面试题,主要包含被问及消费组与分区重平衡时的应答技巧和注意事项,需要的朋友参考一下

当有新的消费者加入到消费者组时,原本的分区就需要重新分配;比如一个topic有30个分区,原本只有两个消费者,每人负责15个分区,当新加入一个消费者时,并没有分区可以给他消费,只能是将30个分区重新分配。

每个消费者组都会有一个broker负责协调(称为group coordinator),各个消费者通过发送心跳的方式向组协调者同步状态,当有消费者一定时间没有给组协调者发送心跳或者有新的消费者加入到消费者组时,就会触发消费组的重平衡操作。

新加入消费者触发重平衡: 1.新加入消费者向组协调者发送joinGroup请求,携带订阅的topic信息 2.此后组协调者收到组内其他消费者的心跳请求时,在响应中告诉消费者要重平衡 3.组内原有消费者会重新发送joinGroup请求到组协调者 4.组协调者根据发送joinGroup请求的先后选出消费者leader,将topic和分区信息响应给各个消费者 5.被选为leader的消费者将分区分配好 6.各消费者发送SyncGroup请求给组协调者请求新分配好的分区信息,其中消费者leader会携带分配好的分区信息 7.组协调者将各个消费者负责的分区信息响应给消费者,重平衡完成 消费者主动离开导致重平衡 1.消费者发送leaveGroup请求给组协调者 2.此后组协调者收到组内其他消费者的心跳请求时,在响应中告诉消费者要重平衡 3.消费者会重新发送joinGroup请求到组协调者 4.组协调者根据发送joinGroup请求的先后选出消费者leader,将topic和分区信息响应给各个消费者 5.被选为leader的消费者将分区分配好 6.各消费者发送SyncGroup请求给组协调者请求新分配好的分区信息,其中消费者leader会携带分配好的分区信息 7.组协调者将各个消费者负责的分区信息响应给消费者,重平衡完成 消费者失去心跳导致重平衡 1.消费者一定时间内没有发送心跳信息给组协调者 2.此后组协调者收到组内其他消费者的心跳请求时,在响应中告诉消费者要重平衡 3.消费者会重新发送joinGroup请求到组协调者 4.组协调者根据发送joinGroup请求的先后选出消费者leader,将topic和分区信息响应给各个消费者 5.被选为leader的消费者将分区分配好 6.各消费者发送SyncGroup请求给组协调者请求新分配好的分区信息,其中消费者leader会携带分配好的分区信息 7.组协调者将各个消费者负责的分区信息响应给消费者,重平衡完成

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

  • 给定以下设置: Kafkav0.11.0.0 3个经纪人 2个主题,每个主题有2个分区,复制因子为3 2个消费者组,每个主题一个 3个包含使用者的服务器 服务器包含两个使用者,每个主题一个,这样: null null null 消费者-B1被分配到topic-1分区-1 消费者-C1被分配到topic-1分区-0 消费者-A1没有分配给分区 这似乎正如我们所料。由于分区计数为2,我们只有两个活动消

  • 我在同一个消费者组上启动了两个消费者,我订阅了20个主题(每个主题只有一个分区) 仅在消费者上使用: kafka消费者组--引导服务器XXXXX:9092--组foo--描述--成员--详细 我做错了什么?

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

  • 由于消息需求的排序,我们有一个主题和一个分区。我们有两个消费者运行在不同的服务器上,具有相同的配置集,即groupId、consumerId和consumerGroup。即 1主题- 当我们部署消费者时,相同的代码会部署在两台服务器上。当消息到来时,我们会注意到两个消费者都在消费消息,而不是只有一个处理。让消费者在两台独立的服务器上运行的原因是,如果一台服务器崩溃,至少其他服务器可以继续处理消息。

  • null 我在这一页上读到以下内容: 使用者从任何单个分区读取,允许您以与消息生成类似的方式扩展消息消耗的吞吐量。 也可以将使用者组织为给定主题的使用者组-组内的每个使用者从唯一分区读取,并且组作为一个整体使用来自整个主题的所有消息。 如果使用者多于分区,则某些使用者将空闲,因为它们没有可从中读取的分区。 如果分区多于使用者,则使用者将从多个分区接收消息。 如果使用者和分区的数量相等,则每个使用者