Механизм перебалансировки Kafka Consumer

Java Kafka

Механизм перебалансировки Kafka Consumer - оригинальная ссылка
Механизм перебалансировки Kafka Consumer - оригинальная ссылка
Механизм перебалансировки Kafka Consumer - оригинальная ссылка

На прошлой неделе я участвовал в техническом обмене Kafka Meetup Beijing Station.Эта статья кратко знакомит с механизмом перебалансировки Kafka Consumer и стратегией оптимизации в ее новой версии~

Группы потребителей в версиях до Кафки

Consumer Group

Как показано на фиг.ConsumerиспользоватьConsumer Groupсами теги имен, и каждая запись, опубликованная в теме, доставляется одному из них в каждой подписавшейся группе потребителей.Consumerпример.ConsumerЭкземпляры могут находиться в отдельных процессах или на отдельных машинах.

я упалConsumerэкземпляры принадлежат одномуConsumer Group, то этиConsumerЭкземпляры будут потребляться таким образом, чтобы они были сбалансированы и перезагружены.Kafka.

я упалConsumerэкземпляры имеют разныеConsumer Group, каждая запись будет транслироваться всемConsumerпроцесс.

Group Coordinator

Group Coordinatorэто услуга, каждыйBrokerЭта служба запускается при запуске.Group Coordinatorиспользуется для храненияGroupотносится кMetaинформацию и будет соответствоватьPartitionизOffsetинформация регистрируется вKafkaвстроенныйTopic(__consumer_offsets)середина.KafkaДо 0.9 он был основан наZookeeperхранитьPartitionизOffsetИнформация(consumers/{group}/offsets/{topic}/{partition}),так какZookeeperНе подходит для частых операций записи, поэтому после 0.9 через встроенныйTopicспособ записать соответствующийPartitionизOffset. Как показано ниже:

существуетKafka 0.8.2Так было раньше

После этого это выглядит так:

каждыйGroupвыберет одинCoordinatorдля завершения каждого изPartitionизOffsetсведения, правила выбора следующие:

  1. рассчитатьGroupсоответствует__consumer_offsetsВверхPartition
  2. Найдите Брокера, соответствующего лидеру Раздела по соответствующему Разделу.Координатор группы на Брокере является координатором группы

Правила расчета перегородки:

partition-Id(__consumer_offsets) = Math.abs(groupId.hashCode() % groupMetadataTopicPartitionCount)

вgroupMetadataTopicPartitionCountсоответствоватьoffsets.topic.num.partitionsзначение параметра, значение по умолчанию — 50 разделов

Consumer Rebalance Protocol

Когда ребалансировать

  1. Меняется количество участников группы. например есть новыеconsumerЭкземпляр присоединяется к группе потребителей или покидает группу.
  2. подписалсяTopicНомер меняется.
  3. подпискаTopicКоличество разделов изменилось.

Когда потребительский процесс зависает

  1. sessionИстекший
  2. heartbeatИстекший

Rebalanceкогда это происходит,Groupвсе подConsumerЭкземпляры будут координироваться для совместного участия,KafkaДля обеспечения максимально справедливого распределения. ноRebalanceпара процессовConsumer Groupбудет иметь более серьезные последствия. существуетRebalanceв процессеConsumer GroupВсе потребительские экземпляры перестанут работать, ожидаяRebalanceПроцесс завершен.

Протокол перебалансировки потребителя

Процесс выполнения после перебалансировки

1. Есть новыеConsumerПрисоединяйсяConsumer Group

2, изConsumer Groupизбиратьleader

3,leaderВыделить разделы

Issues

Known Issue #1: Stop-the-world Rebalance

Как показано выше: предыдущая версияKafkaэто происходитRebalanceвыпуститConsumer Groupвсех ресурсов, что приводит к относительно длительномуStop-the-world

Known Issue #2: Back-and-forth Rebalance

Как показано на рисунке выше: когдаRebalanceНенужное высвобождение и перераспределение ресурсов, которое происходит, когда

Сравнение текущего ребаланса и улучшенного ребаланса

Протокол прогрессивной перебалансировки

Как показано на рисунке выше, новый протокол прогрессивной перебалансировки не требует, чтобы все текущие потребители освобождали ресурсы, которыми они владеют, во время перебалансировки, но регистрирует текущие ресурсы, когда необходимо запустить перебалансировку, а затем выполняет прогрессивную перебалансировку. Эффект оптимизации от этого

  • По сравнению с предыдущей ребалансировкой было выполнено больше ребалансировок, но потребление ресурсов при каждой ребалансировке относительно низкое.
  • Переносится меньше разделов, чем раньше
  • Потребитель может продолжать работать во время перебалансировки

Справочная статья

Подписывайтесь на нас

关注我们